FIXED: diskdrake failed removing swap path from two location

[morgano]

The root partition on my wifes laptop was getting full.
root, home and swap is in a lvm, using one luks encrypted pv, for which I give key on boot.
Outside lvm there is EFI and boot partitions, and this partition I now change from Windows to swap.
The windows partition have not been used for five years, so I decided to use it for swap, instead for the current swap lv in the lvm.
Yes i know swap will after this change be unencrypted, but not important.

Easy, I thought, firing up diskdrake, let it in the lvm remove the swap, and extend root.
And the windows partition I deleted and let it create it anew as swap.
diskdrake asked me if to write fstab, i answered yes.

I know diskdrake have failed me before when removing swap in lvm, so I checked fstab and find it is correct.

But, failures:
Upon boot it times out after a couple minutes saying the swap can not be found, and i see it was trying the old location.
Dropping to dracut shell.
Rebooting to Grub where I see it use the parameter resume= pointing to old swap location. So I delete that whole resume= entry and let it boot, but it again fail trying the old location.

It fails me to find where, except fstab (which is correct) the path to swap is recorded.
And how to correct it.
After correcting that, I guess one need to run dracut -f to fix the kernel command line parameter resume= ?
(and open yet another bug for diskdrake)

Painfully I remember someone telling me before and I may have been exactly here before... Still this seem like in empty slot in my brain
Currently that machine is booted using sysresccd live USB and I have opened and mounted that Mageia root partition.
So what should I do now?

(Yes it would have been much easier to instead change the windows partition to an luks encrypted pv and add it to lvm, but user would then need to enter key twice each boot, or be automated in some way I lack skill in totally)

EDIT: I got hit there too - did not solve it but worked around instead by reverting the deletion and adding a pv. Nothing was encrypted anyway.

EDIT2: Workaround: I manually using the live system created a tiny 100MB lv of exact same name as the one I removed before, so now system boots and works. I did not format it (mkswap) so it is really not used as swap. It do use the other swap outside lvm, and that one is in fstab, so system report 16GB swap. Now I wish to know how to make system forget about that tiny "swap" and later remove it after making sure hibernation-resume also use the new swap.

[doktor5000]

It fails me to find where, except fstab (which is correct) the path to swap is recorded.
And how to correct it.
After correcting that, I guess one need to run dracut -f to fix the kernel command line parameter resume= ?

There are basically two other places apart from fstab. One is the UUID in /etc/dracut.conf.d/51-mageia-resume.conf where it also needs to be updated manually, afterwards you need to run

Code: Select all

dracut -f --regenerate-all

The other place is in /etc/default/grub where the resume= option is normally set to swap by default and it needs to be updated there as well, afterwards
run update-grub2 to actually write the bootloader config, as otherwise you'd still be able to boot but not be able to resume AFAIR.

[morgano]

Thank you doktor
Now i know what to try next time.
Unfortunatey i messed up booting somehow by playing with dracut before editing the files, and failed to boot it up again.
Anyway by booting live system i verified diskdrake forgot to change those files. Will open bug.

I am writing this from the fresh reinstalled system... (/home backup restore in progress, and program installations)
We dont need a swap the size of a windows partition, so now the encrypted lvm pv covers all disk except tiny ESP and /boot partitions.
And yes i did check SMART status of this well used SSD, no errors nor warnings.

I was thinking to use swapfile instead of partition, but i learned that for hibernation there is some manual work and now I know (we think) how to cover up for diskdrake next time i use it to change swap...

[canadaist]

Isnt this a bug?

[sturmvogel]

Not really. You need to be aware that moving/removing swap affects different parts of your system which are handled by different tools. It is nearly impossible or not worth the amount of work to press this in a all-at-once solution.

Disk layout -> fstab -> diskdrake
resume option -> grub -> update-grub2
UIID -> 51-mageia-resume.conf -> dracut

[morgano]

Our tool fools the user - even experineced ones- that it handle swap, but may render system unbootable. Very deceptive!
As it seem well known to break so bad that system fail to boot even to normal command line it should at least warn.

Another effect of diskdrake not handling swap fully, is that when not creating swap partition at installation (i was pondering using swap file instead), that when later using diskdrake to add swap, it do not execute the steps described by doctor5000 - for example /etc/dracut.conf.d/51-mageia-resume.conf was not created.
The danger is that desktop (at least Plasma) assume hibernate to work and offer it. Result: hibernation saving is executed, but it can not restore, so user lost that session.
After manually performing the steps described by doktor, system succeed restoring session after hibernation.

I will open a bug: Fix or make it warn.

[canadaist]

I agree, wholeheartedly.

[morgano]

Bug 33787 - Diskdrake do not handle swap fully - should do, or warn and explain. (critical)