[Solved] Systemd automounts /boot (was mlocate not traversing /boot)

jasonwryan · 2013-07-23 09:42:52

For some reason, mlocate does not index my /boot:

┌─[Shiv  ~ ]
└─╼ locate vmlinuz-linux                                                                                                                                                        
/home/jason/Build/chroot/root/boot/vmlinuz-linux
┌─[Shiv ~ ]
└─╼ sudo updatedb -U /boot                                                                                                                                                      
[sudo] password for jason: 
┌─[Shiv ~ ]
└─╼ locate vmlinuz-linux                                                                                                                                                        
/boot/vmlinuz-linux
/boot/vmlinuz-linux-jwr
┌─[Shiv ~ ]
└─╼ sudo updatedb                                                                                                                                                               
┌─[Shiv ~ ]
└─╼ locate vmlinuz-linux                                                                                                                                                        
/home/jason/Build/chroot/root/boot/vmlinuz-linux

My /etc/updatedb.conf is the stock Arch one, /boot is obviously mounted (as the -U switch works), but a plain updatedb does not return any results from /boot.

I recently moved my ESP from /boot/efi to /boot, and as this is the only machine exhibiting this behaviour, it leads me to suspect something is amiss here.

My fstab:

# ESP: /dev/sda1
UUID=696A-09B3                              /boot       vfat      defaults,relatime,discard          0    2

# /dev/mapper/vgroup-lvroot
UUID=1d2dfd7d-adeb-4786-ag98-c8fg675f8e2f   /           ext4      rw,relatime,discard,data=ordered   0    1

# /dev/mapper/vgroup-lvhome
UUID=50798021-94b5-4011-a593-9087gfhcd59b8   /home       ext4      rw,relatime,discard                0    2

Am I missing something obvious?

# edit: updated thread title with the cause, as opposed to the symptom...

falconindy · 2013-07-23 12:29:53

What's in /etc/updatedb.conf?

karol · 2013-07-23 12:51:30

If /etc/updatedb.conf hasn't been modified, there's no point in posting it.

WonderWoofy · 2013-07-23 13:39:25

There is a mechanism in systemd (or maybe gummiboot) that mounts the ESP on /boot as a systemd autostart unit. So it shows up as autofs, which mlocate does not venture into.

