Bug 1281535 - mdadm 3.3.4 - boot failure - problem with initramfs
Summary: mdadm 3.3.4 - boot failure - problem with initramfs
Keywords:
Status: CLOSED DUPLICATE of bug 912735
Alias: None
Product: Fedora
Classification: Fedora
Component: mdadm
Version: 23
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Doug Ledford
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-11-12 16:54 UTC by Jeremy Rimpo
Modified: 2016-01-11 17:55 UTC (History)
12 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2016-01-11 17:55:09 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Jeremy Rimpo 2015-11-12 16:54:23 UTC
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 19:43:01 UTC
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 16:36:13 UTC
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 18:20:41 UTC
4.2.5-200 does work under FC22, 201 is where it breaks lvm2.

Comment 4 Justin M. Forbes 2015-11-18 20:06:52 UTC
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 11:57:55 UTC
Correction, 4.2.3-200 is the last FC22 kernel to work for me.

Comment 6 Jeremy Rimpo 2015-11-26 09:01:21 UTC
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 15:07:22 UTC
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 20:57:45 UTC
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 17:55:09 UTC

*** 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.