Description of problem:
When booting an encrypted root filesystem, the 'resume' line in the init script
includes the wrong device.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install encrypted system with anaconda
2. Hibernate system
3. Unlock system
Noraml bootup (fixing dirty ext3)
Resume from hiberated (encrypted) swap
Fixed by changing (by hand) the line:
Perhaps some of the long and convoluted code in:
might be of use?
In short, the code at line 1188 of mkinitrd gives a result that doesn't seem to
I can duplicate this without the encrypted root. I get the same resume issue,
so this may be the same as bug #439695. Marking as F9 blocker.
*** Bug 439695 has been marked as a duplicate of this bug. ***
as I indicated in bug #439695 comment #4 this does not appear to be restricted
to resuming on encrypted root, so I am adjusting the summary accordingly:
"I can duplicate this issue, although I get the error on a command like:
If I extract the init script from a kernel build with an earlier version of
mkinitrd which didn't have this problem, I see something like:
resume /dev/mapper/Volume00-swap "
I can confirm this also with encrypted disk, resuming fails the swap partition
is left unmounted and TYPE="swsuspend"
I notice in the init script in the initramfs
(initrd-2.6.25-0.204.rc8.git4.fc9.i686.img) it shows:
*** Bug 442006 has been marked as a duplicate of this bug. ***
Fixed in 6.0.44
I just installed 6.0.44 off koji. Unfortunately it still doesn't look right:
the init script has "resume /dev//dev/vg00/swap" now.
*sigh* Will be fixed in 6.0.45 which Peter is going to build shortly
*** Bug 442144 has been marked as a duplicate of this bug. ***
6.0.45 looks better: it has "resume /dev/vg00/swap", but I haven't actually
tested it yet. (Does initrd create both forms of lvm device paths? mkrootdev
Successfully resumed. 6.0.45 looks like a fix.
Just updated tot his mkinitrd and this may be pm-utils or kernel problem, rather
than related to this issue, but now hibernate doesn't work at all:
simply returns the prompt immediately without any attempt to hibernate.
/var/log/pm-hibernate.log doesn't record any attempts to hibernate.
I'm using latest kernel: -208.
(In reply to comment #12)
> # pm-hibernate
> simply returns the prompt immediately without any attempt to hibernate.
> /var/log/pm-hibernate.log doesn't record any attempts to hibernate.
That appears to be a separate bug. If suspend/resume fails, it leaves the
lockfile around which causes future attempts to suspend to just do nothing. You
can work around it with "rm /var/run/pm-utils/locks/pm-utils.lock".
Resuming with an initrd generated by 6.0.45 works for me: