Bug 974803 - anaconda/dracut: unable to find boot partition on BIOS RAID set using an AMD SATA controller
anaconda/dracut: unable to find boot partition on BIOS RAID set using an AMD ...
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2013-06-15 22:48 EDT by Greg Swift
Modified: 2015-04-14 09:52 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-04-14 09:52:31 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
report from failed fresh install using DVD ISO of 19 beta (78.94 KB, text/plain)
2013-06-15 22:48 EDT, Greg Swift
no flags Details
report from booting after adding no_imsm from #743186 (78.88 KB, text/plain)
2013-06-15 22:50 EDT, Greg Swift
no flags Details
rdsosreport.txt (104.88 KB, text/plain)
2013-11-05 04:47 EST, Andreas Thienemann
no flags Details
anaconda.log (17.39 KB, text/plain)
2013-11-05 04:49 EST, Andreas Thienemann
no flags Details
storage.log (233.02 KB, text/plain)
2013-11-05 04:50 EST, Andreas Thienemann
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 743186 None None None Never

  None (edit)
Description Greg Swift 2013-06-15 22:48:25 EDT
Created attachment 761725 [details]
report from failed fresh install using DVD ISO of 19 beta

Description of problem:
I did a yum upgrade, and then a fresh install after that left me with a non-booting system.  Both ways I'm getting the same error where it can't seem to find the boot partition.  I'm not sure if Anaconda or its dependencies are lying to dracut, or what exactly.

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

How reproducible:

Steps to Reproduce:
1. Install F19 on this hardware
2. Reboot

Actual results:
[  124.898641] ehnintre dracut-initqueue[204]: Scanning devices dm-2  for LVM logical volumes vgroot/lv_swap vgroot/lv_root vgroot/lv_swap vgroot/lv_root
[  124.965251] ehnintre dracut-initqueue[204]: ACTIVE '/dev/vgroot/lv_swap' [2.00 GiB] inherit
[  124.965429] ehnintre dracut-initqueue[204]: inactive '/dev/vgroot/lv_home' [564.22 GiB] inherit
[  124.965574] ehnintre dracut-initqueue[204]: ACTIVE '/dev/vgroot/lv_root' [29.31 GiB] inherit
[  124.967297] ehnintre dracut-initqueue[204]: PARTIAL MODE. Incomplete logical volumes will be processed.
[  185.220281] ehnintre dracut-initqueue[204]: Warning: Could not boot.
[  185.222296] ehnintre dracut-initqueue[204]: Warning: /dev/mapper/pdc_bchhfebjjep1 does not exist

Expected results:
A booted system.

Additional info:

I've noticed that even though dracut seems to be looking at and working with pdc_bchhfebjjep1 that two other things are occurring:

1: During the installer anaconda refers to it as pdc_bchhfebjje1 (note the missing p)
2: In the Live CD or installer if I do a cat /proc/partitions I see sda as the base device, and the partitions are presented as dm-X devices.

I found a bug that looked extremely similar, but the proposed solution didn't work.  I'm assuming because it was Intel and this is AMD, but it didn't hurt to try.  I'll attach the sosreport from that run too.
Comment 1 Greg Swift 2013-06-15 22:50:04 EDT
Created attachment 761726 [details]
report from booting after adding no_imsm from #743186
Comment 2 Greg Swift 2013-06-15 22:51:48 EDT
also... I wouldn't be terribly against figuring out how to get rid of the RAID set, its an RAID0 that the system came with and I didn't really 'notice' at the time when I re-installed.  However i need to ensure my home partition is fully backed up first.
Comment 3 Greg Swift 2013-06-16 12:42:33 EDT
Removing the RAID set completely and re-installing did work around the issue.. but obviously doesn't solve it for anyone else.
Comment 4 Harald Hoyer 2013-06-17 07:33:51 EDT
This was because of bug 966162

    As per RHBZ #966162, parted stopped unconditionally using "p" as a
    separator for dmraid device names in version 3.1, so other things need
    to fall in line with that convention now.

So, maybe the installer image is not up2date.

Warning: /dev/mapper/pdc_bchhfebjjep1 does not exist

dm-name-pdc_bchhfebjje1 -> ../../dm-1

