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 ?
Please attach the traceback you are getting to this bug report so we can have some idea what's going on here. Thanks.
Hello, 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 11.5.0.39 (and 11.5.0.44 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
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 and /proc/mdadm after anaconda storage detection and /proc/mdadm after manual assembling of md-devices
/proc/mdstat! not /proc/mdadm
(In reply to comment #5) > anaconda 11.5.0.39 (and 11.5.0.44 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" ? Thanks!
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 and 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 and 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] Anaconda log different system with only 5 320G disks same layout (3 md devs) same problem
Created attachment 340033 [details] Storage log
Created attachment 340034 [details] output of mdadm --examine /dev/sd??
Created attachment 340035 [details] Program log
Created attachment 340036 [details] output of udevadm info --export-db
Created attachment 340039 [details] content of /proc/mdstat
Please retest with anaconda-11.5.0.47-1. It has several changes that should improve this situation.
I've tested installation with boot.iso 20090424 on 20090426 (so using anaconda-11.5.0.47-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-11.5.0.47-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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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 11.5.0.59. 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?