Bug 1055015 - Dracut doesn't map the OCZ Revodrive dmraid partitions correctly
Summary: Dracut doesn't map the OCZ Revodrive dmraid partitions correctly
Alias: None
Product: Fedora
Classification: Fedora
Component: dracut
Version: 20
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: dracut-maint-list
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2014-01-18 00:31 UTC by Aaron Kling
Modified: 2014-04-06 02:37 UTC (History)
4 users (show)

Fixed In Version: dracut-037-10.git20140402.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-04-06 02:37:30 UTC
Type: Bug

Attachments (Terms of Use)
Attached rdsosreport.txt for prior comment by ejfowler@gmail.com (144.73 KB, text/plain)
2014-03-04 12:06 UTC, Eric Fowler
no flags Details

Description Aaron Kling 2014-01-18 00:31:28 UTC
Description of problem: When booted on another Fedora 20 install, my revodrive is mapped to /dev/sil_${id}#, where # is the partition number. When dracut tries to boot the drive, it maps the drive as /dev/sil_${id}p#. It adds a p like mmc/sdcards do. When I manually rename the devices and remove the p, my system loads the login page, but can't do anything else because the rest of the initialization did not continue when I exited emergency mode.

Version-Release number of selected component (if applicable): dracut-034-64.git20131205.fc20.1

How reproducible: Every time

Steps to Reproduce:
1. Install Fedora 20 with the root on an OCZ Revodrive (and maybe other similar SSDs)
2. Try to boot from the drive.

Actual results: Boot failure due to missing device.

Expected results: Successful boot.

Additional info: I described my situation in a more detail on fedoraforum (http://www.forums.fedoraforum.org/showthread.php?t=296515).

Perhaps related, though I doubt it, is something I mentioned in the forum post. When dracut starts to load, it says my raid is missing a device. But when it eventually falls back to emergency mode, the raid is mounted perfectly fine, albeit with incorrect names.

Comment 1 Harald Hoyer 2014-01-22 11:03:31 UTC
what is your kernel command line?

Comment 2 Aaron Kling 2014-01-22 13:48:51 UTC
root=/dev/mapper/sil_caabbibjaaae3 ro rootflags=subvol=root00 vconsole.font=latarcyrheb-sun16  rd.dm.uuid=sil_caabbibjaaae rhgb quiet LANG=en_US.UTF-8

That is what is in /boot/grub2/grub.cfg.

vconsole.font=latarcyrheb-sun16 $([ -x /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param || :) rd.dm.uuid=sil_caabbibjaaae rhgb quiet

That is what is in /etc/default/grub.

Comment 3 Harald Hoyer 2014-01-24 10:54:26 UTC
dracut uses: dmraid -ay -i --rm_partitions <dev>

So it seems like dmraid is adding the "p", which it should not. 

See also:

Comment 4 Aaron Kling 2014-01-24 14:45:17 UTC
Interesting. What would cause it to map differently during boot and after boot? Are the programs (or code paths) supposed to be different?

Either way, any thoughts on the last part of my request or should I file that against dmraid if it still happens once this is resolved?

Comment 5 Aaron Kling 2014-01-27 23:35:57 UTC
Okay, I can confirm comment #3 and I answered my own question. Using the default dmraid-activation.service script, everything is mapped correctly. That's using dmraid to create the device without partitions, then using kpartx to map the partitions. Changing the script to not call kpartx and removing the -p parameter from dmraid, essentially matching the command in #3, the partitions are mapped with the extra p.

Can this bug be re-assigned to dmraid, please?

Comment 6 Aaron Kling 2014-01-28 04:02:27 UTC
Sorry for so many comments, but I have more to report. I got my setup to boot with a simple patch to dmraid. On line 107 of lib/misc/lib_context.c, I changed the default partition separator from p to blank. That and relabelling my drive (selinux problems likely from my chroot tinkering) made my boot almost smooth. I'm sure a more elegant solution is needed to cover id's that end in a number, but I can use my custom patch for now.

However, even with that, I still have the problem of the initramfs not finding my full raid set on the first pass. It only finds one device and throws an error. Something waits for about 10 seconds then tries again and the boot continues correctly. I don't know where to start looking to try and debug that. Whether it's a dmraid or dracut issue. Maybe it's trying to build the raid set before all devices are enumerated. Can you or someone point me in the right direction?

Comment 7 Eric Fowler 2014-03-04 12:04:33 UTC
I just installed F20, I'm having similar issues. I run two LVM partitions for / on the third partition of OCZ Revodrive, each one with a different version, so I can revert if something blows up on install. They share a /home partition on a separate drive. 

The system was working fine with F18 on VolGrp00-LogVol01, I reclaimed VolGrp00-LogVol00 from F17 for the reinstall. I did not format /boot partition, which is the first partition on the OCZ raid device. the second partition is swap space. 

Now it won't boot to the new F20 or the old F18, but I can bring F20 up on the rescue environment just fine. I let dracut run its course and drop me to shell, then saved rdosreport.txt, attached. 

Not sure what steps to take next, please help, thx.

Comment 8 Eric Fowler 2014-03-04 12:06:22 UTC
Created attachment 870378 [details]
Attached rdsosreport.txt for prior comment by ejfowler@gmail.com

Comment 9 Fedora Update System 2014-04-02 08:57:18 UTC
dracut-037-10.git20140402.fc20 has been submitted as an update for Fedora 20.

Comment 10 Fedora Update System 2014-04-03 04:03:43 UTC
Package dracut-037-10.git20140402.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dracut-037-10.git20140402.fc20'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 11 Fedora Update System 2014-04-06 02:37:30 UTC
dracut-037-10.git20140402.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

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