systemd mounts efi partition, but /etc/fstab says "noauto"

Bug #1691158 reported by DLCBurggraaff
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
systemd (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

Systemd mounts /dev/sda5 on /boot despite the fact that /etc/fstab says:
    /dev/sda5 /boot ext2 noauto,relatime 0 0

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: systemd 229-4ubuntu17
ProcVersionSignature: Ubuntu 4.8.0-52.55~16.04.1-generic 4.8.17
Uname: Linux 4.8.0-52-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.5
Architecture: amd64
CurrentDesktop: XFCE
Date: Tue May 16 17:58:49 2017
MachineType: To Be Filled By O.E.M. To Be Filled By O.E.M.
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz root=/dev/sda10 ro
SourcePackage: systemd
SystemdDelta:
 [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf
 [EXTENDED] /lib/systemd/system/systemd-timesyncd.service → /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf

 2 overridden configuration files found.
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 01/25/2016
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: P1.20
dmi.board.name: H110M-HDS
dmi.board.vendor: ASRock
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrP1.20:bd01/25/2016:svnToBeFilledByO.E.M.:pnToBeFilledByO.E.M.:pvrToBeFilledByO.E.M.:rvnASRock:rnH110M-HDS:rvr:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
dmi.product.name: To Be Filled By O.E.M.
dmi.product.version: To Be Filled By O.E.M.
dmi.sys.vendor: To Be Filled By O.E.M.

Revision history for this message
DLCBurggraaff (burdi) wrote :
Revision history for this message
DLCBurggraaff (burdi) wrote :
Revision history for this message
DLCBurggraaff (burdi) wrote :
Revision history for this message
DLCBurggraaff (burdi) wrote :

root@riposo:~/works# fdisk /dev/sda

Welcome to fdisk (util-linux 2.27.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): p
Disk /dev/sda: 223.6 GiB, 240057409536 bytes, 468862128 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 3A5A8620-1AA6-4190-A9AC-D8AA511D6F9C

Device Start End Sectors Size Type
/dev/sda1 2048 4095 2048 1M Linux filesystem
/dev/sda2 4096 6143 2048 1M Linux filesystem
/dev/sda3 6144 8191 2048 1M Linux filesystem
/dev/sda4 8192 10239 2048 1M BIOS boot
/dev/sda5 10240 10495999 10485760 5G EFI System
/dev/sda6 10496000 10498047 2048 1M Linux filesystem
/dev/sda7 10498048 52441087 41943040 20G Linux filesystem
/dev/sda8 52441088 52443135 2048 1M Linux filesystem
/dev/sda9 52443136 52445183 2048 1M Linux filesystem
/dev/sda10 52445184 94388223 41943040 20G Linux filesystem
/dev/sda11 94388224 136331263 41943040 20G Linux filesystem
/dev/sda12 136331264 220215295 83884032 40G Linux filesystem
/dev/sda13 220215296 220217343 2048 1M Linux filesystem
/dev/sda14 220217344 262160383 41943040 20G Linux filesystem
/dev/sda15 262160384 304103423 41943040 20G Linux filesystem
/dev/sda16 304103424 408961023 104857600 50G Linux filesystem

Revision history for this message
DLCBurggraaff (burdi) wrote :

As e.g. kernel upgrades fail I explicitely umount /dev/sda5 in rc.local

Revision history for this message
DLCBurggraaff (burdi) wrote :

*Correction*: As e.g. reboots after a kernel upgrade fail I explicitely umount /dev/sda5 in rc.local

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

/boot != EFI partition. You should not be placing kernels in teh UEFI partition.

It seems that sda5 is EFI partition which should be mounted as /boot/efi by default. and your kernels can be on different filesystem or the root filesystem in /boot.

do not use EFI fat partition for kernels.

Revision history for this message
DLCBurggraaff (burdi) wrote :

"/boot != EFI partition. You should not be placing kernels in teh UEFI partition."
My root filesystem (sda10 in this case) contains the kernels, the sda5 EFI partition does not.
My sda10 partition does not contain a /boot/efi directory, so I created one and rebooted: sda5 is still mounted on /boot.
I then renamed that directory to /boot/EFI and rebooted: sda5 is still mounted on /boot.

Sda5 only contains Grub2 (and an unofficial PartedMagic spin) and is not really an EFI partition -- this flag is a leftover from an earlier experiment. So I removed that flag and rebooted once more: sda5 is still mounted on /boot ...

Perhaps superfluously I mention that I do not use Xubuntu's Grub/EFI setup, but PartedMagic's instead. The Grub stanza for Xubuntu reads:

menuentry '[10] Xubuntu 16.04.2 "Xenial Xerus"' {
  set root=(hd0,10)
  linux /boot/vmlinuz root=/dev/sda10 ro
  initrd /boot/initrd.gz
}
where /boot/vmlinuz is a symlink to ../vmlinuz and /boot/initrd.gz to ../initrd.img. The /vmlinuz and /initrd.img are symlinks back into /boot and are amended by the installing a new kernel version procedure. My /boot symlinks need no maintenance therefore.

Revision history for this message
DLCBurggraaff (burdi) wrote :

Now imagine what happens when sda5 is mounted "behind my back" on /boot and a new kernel is installed by the Software Updater: the new kernel ends up on sda5 and the /vmlinuz and /initrd.img "system" symlinks point the new files.
On a reboot Grub does not mount sda5: the "system" symlinks point to non-existing files and Grub fails ...

The /var/log/messages file as provided shows that systemd mounts sda5 on /boot and I really cannot think of a reason for that.

Revision history for this message
DLCBurggraaff (burdi) wrote :

I should also mention that the symptom started recently. I am not sure exactly when but it did not occur before the last 3 or so kernel updates.

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

A fuller sosreport would be helpful to see what is going on. ($ sudo sosreport)

Also (not sure if that is included) contents of /run/systemd may be helpful as well. It may be that one of the systemd generators are creating the .mount units that you do not want.

If that is the case you may want to execute something like $ sudo systemctl mask boot.mount
to prevent such a unit mounting things not the way you want.

Revision history for this message
DLCBurggraaff (burdi) wrote :
Revision history for this message
DLCBurggraaff (burdi) wrote :
Revision history for this message
DLCBurggraaff (burdi) wrote :
Revision history for this message
DLCBurggraaff (burdi) wrote :
Revision history for this message
DLCBurggraaff (burdi) wrote :

It looks like /run/systemd/generator/-.mount is the culprit.
However, whatever I try issuing "sudo systemctl mask -.mount" fails with a "systemctl: invalid option -- '.'" error message.

Revision history for this message
Dan Streetman (ddstreet) wrote :

please reopen if this is still an issue

Changed in systemd (Ubuntu):
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.