Category: Uncategorized

Posted on

systemd boot counting and boot-complete.target

Recently I discovered the boot-complete.target and reading the systemd.special man page sounded like it was exactly what I was looking for:

This target is intended as generic synchronization point for services that shall determine or act on whether the boot process completed successfully.

Also reading the AUTOMATIC_BOOT_ASSESSMENT documentation sounded like I am on the right track, so I decided to use the target. Unfortunately the boot-complete.target seemed not to get activated, so I started to dig deeper.

My target was a (non-UEFI) ARM system. Since the Automatic Boot Assessment documentation indicated that the scheme should also work with non-UEFI systems, I was first assuming that systemd has the target already activated by default. But I was wrong… Continue reading “systemd boot counting and boot-complete.target”

Posted on

Control FTDI CBUS while TTY is open

For embedded projects I want to control the FTDI CBUS pins as GPIOs. The libFTDI1 library allows to program the CBUS pins as GPIOs by setting the CBUS function to CBUS_IOMODE. I created a Python script available at the python_ft232_cbus_config repository (must be run as root!). The script reprograms CBUS2/3 to IOMODE, while leaving CBUS0/1 at their default (TXLED/RXLED). It should be fairly easy to change the script for your needs.

Once the CBUS pins are programmed as IOMODE, they can be controlled through libFTDI1. There is a C example in the source repository at examples/bitbang_cbus.c. However, there is one downside when using the library: The FTDI kernel driver gets detached automatically. Since I am a screen user, this means that my open sessions get closed automatically too! Using DONT_DETACH_SIO_MODULE seems not to do the trick, the library returns with error code -5 (unable to claim device). It seems that controlling FTDI from user space inherently conflicts with the in-kernel FTDI driver.

Already a while ago I tried to fix this by adding GPIO support to the kernel driver. Unfortunately this did not work out/I lost interest. However, Peter had a valuable hint back then: Control Transfers should be possible without detaching the kernel driver. Continue reading “Control FTDI CBUS while TTY is open”

Posted on

Getting rid of “will be checked for errors at next reboot”

Some of my virtual servers running Ubuntu 16.04.4 showed a hint whenever logging in:

*** /dev/vda1 will be checked for errors at next reboot ***

This issue persisted already for quite a while. Rebooting seems not to help, and also the tips from the blog post “When “disk will be checked for errors at next reboot” won’t go away in Ubuntu” did not help in my case.

Further exploration showed that “Last checked” as shown when using sudo tune2fs -l /dev/vda1 indeed had a very old date. Is the file system check actually executed? Closely observing the reboot process showed that fsck.ext4 is executed:

Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... 
Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... done.
Begin: Will now check root file system ... fsck from util-linux 2.27.1
[/sbin/fsck.ext4 (1) -- /dev/vda1] fsck.ext4 -a -C0 /dev/vda1

However, the execution returns with a notice that the file system is “clean”. It seems that this does not lead to the date being updated. The man page documents the -f (force) flag to force a check. Digging in the scripts run at boot time (/usr/share/initramfs-tools/scripts/) unveiled that the scripts do add the -f flag in case the kernel parameter forcefsck is used.

So I added the flag in /etc/default/grub to the default Linux kernel arguments:

GRUB_CMDLINE_LINUX_DEFAULT="quiet forcefsck"

And updated grub

sudo update-grub

On the next reboot fsck.ext4 got called with the -f flag and did a proper file system check. And with that, the message on login disappeared.

Note: With forcefsck a full file system check is getting executed on every reboot. This might be not ideal for every environment. It seems that fsck.ext4 and the initramfs scripts do not agree on when a check is actually necessary.

Note 2: All machines also have been upgraded from previous Ubuntu LTS versions so it might be related to that.