Bug 1031512 - module-setup.sh - swap partition check based on "mount point" - "resume" from hibernate fails.
Summary: module-setup.sh - swap partition check based on "mount point" - "resume" from...
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: dracut
Version: 22
Hardware: All
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: dracut-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-11-18 07:39 UTC by james
Modified: 2016-07-19 20:03 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2016-07-19 20:03:40 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description james 2013-11-18 07:39:29 UTC
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
         done
         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:

Always

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 11:35:03 UTC
This is the code line, which prevents your "kswap" entry to be picked up:
http://git.kernel.org/cgit/boot/dracut/dracut.git/tree/dracut.sh#n940

Comment 2 james 2013-11-18 16:14:13 UTC
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 15:12:46 UTC
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:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

Comment 4 Fedora End Of Life 2016-07-19 20:03:40 UTC
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
bug.

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.