Bug 14861

Summary:	when swap UUID changes, initrd should be regenerated
Product:	Mageia	Reporter:	Morgan Leijström <fri>
Component:	RPM Packages	Assignee:	Mageia Bug Squad <bugsquad>
Status:	RESOLVED DUPLICATE	QA Contact:
Severity:	critical
Priority:	Normal	CC:	andresalaun, brianpeterson2, eeeemail, thierry.vignaud
Version:	Cauldron
Target Milestone:	---
Hardware:	All
OS:	Linux
Whiteboard:
Source RPM:	drakxtools	CVE:
Status comment:

Description Morgan Leijström 2014-12-20 18:54:52 CET

Example:

I deleted my swap partition (was in an encrypted lvm)
And made a new (in an unencrypted lvm)
Then the system refused to boot, saying:

dracut Warning: /dev/vg-krypt/swap does not exist
dracut Warning: /dev/mapper/vg-krypt/swap does not exist

and drops to debug shell.

Claire pointed me to her experience of similar situation at qa-discuss ML 2014-4-15.:
https://ml.mageia.org/wwsympa-wrapper.fcgi/arc/qa-discuss/2014-04/msg00032.html

The solution is to regenerate initrd.
It is not trivial, especially not for a normal user.
I summed it up as (for my system) and executed at debug shell:

mkdir /mnt
mount /dev/mapper/vg-mga--root /mnt
mount /dev/sda1 /mnt/boot
mount --bind /proc /mnt/proc
mount --bind /dev /mnt/dev
mount --bind /sys /mnt/sys
mount --bind /run /mnt/run
chroot /mnt
export DRACUT_SKIP_FORCED_NON_HOSTONLY=1
dracut -f
...I then rebooted it: OK.


Here are two issues:

1) the system should not refuse booting when a swap is missing.
As Florian pointed out on discuss ML there are several bug reports of variants of this already.  However in my case fstab entry had been updated correctly, and it was failing on something pointing to swap somewhere else (in initrd?) - i did not find that covered ?

2) diskdrake should run dracut when it exits if a swap have been changed.
(or some other operation that fix it)

Reproducible: 

Steps to Reproduce:

Morgan Leijström 2014-12-20 18:55:23 CET

Priority: Normal => release_blocker

Comment 1 Morgan Leijström 2014-12-20 19:51:02 CET

I forgot to say i used diskdrake to change partitions.

Comment 2 Thierry Vignaud 2014-12-21 11:49:27 CET

Indeed I already got caught by that bug.
But this cannot be release critical as this bug exists for many releases.
Also not that many people would recreate their swap.

Priority: release_blocker => Normal
CC: (none) => thierry.vignaud

Comment 3 Morgan Leijström 2014-12-21 11:54:53 CET

I think i got hit earlier too, not knowing what hit and reinstalled instead.

OK
 2) (not updating initrd) is not so critical if
 1) the boot could just boot without finding that old swap.

claire robinson 2014-12-21 18:16:46 CET

CC: (none) => eeeemail

Comment 4 brian peterson 2015-02-20 07:49:01 CET

apparently here too this problem occurs if one uses diskdrake (from Mageia control center/Partition) to remove the swap partition from a standard install

The partition tool successfully removes the swap entry from /etc/fstab but the boot then fails.

Attempting to remove resume= from grub's menu.lst which deals with the swap partition didn't help..

I reinstalled the bootloader using the installer rescue mode but this didn't fix     it.. I applied dracut and this gets booting back to normal so this is good

If the tool diskdrake can remove the swap partition properly from the fstab file, it should also remove itself from resume= in grub's configuration... and I think here too initrd needs to be updated... or even a message to the end-user.. as long as he or she can get their system booted up after a swap change or in my case completely removing the swap.

I noticed I'm not the only one who stumbled on this.. perhaps this bug should indeed finally be fixed even though few people would bother changing it, the thing is if the tool edits /etc/fstab for the user, it might as well do the rest of the magic, but if the tool breaks the boot then I think this should be fixed.

CC: (none) => brianpeterson2

Comment 5 Manuel Hiebel 2015-05-14 16:06:08 CEST

*** Bug 14502 has been marked as a duplicate of this bug. ***

CC: (none) => andresalaun

Comment 6 Manuel Hiebel 2015-05-14 16:09:32 CEST

another dup in fact

*** This bug has been marked as a duplicate of bug 14759 ***

Status: NEW => RESOLVED
Resolution: (none) => DUPLICATE