Bug 1085784 - Logical volume detection failure in 3.13.8
Summary: Logical volume detection failure in 3.13.8
Keywords:
Status: CLOSED DUPLICATE of bug 1084766
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-04-09 11:02 UTC by Adam Huffman
Modified: 2014-04-28 12:29 UTC (History)
9 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-04-28 12:29:53 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
rdsosreport from the bad kernel, when booting has failed (101.56 KB, text/plain)
2014-04-09 11:02 UTC, Adam Huffman
no flags Details

Description Adam Huffman 2014-04-09 11:02:53 UTC
Created attachment 884474 [details]
rdsosreport from the bad kernel, when booting has failed

Description of problem:
This week we had a bad sector on a disk on a particular machine, meaning that we had to reboot into the vendor diagnostics (because the machine wouldn't boot). Once the disk was fixed, the machine still wouldn't boot. It wasn't finding the root logical volume. I was able to get around this by manually starting the MD device backing some of the LVs and activating them all. However, the names were all scrambled i.e. when I mounted the rootvol LV, a different LV was actually mounted. When I rebooted into the previous kernel (3.13.7), they were detected normally.

Version-Release number of selected component (if applicable):
kernel-3.13.8-200.fc20.x86_64

How reproducible:
Every time

Steps to Reproduce:
1. Boot system
2.
3.

Actual results:
System drops to dracut emergency shell

Expected results:
System boots normally

Additional info:

Comment 1 Chema Casanova 2014-04-23 06:38:34 UTC
I confirm the same behavior of my desktop system that is configured with a RAID. 

I reproduced it with the following kernels:

kernel-3.13.8-200.fc20.x86_64
kernel-3.13.9-200.fc20.x86_64
kernel-3.13.10-200.fc20.x86_64

I have no problems with the previous version.

kernel-3.13.7-200.fc20.x86_64

Comment 2 Michele Baldessari 2014-04-23 11:19:42 UTC
Can you verify that it is not due to a newer version of dracut that is not including some needed modules?

Is this raid software or via hw raid card? (lspci please)

thanks,
Michele

Comment 3 Chema Casanova 2014-04-27 23:05:59 UTC
(In reply to Michele Baldessari from comment #2)
> Can you verify that it is not due to a newer version of dracut that is not
> including some needed modules?

It was possible related, today I received after a yum update the 
dracut-037-11.git20140402.fc20.x86_64

Then I regenerated the the initramfs with

dracut -f initramfs-3.13.10-200.fc20.x86_64.img 3.13.10-200.fc20.x86_64

Reboot and this kernel now completes the boot process.. I've tried the same with the previous not-working kernel again 3.13.9-200.fc20.x86_64 and it solved the problem again.

After checking, it seems that in my case it was related to

https://bugzilla.redhat.com/show_bug.cgi?id=1084766

> 
> Is this raid software or via hw raid card? (lspci please)

I'm using Raid Software

Comment 4 Josh Boyer 2014-04-28 12:29:53 UTC

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


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