Bug 26726 - boot failure due RAID partitioning errors
Summary: boot failure due RAID partitioning errors
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: release_blocker critical
Target Milestone: ---
Assignee: Martin Whitaker
QA Contact:
URL:
Whiteboard: m8alpha1
Keywords:
Depends on:
Blocks:
 
Reported: 2020-06-04 14:06 CEST by Tony Blackwell
Modified: 2020-06-07 01:10 CEST (History)
3 users (show)

See Also:
Source RPM: dracut-050-1.mga8
CVE:
Status comment:


Attachments

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


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