Bug 495580 - rescue mode doesn't see partitions (LVM + Raid)
rescue mode doesn't see partitions (LVM + Raid)
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: David Lehman
Fedora Extras Quality Assurance
Depends On:
Blocks: AnacondaStorage 495581
  Show dependency treegraph
Reported: 2009-04-13 16:39 EDT by Matthieu Araman
Modified: 2010-01-18 11:04 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-01-18 11:04:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Log from Anaconda (74.67 KB, text/plain)
2009-04-15 07:30 EDT, Leonhard Zachl
no flags Details
Anaconda Storage log (52.42 KB, text/plain)
2009-04-15 07:31 EDT, Leonhard Zachl
no flags Details
output of mdadm --examine (32.73 KB, text/plain)
2009-04-15 08:33 EDT, Leonhard Zachl
no flags Details
Anaconda log (29.34 KB, text/plain)
2009-04-17 12:22 EDT, Leonhard Zachl
no flags Details
Storage log (39.37 KB, text/plain)
2009-04-17 12:23 EDT, Leonhard Zachl
no flags Details
output of mdadm --examine /dev/sd?? (7.19 KB, text/plain)
2009-04-17 12:24 EDT, Leonhard Zachl
no flags Details
Program log (2.49 KB, text/plain)
2009-04-17 12:25 EDT, Leonhard Zachl
no flags Details
output of udevadm info --export-db (95.78 KB, text/plain)
2009-04-17 12:26 EDT, Leonhard Zachl
no flags Details
content of /proc/mdstat (265 bytes, text/plain)
2009-04-17 12:26 EDT, Leonhard Zachl
no flags Details

  None (edit)
Description Matthieu Araman 2009-04-13 16:39:25 EDT
Description of problem:
After bug 495575, my rawhide setup froze.
I tried to reboot with Fedora 11 beta in rescue mode and it no longer works.

Version-Release number of selected component (if applicable):
boot.iso install from 20090404 (see parent bug for setup)

