Update with read-only /boot

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?

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. :wink:

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.

1 Like

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.

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.

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.

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

Operation = Install
Operation = Upgrade
Operation = Remove
Type = Package
Target = *

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

$ 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

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.