What | Removed | Added |
---|---|---|
Flags | needinfo?(jjletho67-esus@yahoo.it) |
(In reply to Marco M. from comment #14) > > Hm, for this to work you should probably replace your mount by UUID for > > partitions on the root device by the device name (e.g. /dev/sda1 for > > /boot/efi). > > Yes, they already are mounted by UUID. You can check the fstab file I > attached. But mount by uuid will fail if the first harddisk isn't present, since the filesystem UUID won't be found. Mount by sda should succeed if the first harddisk fails, because the second harddisk becomes sda then. > > This device timeout is rather systemd related. > > After mounting sysroot, systemd creates mount units for partitions on the > > system root device. These mount units have a dependency on the configured > > device. > > It looks like the systemd-gpt-auto-generator is causing this (for details > > see its manpage). > > I'm afraid that you will need to switch back from uefi to legacy bios mode > > if you want to avoid the access to the efi device n the initrd. > > Thanks for the suggestion, I read the man page and it says that if efi > partitions is already specified in fstab no further mountpoint are > autogenerated. In my case /boot/efi is specified in fstab with nofail > option, so it shuold not be a problem and any other units which depends on > it should not exist. > > It's illogical to have any dependencies on /boot/efi, because if systemd is > running this means that uefi boot has been already completed and you don't > need efi partition anymore, at least to complete the boot process. So why > systemd abolutely need an efi partition mounted and does not honor the > nofail option? Indeed, the code in gpt-auto-generator.c shows: --> static int add_esp(DissectedPartition *p) { const char *esp; int r; assert(p); if (in_initrd()) { log_debug("In initrd, ignoring the ESP."); return 0; } --< Could you boot with the boot option: debug (and remove: quiet if present) and check whether you can see the above log message about ignoring ESP?