This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 994231 - Fedora 19's installer absolutely will not deal with a certain software raid configuration
Fedora 19's installer absolutely will not deal with a certain software raid c...
Status: CLOSED DUPLICATE of bug 981991
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
19
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-06 15:47 EDT by Doug McLaren
Modified: 2013-08-13 12:32 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-13 12:32:19 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Logs from an attempted installation (83.69 KB, application/zip)
2013-08-06 16:16 EDT, Doug McLaren
no flags Details
anaconda.log (2.56 KB, text/plain)
2013-08-08 09:31 EDT, David Shea
no flags Details
anaconda-yum.conf (351 bytes, text/plain)
2013-08-08 09:32 EDT, David Shea
no flags Details
blkid.out (1.26 KB, text/plain)
2013-08-08 09:32 EDT, David Shea
no flags Details
boot.log (4.95 KB, text/plain)
2013-08-08 09:32 EDT, David Shea
no flags Details
cat-proc-mdstat.out (175 bytes, text/plain)
2013-08-08 09:33 EDT, David Shea
no flags Details
dmesg.out (77.74 KB, text/plain)
2013-08-08 09:33 EDT, David Shea
no flags Details
fdisk-sda.out (752 bytes, text/plain)
2013-08-08 09:33 EDT, David Shea
no flags Details
fdisk-sdb.out (752 bytes, text/plain)
2013-08-08 09:34 EDT, David Shea
no flags Details
fdisk-sdc.out (599 bytes, text/plain)
2013-08-08 09:34 EDT, David Shea
no flags Details
fdisk-sdd.out (599 bytes, text/plain)
2013-08-08 09:34 EDT, David Shea
no flags Details
fdisk-sde.out (580 bytes, text/plain)
2013-08-08 09:35 EDT, David Shea
no flags Details
ifcfg.log (490 bytes, text/x-log)
2013-08-08 09:35 EDT, David Shea
no flags Details
packaging.log (135 bytes, text/plain)
2013-08-08 09:36 EDT, David Shea
no flags Details
program.log (32.04 KB, text/plain)
2013-08-08 09:36 EDT, David Shea
no flags Details
storage.log (138.36 KB, text/plain)
2013-08-08 09:36 EDT, David Shea
no flags Details
syslog (148.06 KB, text/plain)
2013-08-08 09:37 EDT, David Shea
no flags Details
X.log (47.49 KB, text/plain)
2013-08-08 09:37 EDT, David Shea
no flags Details
top.out (16.49 KB, text/plain)
2013-08-08 09:37 EDT, David Shea
no flags Details
top1.out (16.49 KB, text/plain)
2013-08-08 09:38 EDT, David Shea
no flags Details
top2.out (16.49 KB, text/plain)
2013-08-08 09:38 EDT, David Shea
no flags Details
Reproduced under several diffierent scenarios (926.95 KB, application/zip)
2013-08-08 12:57 EDT, Doug McLaren
no flags Details

  None (edit)
Description Doug McLaren 2013-08-06 15:47:09 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.
Comment 1 Doug McLaren 2013-08-06 16:16:48 EDT
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.
Comment 2 David Shea 2013-08-06 16:35:03 EDT
Was there a traceback file in /tmp (it would be named anaconda-tb-*)? If so, can you attach that to the bug as well?
Comment 3 Doug McLaren 2013-08-06 18:39:12 EDT
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.
Comment 4 David Shea 2013-08-07 10:27:04 EDT
Yes, that would be helpful
Comment 5 David Shea 2013-08-08 09:31:55 EDT
Created attachment 784362 [details]
anaconda.log
Comment 6 David Shea 2013-08-08 09:32:17 EDT
Created attachment 784363 [details]
anaconda-yum.conf
Comment 7 David Shea 2013-08-08 09:32:38 EDT
Created attachment 784364 [details]
blkid.out
Comment 8 David Shea 2013-08-08 09:32:58 EDT
Created attachment 784365 [details]
boot.log
Comment 9 David Shea 2013-08-08 09:33:15 EDT
Created attachment 784366 [details]
cat-proc-mdstat.out
Comment 10 David Shea 2013-08-08 09:33:35 EDT
Created attachment 784367 [details]
dmesg.out
Comment 11 David Shea 2013-08-08 09:33:52 EDT
Created attachment 784368 [details]
fdisk-sda.out
Comment 12 David Shea 2013-08-08 09:34:14 EDT
Created attachment 784370 [details]
fdisk-sdb.out
Comment 13 David Shea 2013-08-08 09:34:34 EDT
Created attachment 784371 [details]
fdisk-sdc.out
Comment 14 David Shea 2013-08-08 09:34:54 EDT
Created attachment 784372 [details]
fdisk-sdd.out
Comment 15 David Shea 2013-08-08 09:35:18 EDT
Created attachment 784373 [details]
fdisk-sde.out
Comment 16 David Shea 2013-08-08 09:35:41 EDT
Created attachment 784374 [details]
ifcfg.log
Comment 17 David Shea 2013-08-08 09:36:04 EDT
Created attachment 784375 [details]
packaging.log
Comment 18 David Shea 2013-08-08 09:36:24 EDT
Created attachment 784376 [details]
program.log
Comment 19 David Shea 2013-08-08 09:36:45 EDT
Created attachment 784377 [details]
storage.log
Comment 20 David Shea 2013-08-08 09:37:07 EDT
Created attachment 784378 [details]
syslog
Comment 21 David Shea 2013-08-08 09:37:29 EDT
Created attachment 784380 [details]
X.log
Comment 22 David Shea 2013-08-08 09:37:49 EDT
Created attachment 784381 [details]
top.out
Comment 23 David Shea 2013-08-08 09:38:15 EDT
Created attachment 784384 [details]
top1.out
Comment 24 David Shea 2013-08-08 09:38:35 EDT
Created attachment 784386 [details]
top2.out
Comment 25 Doug McLaren 2013-08-08 12:57:04 EDT
Created attachment 784496 [details]
Reproduced under several diffierent scenarios
Comment 26 Doug McLaren 2013-08-08 13:03:28 EDT
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.)
Comment 27 Doug McLaren 2013-08-08 13:05:57 EDT
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.
Comment 28 Doug McLaren 2013-08-08 14:03:04 EDT
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.
Comment 29 Doug McLaren 2013-08-13 12:32:19 EDT
It's a duplicate of 981991, so closing it as such.

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

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