Bug 1229289 - firmware raid drive not detected at boot
Summary: firmware raid drive not detected at boot
Keywords:
Status: CLOSED DUPLICATE of bug 1201962
Alias: None
Product: Fedora
Classification: Fedora
Component: dracut
Version: 22
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: dracut-maint-list
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-06-08 11:42 UTC by Eric Bakkum
Modified: 2015-06-16 13:27 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-06-08 13:07:31 UTC


Attachments (Terms of Use)
rdsosreport from failing F22 dracut boot (84.31 KB, text/plain)
2015-06-08 11:42 UTC, Eric Bakkum
no flags Details
rdsosreport from succesful F21 boot (86.32 KB, text/plain)
2015-06-08 11:44 UTC, Eric Bakkum
no flags Details

Description Eric Bakkum 2015-06-08 11:42:20 UTC
Created attachment 1036320 [details]
rdsosreport from failing F22 dracut boot

I was running the F21 xfce spin on my multiboot Intel Matrix raid-0 system. FedUpped to F22, and the upgrade completed successfully. The post-upgrade reboot however dropped into the dracut emergency shell with "Warning: /dev/disk/by-uuid/<uuid of raid partition>" does not exist". It appears that the /dev/md126 and /dev/md127 were not created, and /proc/mdstat shows no "Personalities", so the boot process appears to fail in finding the raid device containing the F22 boot partition.

Other reported bugs like
	https://bugzilla.redhat.com/show_bug.cgi?id=1225184
	https://bugzilla.redhat.com/show_bug.cgi?id=1219264
look similar although the big difference is that my upgrade completed successfully, and the problems only appeared at boot.

The interesting part is that I can still successfully boot to the F21 kernel images that the Fedup process obviously did not remove. In this case however the system runs with a mix of F21 and F22 packages which does not feel like a healthy approach.

The rdsosreport.txt of the failing F22 boot is attached. I also forced a break into dracut with the F21 boot and attach the corresponding rdsosreport.txt as well.

To complete the story: I also tried installing the xfce spin with the live image, and even with the server live image. Both dropped in dracut ar reboot just like with the Fedup procedure.

This is my first bug report, so please let me known what else may be of help.

Comment 1 Eric Bakkum 2015-06-08 11:44:32 UTC
Created attachment 1036324 [details]
rdsosreport from succesful F21 boot

Comment 2 Eric Bakkum 2015-06-08 13:07:31 UTC
After further investigation I found
   https://bugzilla.redhat.com/show_bug.cgi?id=1223017
   https://bugzilla.redhat.com/show_bug.cgi?id=1201962

With the addition of "rd.auto" on the kernel command line as per bug 1201962 the F22 boot succeeds, so this problems appears to be a duplicate of the latter.

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

Comment 3 Harald Hoyer 2015-06-16 13:02:11 UTC
Your kernel command line does not contain any information, that dracut should assemble a raid "root=UUID=99cbd9ec-c54c-4bdb-997d-338264f5f568 ro" ..

Please consider adding the info for the raid to the kernel command line, so you would not need rd.auto.

# dracut --print-cmdline 

should give you the hint what to add.

Comment 4 Eric Bakkum 2015-06-16 13:27:44 UTC
(In reply to Harald Hoyer from comment #3)
Yes, thanks.

Actually I first found out about the rd.auto from the description of bug 1201962 so after that I closed this report.
Lateron I found out about the "dracut --print-cmdline" from your webpage at kernel.org, and added the "rd.md.uuid=..." to the kernel command line. It works fine now.

So it turns out that my problem was caused by FedUp apparently not adding the rd.md.uuid, while is was not needed in F21. In F21 the uuid was set in initramfs /etc/cmdline.d/90raid.conf which is not the case anymore in F22. That was an intentional change I suppose.


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