Join Log in
Score:0
Christoffer Soop avatar Ubuntu

Ignore label when mounting boot partition of os image as a loopback device

ua flag
Christoffer Soop

I would like to mount the boot partition of the ubuntu-21.10-preinstalled-server-arm64+raspi.img.xz downloaded off the Raspberry PI web site.

Unpacking the image file and mounting the boot partition with a command like

mount -o loop,offset=1048576,sizelimit=268435456 ubuntu-21.10-preinstalled-server-arm64+raspi.img /var/nfs/ubuntu-21.10-boot

... works just fine. You can see the mounted image together with the /dev/mmcblk0p1 device:

mount | grep boot
/dev/mmcblk0p1 on /boot/firmware type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
/var/nfs/ubuntu-21.10-preinstalled-server-arm64+raspi.img on /var/nfs/ubuntu-21.10-boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)

However, when I add the same mount to /etc/fstab to the already existing mount for /boot/firmware:

LABEL=system-boot       /boot/firmware  vfat    defaults        0       1
/var/nfs/ubuntu-21.10-preinstalled-server-arm64+raspi.img /var/nfs/ubuntu-21.10-boot ext4 loop,offset=1048576,sizelimit=268435456 0 0

... and reboot the system (or run mount -a) the boot partition of the image is mounted both at /var/nfs/ubuntu-21.10-boot as expected but also at /boot/firmware and thus replacing the real firmware at /dev/mmcblk0p1:

mount | grep boot
/var/nfs/ubuntu-21.10-preinstalled-server-arm64+raspi.img on /var/nfs/ubuntu-21.10-boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
/var/nfs/ubuntu-21.10-preinstalled-server-arm64+raspi.img on /boot/firmware type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)

This is evidently because the boot partition of the image is labeled system-boot which collides with the /dev/mmcblk0p1 labeled the same way.

(The mount manual page specifies that fstab is ignored when both device and mount points are specified which explains why mounting manually works as expected.)

I can think of the following workarounds to avoid the firmware mount to be overwritten:

  • Avoid using fstab and mount manually in an rc script
  • Relabel the boot partition of the image file
  • Replace LABEL=system-boot with the actual device that holds the firmware (as suggested in @Tilman's answer below)

... but

Is there a way to prevent an fstab entry to automatically mount by label?

48
0 + 0
Christoffer Soop avatar
ua flag
Christoffer Soop
Added the workaround from the answer below but not accepting it as an answer as it does not really answer the question if you can prevent the system.d event mechanism from triggering when a loopback device is added to fstab.
0
Reply
Score:0
Tilman avatar Ubuntu
cn flag
Tilman

The clause LABEL=system-boot tells mount to mount any filesystem with volume label system-boot on that mountpoint. If you don't want that then don't use that clause. Replace it by /dev/mmcblk0p1 which tells mount to mount exactly that device, disregarding the label.

0 + 0
Christoffer Soop avatar
ua flag
Christoffer Soop
Thanks - but this assumes that I my script knows that the `system-boot` device is `/dev/mmcblk0p1` something I would hope not take for granted or parse out of the output of mount or some other command...
0
Reply
Tilman avatar
cn flag
Tilman
Then you need to take a step back. What defines which device you want to get mounted on `/boot/firmware`? You cannot use the label since you made that non-unique. You don't want to use the device name since you don't want to impart that knowledge to your script. What then?
0
Reply
Christoffer Soop avatar
ua flag
Christoffer Soop
In this case I am using a pre-packaged image of the OS that I am using both for mounting on a "host" machine that serves an NFS file system to diskless clients. Currently I am using /boot/firmware for the diskless clients but it would be better to use the boot partition of the image as could then disassociate the host OS version from that of the clients. I guess my best option is to change the label of the image file. Also might want to pre-provision software so making custom images does not seem like a stretch.
0
Reply
Christoffer Soop avatar
ua flag
Christoffer Soop
... and then the easiest thing to do is really just to mount the boot partition copy it to the fs and skip the whole label issue all together by not adding the boot partition to fstab at all. Just thought that there would be some way to inhibit the default automount per label feature of fstab for individual lines but I suspect that what I am seeing is an unintended behaviour as the loopback device is already mounted when the automouning kicks in.
0
Reply
sudodus avatar
jp flag
sudodus
In general, it is safer to use the UUID than a label to define what to mount, because it is more likely to be unique. Would that be possible in your case?
1
Reply
Christoffer Soop avatar
ua flag
Christoffer Soop
@sudodus - you mean by changing the default `LABEL=system-boot` line in `/etc/fstab` as opposed to changing the label of the partition defined in the image? Assuming that it works (can't see why not) I still need to find out how to script it using `cloud-init` or Ansible and it does not really answer the original question... but sure, that is a possibility that resolves the underlying issue at least - thanks!
0
Reply
Christoffer Soop avatar
ua flag
Christoffer Soop
... and this was what the answer was saying the first place.
0
Reply
sudodus avatar
jp flag
sudodus
@ChristofferSoop, Yes I mean that changing to `UUID=...` makes it more reliable. (You can find the correct UUID with the command `lsblk -f`), Please notice that the device ID `/dev/...` is *not* as reliable as using the uuid.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.