Bug 438951 - wrong swap dev causes resume failure
Summary: wrong swap dev causes resume failure
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: All Linux
medium
high
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
: 439695 442006 442144 (view as bug list)
Depends On:
Blocks: F9PR
TreeView+ depends on / blocked
 
Reported: 2008-03-26 05:15 UTC by Andrew Bartlett
Modified: 2008-06-17 01:17 UTC (History)
12 users (show)

Fixed In Version: 6.0.45
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-14 13:45:31 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Andrew Bartlett 2008-03-26 05:15:11 UTC
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):
mkinitrd-6.0.40-1.fc9

How reproducible:
Every time

Steps to Reproduce:
1. Install encrypted system with anaconda
2. Hibernate system
3. Unlock system
  
Actual results:
Noraml bootup (fixing dirty ext3)

Expected results:
Resume from hiberated (encrypted) swap

Additional info:

Fixed by changing (by hand) the line:
resume /sys/block/dm-3
to
resume /dev/mapper/Volume00-swap

Perhaps some of the long and convoluted code in:
https://bugzilla.redhat.com/attachment.cgi?id=243401
https://bugzilla.redhat.com/attachment.cgi?id=289833

might be of use?

In short, the code at line 1188 of mkinitrd gives a result that doesn't seem to
work.

Comment 1 Alex Lancaster 2008-04-03 11:14:50 UTC
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.

Comment 2 Charles R. Anderson 2008-04-04 01:05:28 UTC
*** Bug 439695 has been marked as a duplicate of this bug. ***

Comment 3 Alex Lancaster 2008-04-04 03:18:14 UTC
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:

resume /sys/block/dm-3

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 "

Comment 4 Shawn Starr 2008-04-07 23:36:42 UTC
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:

resume /dev//sys/block/dm-2



Comment 5 Jeremy Katz 2008-04-11 13:52:14 UTC
*** Bug 442006 has been marked as a duplicate of this bug. ***

Comment 6 Jeremy Katz 2008-04-11 15:56:44 UTC
Fixed in 6.0.44

Comment 7 Jeremy Fitzhardinge 2008-04-11 16:23:17 UTC
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.


Comment 8 Jeremy Katz 2008-04-11 20:38:02 UTC
*sigh*  Will be fixed in 6.0.45 which Peter is going to build shortly

Comment 9 Warren Togami 2008-04-12 05:01:34 UTC
*** Bug 442144 has been marked as a duplicate of this bug. ***

Comment 10 Jeremy Fitzhardinge 2008-04-12 05:13:46 UTC
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
uses /dev/mapper/vg00-root.)

Comment 11 Jeremy Fitzhardinge 2008-04-12 08:57:30 UTC
Successfully resumed.  6.0.45 looks like a fix.

Comment 12 Alex Lancaster 2008-04-12 14:16:06 UTC
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:

# pm-hibernate

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.  

Comment 13 Jeremy Fitzhardinge 2008-04-12 15:56:10 UTC
(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".

Comment 14 Charles R. Anderson 2008-04-13 21:49:16 UTC
Resuming with an initrd generated by 6.0.45 works for me:

resume /dev/l.sys/swap


Note You need to log in before you can comment on or make changes to this bug.