So, the dracut initramfs was created on a system with old udev rules or an old parted, which resulted in dracut wanting: pdc_bchhfebjjep1.

But the initramfs contains the new udev rules, which will result in pdc_bchhfebjje1 without "p" as a partition separator.

I hope, that as soon as the new parted/udev rules are part of the anaconda image, the installer will use the names without "p".

In such cases it is best to reboot with the recovery/rescue kernel and do:

# dracut -f --regenerate-all
Comment 5 Greg Swift 2013-06-17 09:23:27 EDT
awesome. thanks for the info.
Comment 6 Brian Lane 2013-06-18 20:22:58 EDT
When doing a clean install that fails please attach the /tmp/*log files to this bug as individual text/plain files. You can get to a shell using tmux on tty1 by hitting ctrl-B 2
Comment 7 Greg Swift 2013-06-18 22:53:23 EDT
I should have time to reproduce this later this this week.
Comment 8 Greg Swift 2013-06-25 12:24:54 EDT
My weekend didn't work out as planned, not sure when I can attempt to reproduce.  Close with not enough info if you want.
Comment 9 Andreas Thienemann 2013-11-05 04:46:03 EST
Reopening bug against Fedora 20.

In the installer, /dev/mapper/pdc_cigdfdegch1 is used.
The installed F20-Alpha system however has /dev/mapper/pdc_cigdfdegchp1. Note the additional p as a partition marker.

Recreating the initramfs and comparing the differences shows the culprit in the form of the devexists script which is referring the incorrect partition name.




Anaconda and dracut logs are attached.
Comment 10 Andreas Thienemann 2013-11-05 04:47:32 EST
Created attachment 819605 [details]
Comment 11 Andreas Thienemann 2013-11-05 04:49:13 EST
Created attachment 819606 [details]
Comment 12 Andreas Thienemann 2013-11-05 04:50:21 EST
Created attachment 819607 [details]
Comment 13 Øystein Bedin 2014-02-03 12:51:58 EST
I hit the same problem after upgrading F19 --> F20, running on a HP DL320 with HW raid, using LVM. In case anybody else experience this, I'm hoping that my workaround below may assist in bringing the system back to successfully booting:

1. Drop into the rescue shell and create a symlink to the boot partition in /dev/mapper with the same name but without the “p”, e.g.: 'ln -s /dev/mapper/ddf1_serverp1 /dev/mapper/ddf1_server1'
2. Exit the shell and wait for the system to boot
3. Remove the symlink - this is very important as the next step won't fix the problem otherwise. 
4. Run ‘dracut -f --regenerate-all’
Comment 14 Grant Byers 2014-02-23 17:55:47 EST
Hit the same problem with a clean install of Fedora 20 on an AMD white box with a RAID1 set on Promise Fasttrack RAID (BIOS RAID). Still working on a correct solution here. Unfortunately, I need to get this up ASAP, so I'm not in a position to test patches.
Comment 15 David Lehman 2014-02-24 14:50:32 EST
(In reply to Andreas Thienemann from comment #9)
> In the installer, /dev/mapper/pdc_cigdfdegch1 is used.
> The installed F20-Alpha system however has /dev/mapper/pdc_cigdfdegchp1.

The installer correctly uses no delimiter. After installation the system correctly expects no delimiter but what has been assembled in the initramfs does contain the delimiter. It sounds like the version of dracut used to create the F20 installation media includes code which incorrectly assembles dmraid devices.

Forgive me if this has all been figured out already. I would like to establish and document where this bug sits as of now.

Side note:
To be clear, the "correct" form is to include the 'p' delimiter only if the name of the "disk" device ends with a digit. So, for example, "ddf1_server1" is correct for the first partition on disk "ddf1_server". 

My opinion is that we should always use the same delimiter, regardless of any other factors. Changing the partition naming convention based on the name of the disk that contains it is completely insane IMO. I wish kpartx would just drop support for controlling the prefix and always use a delimiter of 'p'.
Comment 16 David Shea 2015-04-14 09:52:31 EDT
As far as I can tell from the comments here, and since no one has had an update to this in over a year, the problems were udev rules being out of sync between an initramfs and the installed system. If anyone can reproduce this problem with Fedora 21 or newer feel free to reopen the bug.

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