[SOLVED] Long boot delay related to EFI automount.

quequotion · 2024-01-02 16:53:03

Hello! Long time no see.

I've been out of the loop for a while, and I think I've missed something.

First, here are the messages I'm getting at every boot, after a very long delay:

[ TIME ] Timed out waiting for device /dev/disk/by-diskseq/10-part1

[DEPEND] Dependency failed for EFI System Partition Automount

[DEPEND] Dependency failed for Filesystem check on /dev/disk/by-diskseq/10-part1

Despite how dire that sounds, boot proceeds without any problems, and the system is working as well as it ever has.

There is no /dev/disk/by-diskseq/10-part1.

ls /dev/disk/by-diskseq/:

1  2  3  4  5  5-part1  7

I get the impression that some time ago the way systemd handles the EFI partition has changed, and this error may be the result of having not performed some manual intervention that I don't even know the correct terms to look up.

I still have an entry for /boot in /etc/fstab, but what I can google leads me to believe the thing people do these days is let systemd automount it only as needed (x-systemd.automount,noauto). I have not found an arch-specific wiki, guide, or article as to this, but I did find a Fedora bug report and an Archwiki subsection about systemd's GPT automounting.

btw, my /etc/fstab:

# Static information about the filesystems.
# See fstab(5) for details.

# <file system> <dir> <type> <options> <dump> <pass>
# /dev/mapper/cryptroot
UUID=052ca3ae-a5f3-43c8-96b2-5fd547f903ca / ext4 rw,nodiratime,relatime,nobarrier,max_batch_time=60000,stripe=512,inode_readahead_blks=512 0 1

# /dev/md126p1
UUID=B66C-EE89 /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 2

#PGODEST
/home/zombie/Sources/PKGBUILD/BUILDCHROOT/zombie/mnt/pgo/ /mnt/pgo/ none bind,x-gvfs-hide 0 0
/mnt/pgo/ /home/zombie/Sources/PKGBUILD/BUILDCHROOT/root/mnt/pgo/ none bind,x-gvfs-hide 0 0

#SRCDEST
/home/zombie/Sources/PKGBUILD/BUILDCHROOT/zombie/mnt/src/ /mnt/src/ none bind,x-gvfs-hide 0 0
/mnt/src/ /home/zombie/Sources/PKGBUILD/BUILDCHROOT/root/mnt/src/ none bind,x-gvfs-hide 0 0

I note that my file tree includes a /efi, which I have no recollection of creating and which is not owned by any package.
ls /:

bin  boot  dev  efi  etc  home  lib  lib64  lost+found  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

If I try to do anything with that directory, such as list files in it, there is a very long delay and then an error, ie:
ls /efi/:

ls: cannot access '/efi/': No such device

Any suggestions, or requests for further system information, are welcome.

Edit: ie, likely a variant of this, but my symptoms are somewhat different. I will see if I can use the solution from that thread.

Edit again: Indeed, it was the same issue of systemd deciding to ignore my fstab configuration and trying to automount my gtp partition table by itself, which no one ever asked it to do, but is the default thing it does now..

So, after stopping and disabling the haywire automount service and deleting /efi, I added systemd.gpt_auto=no to my kernel options and x-systemd.automount to the mount options for /boot in /etc/fstab. The last part is not strictly necessary, but taking Fedora advice on this (it is not necessary, and potentially even unsafe, to mount the EFI partition at all times).

Last edited by quequotion (2024-01-02 17:22:56)

Head_on_a_Stick · 2024-01-02 17:40:45

quequotion wrote:

I added systemd.gpt_auto=no to my kernel options and x-systemd.automount to the mount options for /boot in /etc/fstab.

Be sure to add vfat to a file in /etc/modules-load.d/ or the /boot/ partition will not be mountable following a kernel upgrade and the kernel image won't be copied to the /boot/ partition, which will break the boot process.

Last edited by Head_on_a_Stick (2024-01-02 17:41:31)

quequotion · 2024-01-02 18:46:06

Head_on_a_Stick wrote:

Be sure to add vfat to a file in /etc/modules-load.d/ or the /boot/ partition will not be mountable following a kernel upgrade and the kernel image won't be copied to the /boot/ partition, which will break the boot process.

Nice catch! Wouldn't have thought of that.

