Bug 26726

Summary:	boot failure due RAID partitioning errors
Product:	Mageia	Reporter:	Tony Blackwell <tablackwell>
Component:	RPM Packages	Assignee:	Martin Whitaker <mageia>
Status:	RESOLVED FIXED	QA Contact:
Severity:	critical
Priority:	release_blocker	CC:	davidwhodgins, mageia, thierry.vignaud
Version:	Cauldron
Target Milestone:	---
Hardware:	All
OS:	Linux
Whiteboard:	m8alpha1
Source RPM:	dracut-050-1.mga8	CVE:
Status comment:

Description Tony Blackwell 2020-06-04 14:06:32 CEST

Description of problem: x86_64 UEFI install on system with lots of disks, installation to RAID0, volume1P3, has working M7 on Volume1P2.
Apparently successful installation, install recognised the RAID.
Boot failed:
dracut Warning: /dev/disk/by-uuid/62dbc600-3e19-4000-0007-ff0ec9271ddf does not exist
dracut warning: /dev/mapper/isw-bdjgiebedg-Volume1p1 does not exist.

My comment: Volume1p1 is the EFI partition, which M7 on that machine uses happily.
When, from the emergency # prompt, I look in /dev/mapper, it contains control and isw-bdjgiebedg-Volume1, but not volume1p1, volume1p2, volume1p3 as I would expect.

Sorry couldn't dump the rdsosreport.txt file as I couldn't mount an inserted memory stick to dump it to; mount failed with 
FAT-fs (sdl1): codepage cp437 not found

So, the install proceeds apparently normally, installing itself to Volume1p3 as intended (installation files are readable there from subsequent boot of the prior M7 installation on Volume1p2).  The setup of /dev/mapper appears to be in error however, so boot fails


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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Tony Blackwell 2020-06-04 14:07:34 CEST

Whiteboard: (none) => m8alpha1

Comment 1 Lewis Smith 2020-06-04 21:18:03 CEST

Thanks for the report, Tony.

Quite unsure where to push this sort of bug, of which we are going to get plenty in the near future. Starting with kernel & tv; please say where might be better.
I am leaving myself CC'd to find out.

Assignee: bugsquad => kernel
CC: (none) => lewyssmith, thierry.vignaud

Comment 2 Martin Whitaker 2020-06-05 18:45:28 CEST

Do you have a non-RAID disk in the system. If so, you could try mounting a partition on that disk and copying the rdsosreport.txt file there. Otherwise, try a USB stick with an ext2 filesystem.

Also, please attach the /root/drakx/report.bug.xz from the mga8 system, and the log file generated by

  lsinitrd ./initrd.img > ls-initrd.log

when run (as root) in /boot of the mga8 system.

Keywords: (none) => NEEDINFO
CC: (none) => mageia

Comment 3 Lewis Smith 2020-06-05 20:16:22 CEST

Thanks for jumping on it, Martin.
Removing my own CC.

CC: lewyssmith => (none)

Comment 4 Martin Whitaker 2020-06-06 14:48:10 CEST

No need for the info - I've reproduced the fault and identified the upstream change in dracut that is causing it.

Component: Installer => RPM Packages
Source RPM: (none) => dracut-050-1.mga8
Priority: Normal => release_blocker
Keywords: NEEDINFO => (none)
Assignee: kernel => mageia

Comment 5 Martin Whitaker 2020-06-06 17:02:32 CEST

Fixed in dracut-050-2.mga8.

To get your current system to boot, when dracut drops to the debug shell, enter the command

  kpartx -a /dev/mapper/isw-bdjgiebedg-Volume1

then exit the shell. If that works, install the updated dracut package and then run

  dracut -f

to rebuild the initrd image. The next boot should complete without error.

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

Dave Hodgins 2020-06-07 01:10:48 CEST

CC: (none) => davidwhodgins