This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 438951 - wrong swap dev causes resume failure
wrong swap dev causes resume failure
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
rawhide
All Linux
medium Severity high
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
:
: 439695 442006 442144 (view as bug list)
Depends On:
Blocks: F9PR
  Show dependency treegraph
 
Reported: 2008-03-26 01:15 EDT by Andrew Bartlett
Modified: 2008-06-16 21:17 EDT (History)
12 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description Andrew Bartlett 2008-03-26 01:15:11 EDT
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 07:14:50 EDT
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-03 21:05:28 EDT
*** Bug 439695 has been marked as a duplicate of this bug. ***
Comment 3 Alex Lancaster 2008-04-03 23:18:14 EDT
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 19:36:42 EDT
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 09:52:14 EDT
*** Bug 442006 has been marked as a duplicate of this bug. ***
Comment 6 Jeremy Katz 2008-04-11 11:56:44 EDT
Fixed in 6.0.44
Comment 7 Jeremy Fitzhardinge 2008-04-11 12:23:17 EDT
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 16:38:02 EDT
*sigh*  Will be fixed in 6.0.45 which Peter is going to build shortly
Comment 9 Warren Togami 2008-04-12 01:01:34 EDT
*** Bug 442144 has been marked as a duplicate of this bug. ***
Comment 10 Jeremy Fitzhardinge 2008-04-12 01:13:46 EDT
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 04:57:30 EDT
Successfully resumed.  6.0.45 looks like a fix.
Comment 12 Alex Lancaster 2008-04-12 10:16:06 EDT
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 11:56:10 EDT
(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 17:49:16 EDT
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.