|
Bugzilla – Full Text Bug Listing |
| Summary: | While booting system waits 2 minutes for non-existing partition with uuid | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Freek de Kruijf <freek> |
| Component: | Basesystem | Assignee: | systemd maintainers <systemd-maintainers> |
| Status: | RESOLVED UPSTREAM | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | antonio.feijoo, aschnell, fbui, nwr10cst-oslnx |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | 64bit | ||
| OS: | openSUSE Tumbleweed | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Freek de Kruijf
2024-03-18 15:21:56 UTC
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. |