Update with read-only /boot

[0n0w1c]

This morning, for the first time that I can recall, for some reason my /boot partition mounted read-only. I updated and it ran to completion, but I noticed during the update of the raspberrypi bootloader packages, it failed to “unlink” files. So I umounted and remounted /boot and then I re-ran the update for those packages and all is good.

Maybe the update process could check to make sure the filesystems are read-write before starting the update process?

[Strit]

A package manager assumes the partitions where files are getting placed are read-write.

We don’t do anything to specifically mount something read-only.

If your boot partition mounted read-only it could mean that the SD card might be starting to fail…

If you want the package manager to check if the destinations are actually read-write, you should suggest it the pacman/alpm developers.

[0n0w1c]

I fsck’ed /boot and it did have errors. I cleared those up and re-installed the kernel and bootloaders again, just to make sure the files were sane. I doubt the Arch folks would care for my suggestion, so I might add my own pre-update alpm hook that does a check. However, I should probably create a boot time check, so I know there is an issue before attempting to update.

[0n0w1c]

For those that may be wondering… how /boot was mounted read-only, it is due to the defaults for a FAT partition:

From my /etc/fstab

UUID=92DA-BDF9                       /boot                   vfat    defaults,nofail                                                 0       0

If you examine how /boot is actually mounted:
$ grep “/boot” /etc/mtab

/dev/sda1 /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro 0 0

There you will see errors=remount-ro

So with my configuration, /boot will be mounted read-only if there are errors on the FAT filesystem. This will likely go unnoticed until an attempt to write to /boot. If a kernel update occurs and I do not notice the errors during the update, my system may be rendered unable to boot.

Fortunately, an improper umount does not equate to filesystem errors, as this occurs often.

[Strit]

But this would be a safety measure, wouldn’t it? Like if the filesystem on /boot has errors, it shouldn’t try writing to it in the first place, since that could make it worse.

[0n0w1c]

Yes, to my understanding you are correct, writing to a corrupt filesystem can be very destructive and should be avoided. So I am not going to adjust how my system mounts, simply a test to detect a read-only /boot and alert to the condition. One of the downsides to booting into graphical mode, it is very easy to miss import boot messages.

I should probably remove the nofail. I believe the system would then simply refuse to boot, but sometimes that is not so good. So I am not advocating how I mount. If this were a server, I would remove the nofail and repair the filesystem the correct way, which is to boot on different media and then perform the filesystem repairs.

[0n0w1c]

This is what I came up with to check the mount status of /boot. Nothing fancy but it seems to do the job. If /boot is either not mounted or mounted read-only, it will stop the update.

$ cat /etc/pacman.d/hooks/03-check_boot.hook

[Trigger]
Operation = Install
Operation = Upgrade
Operation = Remove
Type = Package
Target = *

[Action]
Depends = grep
Description = Checking if /boot is properly mounted...
When = PreTransaction
Exec = /usr/local/bin/check_boot
AbortOnFail

$ cat /usr/local/bin/check_boot

#!/bin/bash -e

# Check if /boot is properly mounted
# Called by /etc/pacman.d/hooks/03-check_boot.hook

grep "/boot" /etc/mtab | grep -q "vfat rw"
if [ $? -ne 0 ]; then
   exit 1
fi