Bug 1031512 - module-setup.sh - swap partition check based on "mount point" - "resume" from hibernate fails.
module-setup.sh - swap partition check based on "mount point" - "resume" from...
Product: Fedora
Classification: Fedora
Component: dracut (Show other bugs)
All Linux
unspecified Severity low
: ---
: ---
Assigned To: dracut-maint
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-11-18 02:39 EST by james
Modified: 2016-07-19 16:03 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-07-19 16:03:40 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description james 2013-11-18 02:39:29 EST
Description of problem:

"/usr/lib/dracut/modules.d/95resume/module-setup.sh" has

 check() {
     # No point trying to support resume, if no swap partition exist
     [[ $hostonly ]] || [[ $mount_needs ]] && {
         for fs in "${host_fs_types[@]}"; do
             [[ $fs = swap ]] && return 0
         return 255

     return 0

But then, this seems to actually read the "mount point" parameter from /etc/fstab, instead of the "file system type".  So, if the "mount point" for the swap partition is given some useful distinguishing name, like "kswap" instead of "swap", the detection fails, and consequently, "resume" from hibernation will fail.  Rather than being "no point to trying to support resume", this "check()" function seems to be "worse than useless", as it causes "resume" from hibernation to fail with a perfectly good swap partition.

This apparent requirement that the swap "mount point" be named "swap" does not appear to be documented in dracut.  The "fstab" man page suggests the mount point label be "none", since the swap partition is arguably not actually "mounted" at all.  "Following the man page" would also lead to a "resume" failure.

Mindless fix - change "return 255" to "return 0", to disable this "check()" function and always "support resume".

On the other hand, if the actual "file system type" is checked, instead of the "mount point", then the "fs type" for the swap partition will likely always be labeled as "swap", and the swap partition detection would succeed, without regard to the "mount point" label chosen.

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

Arch Linux
dracut 034-1

How reproducible:


Steps to Reproduce:
1. sudo vim /etc/fstab
2. change the second field of the swap partition entry to "kswap"
3. sudo dracut -f
4. sudo pm-hibernate
5. reboot
6. "PM: Hibernation image not present or could not be loaded."
Comment 1 Harald Hoyer 2013-11-18 06:35:03 EST
This is the code line, which prevents your "kswap" entry to be picked up:
Comment 2 james 2013-11-18 11:14:13 EST
Hmm - I'd suggest that line 939,

        [[ $_t != "swap" ]] && continue

should be considered "definitive", and that the subsequent line 940,

        [[ $_m != "swap" ]] && [[ $_m != "none" ]] && continue

is overly and unnecessarily restrictive.

As I understand, the "mount point" label in /etc/fstab for a swap partition is of no consequence, and can be chosen arbitrarily.  Especially in the days of yore, when swap partitions were listed by "mount", many people considered the line "/dev/hda1 on none" to be kind of silly, since the partition was certainly connected "somewhere", and yet using the same label for mount point and for file system type gave "/dev/hda1 on swap type swap", which was also kind of silly, because "swap" and "swap" were difficult to distinguish, one being a mount point and the other being a file system type.

There is no point in "forcing" policy for something that is of no consequence, forcing the swap partition mount point label in /etc/fstab.  And being unnecessarily restrictive makes dracut more brittle, rather than more robust.

I would suggest deleting line 940.
Comment 3 Jaroslav Reznik 2015-03-03 10:12:46 EST
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
Comment 4 Fedora End Of Life 2016-07-19 16:03:40 EDT
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this

Thank you for reporting this bug and we are sorry it could not be fixed.

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