Red Hat Bugzilla – Bug 994231
Fedora 19's installer absolutely will not deal with a certain software raid configuration
Last modified: 2013-08-13 12:32:19 EDT
Description of problem: Fedora 19's installer will not even start with my system's configuration -- anaconda dies before any gui operations happen. Version-Release number of selected component (if applicable): Fedora 18 installed. Trying to install Fedora 19. How reproducible: Every time I boot off the F19 dvd on my system. Steps to Reproduce: The key components of my system : # df Filesystem 1K-blocks Used Available Use% Mounted on /dev/md0 51475004 18193208 30660360 38% / # cat /proc/mdstat md0 : active raid1 sda1[1] sdb1[0] 52428736 blocks [2/2] [UU] (I also have md1 and md2, but I don't know that they're involved in this issue.) # fdisk /dev/sda Disk /dev/sda: 750.2 GB, 750156374016 bytes, 1465149168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x53648e37 Device Boot Start End Blocks Id System /dev/sda1 2048 104859647 52428800 fd Linux raid autodetect /dev/sda2 104859648 138414079 16777216 82 Linux swap / Solaris /dev/sda3 138414080 1465149167 663367544 fd Linux raid autodetect ... /dev/sdb is partitioned *exactly* the same. With this configuration, when I attempt to boot off the F19 dvd, it gets to the point where it starts X but nothing is ever displayed, and when I look deeper I see that anaconda has died, right after some process started up the raid devices. Going into fdisk and changing these partitions from type fd to type 83 did not make a difference -- the system *still* saw the software raid sets and started them and then anaconda died. Going into fdisk and *deleting* these partitions allowed the anaconda to start properly, but even when I went into the text console and recreated the partitions and restart /dev/md0 I was unable to make anaconda install into it -- it absolutely refused to ever see that /dev/md0 existed. Previous versions of Fedora did allow me to manually set up this configuration and use it. Adding the kernel options nodmraid and rd_NO_MD did not change anything. Trying to install in text mode hangs in the same place. Actual results: Installer hangs/crashes right after starting X. Expected results: Being able to reformat and re-install onto existing /dev/md0 (or recreate it, either way works), leaving /dev/md1 and other things alone. Additional info: This configuration was created with a previous release of Fedora, but I don't recall which. I'd rather not use LVM, but do want my raid 1. I'd also rather not muck with the existing data in md1. Fedora 18 is currently installed (and working fine -- I'm using it now), and that was upgraded via yum (as I was having the same or a similar problem going from F17 to F18) and I don't recall what happened before that. My problem sound a lot like Bug 471741, "Can't install Fedora on precreated software RAID" -- but the problem seems more fundamental now -- back then, the installer wasn't properly dealing with the software raid setup, but at least it would try -- now, it won't work with it at all. I'll run through the process again and see if I can save the logs from the installation attempt.
Created attachment 783494 [details] Logs from an attempted installation Included are a set of logs and some other things that I saved from an installation attempt. At this point anaconda was just spinning using 100% of the cpu, and there was a "An unknown error has occurred" message on the X server. (And if I attempt to let it submit a bug report, the computer reboots with no indication that it did or didn't actually submit something.) In this instance all the partitions existed and were type fd, but I saw the same behavior when I changed these partitions to type 83. The problem did go away when I deleted them entirely, however.
Was there a traceback file in /tmp (it would be named anaconda-tb-*)? If so, can you attach that to the bug as well?
I included all the files in /tmp. I presume that there was no traceback file because anaconda was still running (even though it was stuck and had been there for an hour in a previous run.) Would it be helpful to run through the process again and send it a USR1 signal to trigger a crash? I've already gone ahead and upgraded my system via fedup (with no problems there, though my intent was to do a fresh install), but I can probably still reproduce the problem at will.
Yes, that would be helpful
Created attachment 784362 [details] anaconda.log
Created attachment 784363 [details] anaconda-yum.conf
Created attachment 784364 [details] blkid.out
Created attachment 784365 [details] boot.log
Created attachment 784366 [details] cat-proc-mdstat.out
Created attachment 784367 [details] dmesg.out
Created attachment 784368 [details] fdisk-sda.out
Created attachment 784370 [details] fdisk-sdb.out
Created attachment 784371 [details] fdisk-sdc.out
Created attachment 784372 [details] fdisk-sdd.out
Created attachment 784373 [details] fdisk-sde.out
Created attachment 784374 [details] ifcfg.log
Created attachment 784375 [details] packaging.log
Created attachment 784376 [details] program.log
Created attachment 784377 [details] storage.log
Created attachment 784378 [details] syslog
Created attachment 784380 [details] X.log
Created attachment 784381 [details] top.out
Created attachment 784384 [details] top1.out
Created attachment 784386 [details] top2.out
Created attachment 784496 [details] Reproduced under several diffierent scenarios
I went ahead and tried all the different installation scenarios again. Note that Anaconda is no longer spinning and using 100% of a cpu -- instead, it's either dying or just sitting there idle, and now I'm seeing anaconda-tb* files, so they've been collected under several different situations. I don't know why this changed, but one thing that has changed is my system is now running Fedora 19 (having been upgraded via fedup.) I see that you've attached files directly rather than as a .zip file, but I'm not sure which of these files you want to do that with so I'll not do that. (There's a whole bunch of files now in that zip file, as I recreated the problem a bunch of times.) When I tried the text mode installer, it (anaconda) immediately died and gave an error and allowed me to debug/report it, so I reported it, and it created bug 995159. This case probably gave the easiest to digest information on the issue. I started collecting the files for submission into this ticket when I thought it was done creating 995159, but then two errors appeared -- I think I moved some files too soon. So there may be some files missing from 995159, but they're included in the zip file included here (under the "using-text-mode" path in the zip file.)
I should add a bit to this statement -- "instead, it's either dying or just sitting there idle" -- that I saw both scenarios today. Anaconda today is not spinning using 100% of the cpu anymore, but I saw cases where it died, and I saw cases where the process was still there but just sitting there idle. In the idle cases, strace showed it stuck on something, but never told me what, so I didn't include strace output. Hopefully the traceback files have what's needed.
Looks like this is indeed a duplicate of bug 981991. By editing my /etc/fstab and commenting out the two /dev/mdX entries -- UUID=6d22406f-d6c1-4bc7-9d54-d8908a23a5cd / ext4 defaults 1 1 UUID=b46ff524-dd9b-4f69-b480-bc2b41020e23 swap swap defaults 0 0 UUID=8135bc0e-0a64-4d79-89cb-720bbd29f35a swap swap defaults 0 0 /dev/md1 /u ext4 defaults 1 2 /dev/md2 /u3 ext4 defaults 1 1 ... I was able to select partitions and I think I could even have installed on them. So this seems to be understood, though certainly, 981991 should be fixed.
It's a duplicate of 981991, so closing it as such. *** This bug has been marked as a duplicate of bug 981991 ***