Bug 1281535 - mdadm 3.3.4 - boot failure - problem with initramfs
mdadm 3.3.4 - boot failure - problem with initramfs
Status: CLOSED DUPLICATE of bug 912735
Product: Fedora
Classification: Fedora
Component: mdadm (Show other bugs)
23
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Doug Ledford
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-12 11:54 EST by Jeremy Rimpo
Modified: 2016-01-11 12:55 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-01-11 12:55:09 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jeremy Rimpo 2015-11-12 11:54:23 EST
Description of problem:
Though this might be related to the mdadm update, I am still able to boot with kernel 4.2.5.

Essentially, the system starts to boot but hangs almost immediately. If I drop into the busybox initramfs prompt, I can see that there are no partitions available for my LVM system/home/swap partitions, and I see no md### entries for the firmware drives.

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

How reproducible:
Every time this system boots. (I have another system that boots fine, which uses a true hardware RAID controller.)

Steps to Reproduce:
1. Update to 4.2.6 on my firmware raid system
2. Try to boot

Actual results:
System hangs at target 'Basic System' if I remember correctly. It's the third target.

Expected results:
Booting system.

Additional info:
I can't grab a journalctl as the system can't write the files. But the issue is definitely that it's unable to mount my partitions.
Comment 1 dan 2015-11-17 14:43:01 EST
Same thing with kernel 4.2.5-201 under FC22.  LVM volumes cannot be found.  Works fine under kernel 4.1.7-200.
Comment 2 Justin M. Forbes 2015-11-18 11:36:13 EST
So kernel 4.2.5 works with F23, but not with F22, kernel 4.2.6 does not work with either?
Comment 3 dan 2015-11-18 13:20:41 EST
4.2.5-200 does work under FC22, 201 is where it breaks lvm2.
Comment 4 Justin M. Forbes 2015-11-18 15:06:52 EST
That clears things up a lot. There were no changes between the 200 and 201 builds, 201 was a rebuild because the 200 kernels were signed with the wrong key for secureboot. Considering mdadm updated to mdadm-3.3.4-2.fc22  roughly the same time as the 201 update was submitted, and the F23 update for mdadm was just before the 4.2.6 kernel release,  it is looking like that is the culprit. Reassigning.
Comment 5 dan 2015-11-22 06:57:55 EST
Correction, 4.2.3-200 is the last FC22 kernel to work for me.
Comment 6 Jeremy Rimpo 2015-11-26 04:01:21 EST
The 4.2.6-301 kernel still does not work, while the 4.2.5 does (on 23). I do not believe the mdadm version matters here.

I can try downgrading it "just in case" soon, but it makes no sense to me that the new version would work on older kernels but not new kernels while the old version would.

I'm not even sure this is an lvm issue, as I do not see any firmware raid drives when the boot fails to dracut under /dev. There's a problem here detecting drives.
Comment 7 Justin M. Forbes 2015-11-26 10:07:22 EST
It makes perfect sense because you didn't recreate your initramfs when you upgraded mdadm.  Your old kernels still use the old versions in your initramfs. Any new kernel installed after the update would use the new.  As I said, there was zero difference between 200 and 201, the bump and rebuild was only to get the correct signature for secure boot on there. That clearly points out that it was not a kernel change which caused your issue.
Comment 9 Jeremy Rimpo 2015-11-27 15:57:45 EST
I wasn't getting the initramfs link. Now I understand the problem. I've tested this theory out and it appears to be correct. It seems that the boot process is broken in the newest mdadm, though the commands appear to run fine once booted.
Comment 10 Jeremy Rimpo 2016-01-11 12:55:09 EST

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

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