Red Hat Bugzilla – Bug 166369
mkinitrd assumes first swap entry in /etc/fstab is swsusp device
Last modified: 2010-01-12 10:32:01 EST
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): mkinitrd-4.2.21-1 How reproducible: Always 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 4.swsusp 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:
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.
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.
Sorry. I was concentrating too much on what you said about swsusp, not the title of the bug.
So can anyone tell us when there is no resume= parameter which swap will be used by swsusp?
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 device.
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.
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.