Red Hat Bugzilla – Bug 974803
anaconda/dracut: unable to find boot partition on BIOS RAID set using an AMD SATA controller
Last modified: 2015-04-14 09:52:31 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):
Steps to Reproduce:
1. Install F19 on this hardware
[ 124.898641] ehnintre dracut-initqueue: 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: ACTIVE '/dev/vgroot/lv_swap' [2.00 GiB] inherit
[ 124.965429] ehnintre dracut-initqueue: inactive '/dev/vgroot/lv_home' [564.22 GiB] inherit
[ 124.965574] ehnintre dracut-initqueue: ACTIVE '/dev/vgroot/lv_root' [29.31 GiB] inherit
[ 124.967297] ehnintre dracut-initqueue: PARTIAL MODE. Incomplete logical volumes will be processed.
[ 185.220281] ehnintre dracut-initqueue: Warning: Could not boot.
[ 185.222296] ehnintre dracut-initqueue: Warning: /dev/mapper/pdc_bchhfebjjep1 does not exist
A booted system.
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.
Created attachment 761726 [details]
report from booting after adding no_imsm from #743186
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.
Removing the RAID set completely and re-installing did work around the issue.. but obviously doesn't solve it for anyone else.
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
awesome. thanks for the info.
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
I should have time to reproduce this later this this week.
My weekend didn't work out as planned, not sure when I can attempt to reproduce. Close with not enough info if you want.
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.
Created attachment 819605 [details]
Created attachment 819606 [details]
Created attachment 819607 [details]
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’
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.
(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.
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'.
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.