How reproducible:
not completely.
Before the freeze, I could use Fedora 11 beta and load my system under /mnt/sysimage
After first try post freeze, I had a anaconda exception from the rescue mode when trying to load partition.
After reboot with fedora 11 beta, I could manually start raid, see lvm (but I don't know how to make the devices visible so I could try to fsck/mount from the rescue mode)
After another try with automatic detection, I've got "You don't have any linux partitions" 

Actual results:
partitions not seen

Expected results:
rescue mode should run after a system freeze with LVM+Raid setup

Additional info:
I could start the raid with mdadm --assemble --scan
cat /proc/mdstat shows /dev/md0 and /dev/md1 ok
lvm shows everything ok
I don't see the lvm partitions under /dev
How do I make them visible after starting raid when running rescue mode ?
Comment 1 Chris Lumens 2009-04-13 16:49:56 EDT
Please attach the traceback you are getting to this bug report so we can have some idea what's going on here.  Thanks.
Comment 2 Matthieu Araman 2009-04-13 17:30:31 EDT

when the rescue mode traceback occured, it just printed on the screen and asked for a reboot (it doesn't ask to file a bug like when you do the initial install). I didn't write it down as it was rather meaningless...
I just did 2 more reboots and now I can see my partitions backs with the rescue mode.
Not sure what made them come back
I manually started raid with mdadm --assemble --scan
I played with the lvm command :
- used all the display commands
- try an lvm export /import (may be that was it ?)

I will continue testing.
If this occurs again, may be I can try to switch to another console and transfert via network the anaconda.log and storage.log I just found under /tmp before rebooting.
Comment 3 David Lehman 2009-04-13 17:58:40 EDT
You should be able to just run rescue mode and let anaconda start your raid and lvm. You should not have to manually start anything.

If this fails (without you doing things manually on tty2) please attach /tmp/storage.log, /tmp/program.log, and /tmp/anaconda.log to this bug report so we can find out why we are unable to detect your setup.
Comment 4 Matthieu Araman 2009-04-13 19:12:44 EDT
I tried to replicate by stopping the os several times with poweroff but it seems I had turned off the system at a specific time and it's not that easy to replicate...
Comment 5 Leonhard Zachl 2009-04-15 07:29:23 EDT
think it's the same problem here:

i'm trying to update F11-alpha to F11-beta or Raw Hide
with 3 md devices

anaconda (and too) is unable to detect software raid devices
neither in install mode nor in rescue mode.

anaconda is mixing up the Preferred Minor Entry in the raid superblock

see attachments
Comment 6 Leonhard Zachl 2009-04-15 07:30:38 EDT
Created attachment 339667 [details]
Log from Anaconda
Comment 7 Leonhard Zachl 2009-04-15 07:31:49 EDT
Created attachment 339668 [details]
Anaconda Storage log
Comment 8 Leonhard Zachl 2009-04-15 08:33:04 EDT
Created attachment 339677 [details]
output of mdadm --examine

contains output of
mdadm --examine /dev/sd?2
mdadm --examine /dev/sd?1

after anaconda storage detection

after manual assembling of md-devices
Comment 9 Leonhard Zachl 2009-04-15 09:10:39 EDT
/proc/mdstat! not /proc/mdadm
Comment 10 Hans de Goede 2009-04-15 18:48:45 EDT
(In reply to comment #5)
> anaconda (and too) is unable to detect software raid
> devices
> neither in install mode nor in rescue mode.
> anaconda is mixing up the Preferred Minor Entry in the raid superblock

Thanks for the logs, can you be a bit more verbose about what you mean with
"anaconda is mixing up the Preferred Minor Entry in the raid superblock" ?

Comment 11 Leonhard Zachl 2009-04-16 08:17:31 EDT
as you see in the output of mdadm --examine /dev/sd?[12] in https://bugzilla.redhat.com/attachment.cgi?id=339677

the preferred minor was

6 for UUID 6fe653d2:4c0c45a9:dc316710:85b8eb81
4 for UUID 97d9f888:c32f99c9:a300e005:00ccdc18

after storage detection of anaconda
the superblock of one (the first?) device was changed

1 for /dev/sda2 of UUID 6fe653d2:4c0c45a9:dc316710:85b8eb81
2 for /dev/sdc1 of UUID 97d9f888:c32f99c9:a300e005:00ccdc18

manual assembling of the md-devices with mdadm will kick off
these changed devices, because of the different superblock
and have to be re-added
Comment 12 David Lehman 2009-04-16 21:16:50 EDT
It would be very useful if you could also provide the file /tmp/program.log and the full output of the command 'udevadm info --export-db', both taken from the installer environment at the time of the failure.
Comment 13 Leonhard Zachl 2009-04-17 12:22:20 EDT
Created attachment 340032 [details]
Anaconda log

different system with only 5 320G disks
same layout (3 md devs)
same problem
Comment 14 Leonhard Zachl 2009-04-17 12:23:23 EDT
Created attachment 340033 [details]
Storage log
Comment 15 Leonhard Zachl 2009-04-17 12:24:20 EDT
Created attachment 340034 [details]
output of mdadm --examine /dev/sd??
Comment 16 Leonhard Zachl 2009-04-17 12:25:09 EDT
Created attachment 340035 [details]
Program log
Comment 17 Leonhard Zachl 2009-04-17 12:26:04 EDT
Created attachment 340036 [details]
output of udevadm info --export-db
Comment 18 Leonhard Zachl 2009-04-17 12:26:43 EDT
Created attachment 340039 [details]
content of /proc/mdstat
Comment 19 David Lehman 2009-04-23 12:25:28 EDT
Please retest with anaconda- It has several changes that should improve this situation.
Comment 20 Matthieu Araman 2009-04-27 02:30:39 EDT
I've tested installation with boot.iso 20090424 on 20090426 (so using anaconda-
Disks partitionning are not recognized correctly at install time.

Before installation, I've got a working rawhide with LVM + RAID
Installation log files are here : http://plouic.com/fedora-matzilla/rawhide20090424/install-logs-anaconda-

my setup : 
2 disks 1To
sda and sdb
sda1 = 200Mb type Raid soft
sdb1 = 200Mb type Raid soft
-> /dev/md0 (raid1)
/dev/md0 contains /boot type ext3

sda2 and sdb2 type raid soft , rest of disk
/dev/md1 raid1 made of sda2 and sdb2
/dev/md1 contains a lvm setup.(see details in bug 495581)

At install time, Anaconda find some kind of strange setup :
/dev/sda1, /dev/sda2 and only dev/sdb1 type LVM (which is normally /dev/sdb2)
looking at storage.log, I think anaconda read first /dev/sda, then find /dev/sda1
As this is a md device, I think anaconda tries to start raid at this time.
Unfortunately as /dev/sdb hasn't yet been discovered, /dev/md0 is only found containing /dev/sda1
Raid things should be done only after disk discovery is finished.

I didn't retest rescue mode (only had tested with Beta) but rescue mode was better than install mode, which is still not good at discovery.
Comment 21 Bug Zapper 2009-06-09 09:46:53 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
Comment 22 Dennis Schafroth 2009-06-22 17:49:35 EDT
I am seeing something similar using released F11. 

Trying to get a rescue session running on a F10 using a cobbler pxe boot. 

the boot works, the anaconda in rescue starts, but msg "No Linux partitions found"

F10 is on one disk (and the only disk) and only using LVM.
Comment 23 Nate Straz 2009-08-11 13:13:03 EDT
I am hitting this with the released F11 anaconda images, version  Rescue mode finds no partitions then immediately reboots.
Comment 24 James Laska 2009-08-11 13:20:51 EDT
Moving to ASSIGNED based on comment#23
Comment 25 David Lehman 2009-09-22 15:55:58 EDT
Have any of you retested this with recent versions of anaconda such as the F12-Alpha?

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