You are not logged in.
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...
Offline
If /etc/updatedb.conf hasn't been modified, there's no point in posting it.
Offline
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)
Offline
But there's no automounter in OP's fstab...
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)
Offline
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)
Offline
Interesting/mysterious stuff... I Googled for this and found this relevant talk in our (duh) wiki:
https://wiki.archlinux.org/index.php/Talk:Gummiboot
This silver ladybug at line 28...
Offline
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)
If there's one thing I've learned about remote debugging over the years, it's to not trust people.
Especially Antipodeans
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
* this feature isn't even documented in systemd yet
Great. Any way to suppress this?
Offline
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.
Offline
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.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
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.
Offline
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...
Offline
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.
Offline
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.
Offline
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.
Offline
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
This silver ladybug at line 28...
Offline