Bugzilla – Bug 1221636
While booting system waits 2 minutes for non-existing partition with uuid
Last modified: 2024-04-15 13:27:25 UTC
During boot journalctl -b reports: mrt 18 13:40:14 eiktum systemd-hibernate-resume-generator[167]: Reported hibernation image: ID=opensuse-tumbleweed VERSION_ID=20231106 kernel=6.5.9-1-default UUID=b66ef179-3b2f-407b-81f3-88e5c71ea8de offset=0 [....] mrt 18 13:40:14 eiktum systemd[1]: Expecting device /dev/disk/by-uuid/b66ef179-3b2f-407b-81f3-88e5c71ea8de... mrt 18 13:40:14 eiktum systemd[1]: Expecting device /dev/disk/by-uuid/e210e98f-8b62-4fd0-ad4c-437cf6bd1317... The device with UUID=b66ef179-3b2f-407b-81f3-88e5c71ea8de is not present in the system, so during boot it takes 2 minutes waiting for this device to show up and to continue booting. Apparently without any ill effects. It appeared after the upgrade to Plasma 6.
Check the output from: grep resume /etc/default/grub
(In reply to Neil Rickert from comment #1) > Check the output from: > > grep resume /etc/default/grub Does not show any output. I searched the whole tree of /boot and /etc for the last three characters (8de) of the uuid the system is waiting for and did not find anything resembling the whole uuid.
(In reply to Freek de Kruijf from comment #2) > (In reply to Neil Rickert from comment #1) > > Check the output from: > > > > grep resume /etc/default/grub > > Does not show any output. > > I searched the whole tree of /boot and /etc for the last three characters > (8de) of the uuid the system is waiting for and did not find anything > resembling the whole uuid. I installed Tumbleweed a second time on a separate partition using other partitions used in the first one and reformatted the 2 swap partitions. After that this strange waiting for a non-existing uuid appeared again. I can't find where this comes from. I changed the timeout for resume-hibernation but that did nothing. So it looks like something that happens after resume-hibernation.
(In reply to Freek de Kruijf from comment #0) > During boot journalctl -b reports: > mrt 18 13:40:14 eiktum systemd-hibernate-resume-generator[167]: Reported > hibernation image: ID=opensuse-tumbleweed VERSION_ID=20231106 > kernel=6.5.9-1-default UUID=b66ef179-3b2f-407b-81f3-88e5c71ea8de offset=0 You're experiencing the following upstream issue: https://github.com/systemd/systemd/issues/32021 Temporary workaround: https://github.com/systemd/systemd/issues/30395#issuecomment-1852613917
(In reply to Antonio Feijoo from comment #4) > (In reply to Freek de Kruijf from comment #0) > > During boot journalctl -b reports: > > mrt 18 13:40:14 eiktum systemd-hibernate-resume-generator[167]: Reported > > hibernation image: ID=opensuse-tumbleweed VERSION_ID=20231106 > > kernel=6.5.9-1-default UUID=b66ef179-3b2f-407b-81f3-88e5c71ea8de offset=0 > > You're experiencing the following upstream issue: > https://github.com/systemd/systemd/issues/32021 > > Temporary workaround: > https://github.com/systemd/systemd/issues/30395#issuecomment-1852613917 It suggests to remove the entry /sys/firmware/efi/efivars/HibernateLocation... Although the protection is -rw-r--r-- I am unable to remove that entry with "rm" as root; Operation not permitted.
> Although the protection is -rw-r--r-- I am unable to remove that entry with > "rm" as root; Operation not permitted. Did not read further and used chattr -i on that entry and now the entry is removed. Thanks!!
I'm wondering whether "HibernateLocation" EFI variable shouldn't be unconditionally purged by the installer when it set a new system up.... Or maybe the resume generator should be skipped when the first boot condition is met.
I'm closing this report as this is supposed to be fixed by https://github.com/systemd/systemd/pull/32043 which will be released with v256.