Bug 166369 - mkinitrd assumes first swap entry in /etc/fstab is swsusp device
Summary: mkinitrd assumes first swap entry in /etc/fstab is swsusp device
Alias: None
Product: Fedora
Classification: Fedora
Component: mkinitrd
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Peter Jones
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2005-08-19 20:06 UTC by Alexandre Oliva
Modified: 2010-01-12 15:32 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2010-01-12 15:32:01 UTC

Attachments (Terms of Use)

Description Alexandre Oliva 2005-08-19 20:06:05 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8b3) Gecko/20050818 Fedora/1.1-0.2.7.deerpark.alpha2.1 Firefox/1.0+

Description of problem:
It would be nice if mkinitrd paid attention to pri= options for swap devices (assuming swsusp does too).  It's not clear to me what happens if multiple devices with the same priority are in use; I know the kernel will use them all simultaneously for swap, but how about swsusp?  Is it even predictable what device the kernel would use in this case?

It would also be nice if there was a way to have one device be used as the main swap device, and a different device used for swsusp.  E.g., I'd like to use external, fast&big disks for normal swapping, but I'd like to have my notebook set up to suspend to and from its internal disk, such that this works when it's most needed, namely, when I'm on the road.  I can come up with a script to move up the priority of the internal-disk swap device right before suspend, and then back down after the box comes back up, but then every time I update the kernel (almost daily, if tracking rawhide) I'd have to re-run mkinitrd with such a tweaked swap setting as well, such that it set things up properly.  If mkinitrd could take default settings to override the swsuspdev from a sysconfig file, it would be simple to get things to work the way I'd like.  Would such a change be acceptable?

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Set up a positive-priority swap device that is not the first swap entry in /etc/fstab
2.enable it
3.re-create initrd
5.try to resume

Actual Results:  Resume doesn't find the suspend image where it looked for it

Expected Results:  It should pay attention to priorities, and, ideally, use info from a sysconfig file to override /etc/fstab, that ideally the rest of the upcoming swsusp machinery should pay attention to as well.

Additional info:

Comment 1 Nigel Cunningham 2007-05-18 23:38:38 UTC
swsusp is only able to use one swap device. IIRC, it uses the one specified in
resume=, regardless of the order swapon'ed.

Since it doesn't look like there's any chance of upstream adding support for
multiple swap devices in the near future, I'd have to suggest using a suspend2
enabled kernel. It has support for all of the things you're after.

Comment 2 Alexandre Oliva 2007-05-19 02:44:01 UTC
This bug report is about mkinitrd not recording the primary swap device in
initrd.  I don't see how it relates with the comment of adding multiple swap
devices or the order of swapon.

The problem is that, given:

LABEL=SWAPsecondary           swap                    swap    pri=0           0 0
LABEL=SWAPprimary             swap                    swap    pri=1           0 0

it will record SWAPsecondary as the primary swap, just because it's listed
first, and then resume will fail to recover the state saved in SWAPprimary.

Comment 3 Nigel Cunningham 2007-05-19 05:51:38 UTC
Sorry. I was concentrating too much on what you said about swsusp, not the title
of the bug.

Comment 4 Hans de Goede 2009-02-04 21:23:16 UTC
So can anyone tell us when there is no resume= parameter which swap will be used by swsusp?

Comment 5 Jeremy Katz 2009-05-05 21:29:17 UTC
The kernel always uses the first swap device.

From kernel/power/Kconfig
         Note there is currently not a way to specify which device to save the
         suspended image to. It will simply pick the first available swap 

Comment 6 Alexandre Oliva 2009-05-06 16:42:39 UTC
First swap device, as far as the kernel is concerned, is not the same as first swap device listed in /etc/fstab.  That's precisely where pri= makes a difference, and this is precisely what this bug report is about.  mkinitrd does NOT use the first swap device, it uses the first entry in /etc/fstab.

Comment 7 Hans de Goede 2010-01-12 15:32:01 UTC
This is a mass edit of all mkinitrd bugs.

Thanks for taking the time to file this bug report (and/or commenting on it).

As you may have heard in Fedora 12 mkinitrd has been replaced by dracut. In Fedora 12 the mkinitrd package is still around as some programs depend on
certain libraries it provides, but mkinitrd itself is no longer used.

In Fedora 13 mkinitrd will be removed completely. This means that all work
on initrd has stopped.

Rather then keeping mkinitrd bugs open and giving false hope they might get fixed we are mass closing them, so as to clearly communicate that no more work will be done on mkinitrd. We apologize for any inconvenience this may cause. 

If you are using Fedora 11 and are experiencing a mkinitrd bug you cannot work around, please upgrade to Fedora 12. If you experience problems with the initrd in Fedora 12, please file a bug against dracut.

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