Red Hat Bugzilla – Bug 495580
rescue mode doesn't see partitions (LVM + Raid)
Last modified: 2010-01-18 11:04:29 EST
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)
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"
partitions not seen
rescue mode should run after a system freeze with LVM+Raid setup
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 ?
Please attach the traceback you are getting to this bug report so we can have some idea what's going on here. Thanks.
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.
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.
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...
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 220.127.116.11 (and 18.104.22.168 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
Created attachment 339667 [details]
Log from Anaconda
Created attachment 339668 [details]
Anaconda Storage log
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
/proc/mdstat! not /proc/mdadm
(In reply to comment #5)
> anaconda 22.214.171.124 (and 126.96.36.199 too) is unable to detect software raid
> 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" ?
as you see in the output of mdadm --examine /dev/sd? 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
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.
Created attachment 340032 [details]
different system with only 5 320G disks
same layout (3 md devs)
Created attachment 340033 [details]
Created attachment 340034 [details]
output of mdadm --examine /dev/sd??
Created attachment 340035 [details]
Created attachment 340036 [details]
output of udevadm info --export-db
Created attachment 340039 [details]
content of /proc/mdstat
Please retest with anaconda-188.8.131.52-1. It has several changes that should improve this situation.
I've tested installation with boot.iso 20090424 on 20090426 (so using anaconda-184.108.40.206-1)
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-220.127.116.11-1.tar
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.
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:
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.
I am hitting this with the released F11 anaconda images, version 18.104.22.168. Rescue mode finds no partitions then immediately reboots.
Moving to ASSIGNED based on comment#23
Have any of you retested this with recent versions of anaconda such as the F12-Alpha?