$ mount | grep boot
systemd-1 on /boot type autofs (rw,relatime,fd=37,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
/dev/sda1 on /boot type vfat (rw,nosuid,nodev,noexec,noatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

Last edited by WonderWoofy (2013-07-23 13:40:24)

falconindy · 2013-07-23 13:48:28

But there's no automounter in OP's fstab...

karol wrote:

If /etc/updatedb.conf hasn't been modified, there's no point in posting it.

If there's one thing I've learned about remote debugging over the years, it's to not trust people.

Last edited by falconindy (2013-07-23 13:49:17)

WonderWoofy · 2013-07-23 13:49:33

There is no automounter in my fstab either.

$ grep boot /etc/fstab
/dev/disk/by-label/EFI_System	/boot     vfat        noatime,nodev,nosuid,noexec    0      2

Last edited by WonderWoofy (2013-07-23 13:50:39)

lolilolicon · 2013-07-23 14:04:29

Interesting/mysterious stuff... I Googled for this and found this relevant talk in our (duh) wiki:
https://wiki.archlinux.org/index.php/Talk:Gummiboot

jasonwryan · 2013-07-23 18:11:51

WonderWoofy wrote:

There is a mechanism in systemd (or maybe gummiboot) that mounts the ESP on /boot as a systemd autostart unit. So it shows up as autofs, which mlocate does not venture into.

Bingo!

┌─[Shiv ~ ]
└─╼ mount | grep boot
systemd-1 on /boot type autofs (rw,relatime,fd=36,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
/dev/sda1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro,discard)

falconindy wrote:

If there's one thing I've learned about remote debugging over the years, it's to not trust people.

Especially Antipodeans

lolilolicon wrote:

I Googled for this and found this relevant talk in our (duh) wiki

I spent some time yesterday searching, but missed this--to my shame

65kid on the wiki wrote:

* this feature isn't even documented in systemd yet

Great. Any way to suppress this?

WonderWoofy · 2013-07-23 18:36:45

I would imagine that if you create a symlink for /etc/systemd/system/boot.automount to /dev/null, it would effectively mask the autogenerated unit in /run/systemd/generators.late. But I am not sure and have not actually tried this. But it would make sense, as things in /etc *should* override whatever is in /run and /usr.

cfr · 2013-07-23 18:59:59

Not sure about this at all but systemd.mount's man page says:

If a mount point is configured in both /etc/fstab and a unit file that is stored below /usr the former will take precedence. If the unit file is stored below /etc it will take precedence. This means: native unit files take precedence over traditional configuration files, but this is superseded by the rule that configuration in /etc will always take precedence over configuration in /usr.

I'm not sure if there is an error in this but the third sentence seems to contradict the first - fstab is a traditional config file so a unit file of any kind should take precedence? Of course, it is not clear how this applies to generators - do those work in the same way precedence-wise as units?

But I wonder if you could create a systemd unit under /etc if WonderWoofy's suggestion doesn't work.

WonderWoofy · 2013-07-23 19:09:09

That does seem to contradict itself, doesn't it. In any case, you souldn't be adding to /usr anyway, and /etc will override both, so that contradiction doesn't really apply here.

You could make a boot.mount unit that would override what is created in /run/systemd/generators. But the problem is that it is not the boot.mount that you want to override, it is the boot.automount. So I think that if you create the mask in /etc, it *should* render the automount unit in /run disabled.

jasonwryan · 2013-07-23 20:56:15

WonderWoofy wrote:

I would imagine that if you create a symlink for /etc/systemd/system/boot.automount to /dev/null, it would effectively mask the autogenerated unit in /run/systemd/generators.late.

Thanks WW: this works. It does seem like a fugly hack, though...

WonderWoofy · 2013-07-24 00:59:58

I tried using systemctl (since it generates a proper unit in /run/systemd/generators.late) and it masked it just fine.

# systemctl mask boot.automount
ln -s '/dev/null' '/etc/systemd/system/boot.automount'

If you choose to boot with something else, and this unit is not generated, it will not do anything anyway. So although it doesn't seem pretty, I would imagine this would be the "proper" way of handling this. Unless of course there is some other way to optionally turn this functionality off from gummiboot or systemd that I am unaware of.

jasonwryan · 2013-07-24 01:08:21

The "proper" way of handling this, IMO, would be to have it off by default.

Thanks for the help with this though, it is much appreciated.

WonderWoofy · 2013-07-24 01:23:51

jasonwryan wrote:

The "proper" way of handling this, IMO, would be to have it off by default.

Oh, I don't disagree with you here. But, I just meant "proper" in the current situation of having the decision made for you. It would be nice if you could at least put something in loader.conf that would disable this.

Thanks for the help with this though, it is much appreciated.

No problem.

lolilolicon · 2013-07-24 02:13:22

TARGET SOURCE    FSTYPE OPTIONS
/boot  systemd-1 autofs rw,relatime,fd=36,pgrp=1,timeout=300,minproto=5,maxproto=5,direct
/boot  /dev/sda1 vfat   rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro,discard

I don't care if updatedb skips /boot, but I do dislike having two entries for /boot in my mtab.
I don't think I need systemd to automount my /boot, with unoptimized mount options (or is there a way to specify them in the unit file?).
This undocumented auto-automount behavior is bad-bad on systemd's part

Arch Linux

#1 2013-07-23 09:42:52

[Solved] Systemd automounts /boot (was mlocate not traversing /boot)

#2 2013-07-23 12:29:53

Re: [Solved] Systemd automounts /boot (was mlocate not traversing /boot)

#3 2013-07-23 12:51:30

Re: [Solved] Systemd automounts /boot (was mlocate not traversing /boot)

#4 2013-07-23 13:39:25

Re: [Solved] Systemd automounts /boot (was mlocate not traversing /boot)

#5 2013-07-23 13:48:28

Re: [Solved] Systemd automounts /boot (was mlocate not traversing /boot)

#6 2013-07-23 13:49:33

Re: [Solved] Systemd automounts /boot (was mlocate not traversing /boot)

#7 2013-07-23 14:04:29

Re: [Solved] Systemd automounts /boot (was mlocate not traversing /boot)

#8 2013-07-23 18:11:51

Re: [Solved] Systemd automounts /boot (was mlocate not traversing /boot)

#9 2013-07-23 18:36:45

Re: [Solved] Systemd automounts /boot (was mlocate not traversing /boot)

#10 2013-07-23 18:59:59

Re: [Solved] Systemd automounts /boot (was mlocate not traversing /boot)

#11 2013-07-23 19:09:09

Re: [Solved] Systemd automounts /boot (was mlocate not traversing /boot)

#12 2013-07-23 20:56:15

Re: [Solved] Systemd automounts /boot (was mlocate not traversing /boot)

#13 2013-07-24 00:59:58

Re: [Solved] Systemd automounts /boot (was mlocate not traversing /boot)

#14 2013-07-24 01:08:21

Re: [Solved] Systemd automounts /boot (was mlocate not traversing /boot)

#15 2013-07-24 01:23:51

Re: [Solved] Systemd automounts /boot (was mlocate not traversing /boot)

#16 2013-07-24 02:13:22

Re: [Solved] Systemd automounts /boot (was mlocate not traversing /boot)

Board footer