Update does not mount /boot which is "noauto"


I have a new BTRFS only system which uses subvols for / (@), /home (@home), etc.

The /boot is on subvol @boot, marked as “noauto” in /etc/fstab

UUID=...	/boot         	btrfs     	rw,noauto,noatime,nodiratime,compress=zstd:3,space_cache,autodefrag,subvol=@boot	0 0

so /boot is empty (not mounted).

Yesterday system update has not mounted /boot and placed all updated kernels files in (previously) empty /boot.

Should update mount /boot before updating kernels, grub or not?

Or should I mount /boot manually every time before starting system update or installing/updating kernels?

Thank you.

why you use a separate subvolume @boot ? On my systems folder /boot remains to subvolume @ mounted at / → eg. root. Then every snapshot of your root system contains even /boot and your installed kernel initramfs. Without it the system is not bootable or even consistently. Thus what u wanted with you @boot subvolume?

Valid point. But I’m not snapshotting whole system.
I want to hide initramfs (and whole /boot) files from other users.

My initial question should update automount /boot or not.
As I could be using other type of fs and have /boot separate, and not mounted automatically.

Negative. There is no way of knowing how many partitions and/or subvolumes have been created in and for a particular GNU/Linux (or other UNIX) system when these partitions or subvolumes are not in use.

How would the update mechanism know whether a particular subvolume is part of the system, whether it’s only a snapshot, or ─ if it’s a different partition ─ whether it may belong to another operating system on the same computer?

It is up to the administrator of the system to ensure that all pertinent filesystems and subvolumes are mounted in read/write mode before commencing the upgrade.

If you want to make sure other user accounts cannot read the contents of /boot, then simply set its permissions to 700, and for extra security/stability, you can also mount it read-only during normal system operation, so long as you remember to remount it as read/write before a system update. You could even write a small script or shell function to automate the process.

In order to move the files that are now in the /boot directory on your root filesystem, mount the @boot subvolume to /mnt, move everything over, unmount the subvolume from /mnt again and mount it on /bootmount has a --move option, so you can do that in one go ─ and then run… :arrow_down:

sudo update-grub

Thank you for explanation.

1 Like

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