I note that I do already have it in /etc/mkinitcpio.conf:

/etc/mkinitcpio.conf
# vim:set ft=sh
# MODULES
# The following modules are loaded before any boot hooks are
# run.  Advanced users may wish to specify all system modules
# in this array.  For instance:
#     MODULES=(usbhid xhci_hcd)
#MODULES=()
MODULES=(raid0 ext4 fat vfat nvidia nvidia_modeset nvidia_uvm nvidia_drm hid_logitech_dj uhci_hcd usbhid)

# BINARIES
# This setting includes any additional binaries a given user may
# wish into the CPIO image.  This is run last, so it may be used to
# override the actual binaries included by a given hook
# BINARIES are dependency parsed, so you may safely ignore libraries
#BINARIES=()
BINARIES=(mdmon fsck fsck.ext4 fsck.fat)

# FILES
# This setting is similar to BINARIES above, however, files are added
# as-is and are not parsed in any way.  This is useful for config files.
FILES=()

# HOOKS
# This is the most important setting in this file.  The HOOKS control the
# modules and scripts added to the image, and what happens at boot time.
# Order is important, and it is recommended that you do not change the
# order in which HOOKS are added.  Run 'mkinitcpio -H <hook name>' for
# help on a given hook.
# 'base' is _required_ unless you know precisely what you are doing.
# 'udev' is _required_ in order to automatically load modules
# 'filesystems' is _required_ unless you specify your fs modules in MODULES
# Examples:
##   This setup specifies all modules in the MODULES setting above.
##   No RAID, lvm2, or encrypted root is needed.
#    HOOKS=(base)
#
##   This setup will autodetect all modules for your system and should
##   work as a sane default
#    HOOKS=(base udev autodetect modconf block filesystems fsck)
#
##   This setup will generate a 'full' image which supports most systems.
##   No autodetection is done.
#    HOOKS=(base udev modconf block filesystems fsck)
#
##   This setup assembles a mdadm array with an encrypted root file system.
##   Note: See 'mkinitcpio -H mdadm_udev' for more information on RAID devices.
#    HOOKS=(base udev modconf keyboard keymap consolefont block mdadm_udev encrypt filesystems fsck)
#
##   This setup loads an lvm2 volume group.
#    HOOKS=(base udev modconf block lvm2 filesystems fsck)
#
##   NOTE: If you have /usr on a separate partition, you MUST include the
#    usr and fsck hooks.
#HOOKS=(base udev autodetect modconf kms keyboard keymap consolefont block filesystems fsck)
HOOKS=(base systemd autodetect sd-vconsole modconf keyboard block mdadm_udev sd-encrypt shadow)

# COMPRESSION
# Use this to compress the initramfs image. By default, zstd compression
# is used. Use 'cat' to create an uncompressed image.
COMPRESSION="zstd"
#COMPRESSION="gzip"
#COMPRESSION="bzip2"
#COMPRESSION="lzma"
#COMPRESSION="xz"
#COMPRESSION="lzop"
#COMPRESSION="lz4"

# COMPRESSION_OPTIONS
# Additional options for the compressor
COMPRESSION_OPTIONS=(-T0)

# MODULES_DECOMPRESS
# Decompress kernel modules during initramfs creation.
# Enable to speedup boot process, disable to save RAM
# during early userspace. Switch (yes/no).
MODULES_DECOMPRESS="yes"

I had already rebooted once before getting your reply, and /boot/ is operational with an automount service running.

nl6720 · 2024-01-03 13:17:35

Head_on_a_Stick wrote:

Be sure to add vfat to a file in /etc/modules-load.d/ or the /boot/ partition will not be mountable following a kernel upgrade and the kernel image won't be copied to the /boot/ partition, which will break the boot process.

That's not needed since https://gitlab.archlinux.org/archlinux/ … de913f64a3 (mkinitcpio 35).

Arch Linux

#1 2024-01-02 16:53:03

[SOLVED] Long boot delay related to EFI automount.

#2 2024-01-02 17:40:45

Re: [SOLVED] Long boot delay related to EFI automount.

#3 2024-01-02 18:46:06

Re: [SOLVED] Long boot delay related to EFI automount.

#4 2024-01-03 13:17:35

Re: [SOLVED] Long boot delay related to EFI automount.

Board footer