Bug 21823 - dracut creates not bootable initrd images after removing a raid volume
Summary: dracut creates not bootable initrd images after removing a raid volume
Status: RESOLVED OLD
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 6
Hardware: x86_64 Linux
Priority: Normal major
Target Milestone: ---
Assignee: Base system maintainers
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-10-09 17:44 CEST by peter lawford
Modified: 2020-08-02 22:28 CEST (History)
4 users (show)

See Also:
Source RPM: dracut
CVE:
Status comment:


Attachments
return of lsinitrd for the actual initrd-4.9.50-desktop-1.mga6.img (67.49 KB, text/plain)
2017-10-09 17:47 CEST, peter lawford
Details
return of lsinitrd for the initrd-4.9.50-desktop-1.mga6.img of 10/4th/2017 which doesn't work (67.72 KB, text/plain)
2017-10-09 17:50 CEST, peter lawford
Details

Description peter lawford 2017-10-09 17:44:40 CEST
Description of problem:my mageia6 lies on a lvm:
pvs: /dev/sdh[23]
vg:  vgmagaux
lvs: on sdh2: vgmagaux/lvbootmagaux, vgmagaux/lvrootmagaux, vgmagaux/lvusrmagaux, vgmagaux/lvvarmagaux
     on sdh3:  vgmagaux/lvhomemagaux

a couple of days ago, I've met booting problems withe dracut's error messages, but finally the boot process ended succesfully; I decided to create a new initrd.img with dracut:

[root@magaux alain4]# dracut -v --add "lvm mdraid" vmlinuz-4.9.50-desktop-1.mga6 4.9.50-server-1.mga6

but before I have backuped the old image:

[root@magaux alain4]# mv -v /boot/vmlinuz-4.9.50-desktop-1.mga6 /boot/vmlinuz-4.9.50-desktop-1.mga6.old

I've tried to boot with the new initrd.img I'd created withe dracut, and the boot process aborted, with the message: dracut could not boot

from now on, I use the ancient image:

[root@magaux alain4]# mv -v /boot/vmlinuz-4.9.50-desktop-1.mga6.old /boot/vmlinuz-4.9.50-desktop-1.mga6
 which works

appended files:
return of the command lsinitrd for actual image and the one I have created with dracut on 10/4th/2017 and which doesn't work: what is strange is they are identical excepted the date of creation





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


How reproducible:


Steps to Reproduce:
1.
2.
3.
Comment 1 peter lawford 2017-10-09 17:47:54 CEST
Created attachment 9714 [details]
return of lsinitrd for the actual initrd-4.9.50-desktop-1.mga6.img
Comment 2 peter lawford 2017-10-09 17:50:33 CEST
Created attachment 9715 [details]
return of lsinitrd for the initrd-4.9.50-desktop-1.mga6.img of 10/4th/2017 which doesn't work
Comment 3 peter lawford 2017-10-09 17:53:35 CEST
NB: I use only legacy-grub for booting
I don't meet this problem with my mageia5
Comment 4 peter lawford 2017-10-09 19:31:56 CEST
ERRATUM: in the description of the problem, it should be read:
initrd-4.9.50-desktop-1.mga6  and not vmlinuz-4.9.50-desktop-1.mga6
Marja Van Waes 2017-10-10 15:01:22 CEST

Assignee: bugsquad => basesystem
Source RPM: (none) => dracut
CC: (none) => mageia, marja11

Comment 5 peter lawford 2017-10-18 01:00:02 CEST
the problem is fixed, but the bug is not solve
I just discovered that dracut_desktop_content.04.10.2017 and dracut_desktop_content.21.09.2017 slightly differ of two lines: 
284  -rw-r--r--   1 root     root           58 Oct  4 11:37 usr/lib/dracut/hooks/emergency/80-\\x2fdev\\x2fmd127.sh 
and
289  -rw-r--r--   1 root     root           20 Oct  4 11:37 usr/lib/dracut/hooks/initqueue/finished/devexists-\\x2fdev\\x2fmd127.sh
which belong to drac_desk_ 04.10, but not to the other.
md127 is an old -l0 -n6 raid volume I used as swap space, but which caused troubles since in the other systems it was known as md123; I have removed it:
# swapoff /dev/md127
# mdadm --stop /dev/md127
# mdadm --zero-superblock /dev/<components_of_md127>
and swap is now on a physical hd partition
but clearly mageia6 kept a trace of this volume somewhere in its machinery
since I evenly backup mageia6 with dump, I have restored it at a step before the latter one, where md127 didn't appear
now dracut creates clean initrd's which are bootable, and everything goes OK
but I consider that the bug is not solved, since I don't know why and where the system keeps a trace of a regularly removed raid volume, and why because that dracut creates non bootable initrd's
Comment 6 Marja Van Waes 2017-10-18 10:12:46 CEST
(In reply to peter lawford from comment #5)

> md127 is an old -l0 -n6 raid volume I used as swap space, but which caused
> troubles since in the other systems it was known as md123; I have removed it:
> # swapoff /dev/md127

Did you also remove it from /etc/fstab when you did that?

> # mdadm --stop /dev/md127
> # mdadm --zero-superblock /dev/<components_of_md127>
Comment 7 peter lawford 2017-10-18 12:24:51 CEST
(In reply to Marja van Waes from comment #6)
> (In reply to peter lawford from comment #5)
> 
> > md127 is an old -l0 -n6 raid volume I used as swap space, but which caused
> > troubles since in the other systems it was known as md123; I have removed it:
> > # swapoff /dev/md127
> 
> Did you also remove it from /etc/fstab when you did that?
> 
> > # mdadm --stop /dev/md127
> > # mdadm --zero-superblock /dev/<components_of_md127>

yes I did of course! when I change anything in my system /etc/fstab is the first file I update
Comment 8 peter lawford 2017-10-18 12:26:32 CEST
...and /etc/mdadm.conf too
Comment 9 Thomas Backlund 2017-10-18 12:33:59 CEST
If you alter mdadm.conf after a kernel is installed, then initrd needs to be re-created/updated to drop the references to the removed devices...

CC: (none) => tmb

Comment 10 peter lawford 2017-10-18 12:56:56 CEST
(In reply to Thomas Backlund from comment #9)
> If you alter mdadm.conf after a kernel is installed, then initrd needs to be
> re-created/updated to drop the references to the removed devices...

it's exactly I did, after dropping md127 and it's components from mdadm.conf, I "dracutted" to create a new initrd, and although that, the lines #284 and #289 remained in initrd's content
Thierry Vignaud 2017-10-18 14:49:38 CEST

Summary: dracut creates not bootable initrd images => dracut creates not bootable initrd images after removing a raid volume

Comment 11 Aurelien Oudelet 2020-08-02 22:28:12 CEST
This message is a reminder that Mageia 6 is end of life.

Mageia stopped maintaining and issuing updates for Mageia 6. At that time this bug will be closed as OLD (EOL).

Package Maintainer: If you wish for this bug to remain open because you plan to 
fix it in a currently maintained version, simply change the 'version' to a later 
Mageia version prior to Mageia 6's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we cannot 
be able to fix it before Mageia 6 was end of life.
If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia.

Although we aim to fix as many bugs as possible during every release's lifetime, 
sometimes those efforts are overtaken by events. Often a more recent Mageia 
release includes newer upstream software that fixes bugs or makes them obsolete.

--
Mageia Bugsquad

Resolution: (none) => OLD
CC: (none) => ouaurelien
Status: NEW => RESOLVED


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