Bugzilla – Bug 936964
swap partition's UUID hard coded in initrd produces emergency shell instead of booting
Last modified: 2015-11-27 09:06:34 UTC
cf. https://bugzilla.redhat.com/show_bug.cgi?id=1187007 Mailing list discussion: http://lists.opensuse.org/opensuse/2015-07/msg00080.html To reproduce on TW 20150630 already installed: 1-change UUID of swap partition (e.g., install something else in multiboot which recreates swap) 2-change fstab for new swap UUID (or to swap's volume label or device name) 3-try to boot Actual result: 1-emergency shell 2-obsolete UUID not found Expected result: 1-normal boot Notes: 1-initrd (26 February) for 3.19.0 (20 February) produces no such problem. 2-restoring original UUID to swap partition fixes existing initrd
I submitted a new dracut package for factory 4 days ago: https://build.opensuse.org/request/show/314859 Hopefully it goes through and shows up pretty soon. Please try this one, rules are not that strict anymore for waiting on swap. Hm, I fear it won't help, you also could/want use your swap for suspend to disk, right? Hm, for me, the right way looks like in above steps: To reproduce on TW 20150630 already installed: 1-change UUID... 2-change fstab ... 3-try to boot ... Number 2.5 is missing: call dracut to update the swap uuid inside the initrd. Ok, but this can be difficult up to impossible. Not sure what could change the UUID, but there might be obscure reasons (see EFI based fedora bug). IMO best and relative easy solution for now would be something like discussed on the initramfs mailing list: "Allow boot to continue if swap devices are not detected." I try to come up with something, but it may take some days.
(In reply to Thomas Renninger from comment #1) > you also could/want use your swap for suspend to disk, right? All my TW installations are used exclusively for testing. I have 0 laptops. All my installations are in multiboot. Consequently, I never ever suspend. > Hm, for me, the right way looks like in above steps: > To reproduce on TW 20150630 already installed: > 1-change UUID... > 2-change fstab ... > 3-try to boot ... > Number 2.5 is missing: > call dracut to update the swap uuid inside the initrd. > Ok, but this can be difficult up to impossible. I agree about the difficult part. At least in theory, one could chroot in from whatever was booted to perform rebuild, but that would be far inferior to life as it previously existed, a herculean task if all 10, 20, 30 or more installations' initrds behaved like TW current. > Not sure what could change the UUID 1-Some distro installers insist on using and reformatting every existing swap partition found (maybe most do?). 2-delete to recreate at increased size rather than direct resize (is resize of swap even possible?). 3-decide swap is not wanted or wanted on a different disk, so remove entry from fstab, and repurpose its partition 4-scenario from recent days (in less than full detail): A: run short on / freespace with an upgrade process downloading everything in advance of installing B: reboot something else C: swapoff -a D: mkfs on "swap" partition E: (move /var from shortspaced part to former swapper part; edit its fstab accordingly) F: boot shortspaced installation and finish upgrade G: reboot something else to undo step E: H: recreate swap > IMO best and relative easy solution for now would be something like > discussed on the initramfs mailing list: > "Allow boot to continue if swap devices are not detected." Seems sensible to me. Does need for swap ever begin before any login or normal autostart server operations occur? > I try to come up with something, but it may take some days. Thanks.
On host gx62b, I booted 13.2, ran swapoff -a, recreated swap using same LABEL but new UUID. TW, freshly updated, with swap defined in fstab using device name, subsequently booted kernel 4.1.4 normally. I then ran swapoff -a, recreated swap with different LABEL and UUID. Again TW subsequently booted normally. I don't recognize anything in dracut-043-2.1 changelog to account for the improvement, but it does seem this is somehow fixed.
Tried with latest TW and dracut-044, seems to work fine.