Bug 494222 - F11 installation not possible when /dev/md0 has been only 1 drive (out of 2) available
F11 installation not possible when /dev/md0 has been only 1 drive (out of 2) ...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
x86_64 Linux
low Severity urgent
: ---
: ---
Assigned To: Radek Vykydal
Fedora Extras Quality Assurance
anaconda_trace_hash:bd9f2b7e8666afc3f...
:
Depends On:
Blocks: AnacondaStorage
  Show dependency treegraph
 
Reported: 2009-04-05 15:54 EDT by Niels Haase
Modified: 2011-05-28 19:30 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-21 04:52:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Attached traceback automatically from anaconda. (87.80 KB, text/plain)
2009-04-05 15:55 EDT, Niels Haase
no flags Details
tarball with anaconda.log, program.log, storage.log and syslog from /tmp (80.00 KB, application/x-tar)
2009-04-19 06:56 EDT, Niels Haase
no flags Details

  None (edit)
Description Niels Haase 2009-04-05 15:54:49 EDT
The following was filed automatically by anaconda:
anaconda 11.5.0.40 exception report
Traceback (most recent call first):
  File "/usr/lib/anaconda/storage/devicelibs/mdraid.py", line 182, in mddeactivate
    raise MDRaidError("mddeactivate failed for %s" % device)
  File "/usr/lib/anaconda/storage/devices.py", line 2289, in teardown
    mdraid.mddeactivate(self.path)
  File "/usr/lib/anaconda/storage/devicetree.py", line 1516, in teardownAll
    device.teardown(recursive=True)
  File "/usr/lib/anaconda/storage/devicetree.py", line 1506, in populate
    self.teardownAll()
  File "/usr/lib/anaconda/storage/__init__.py", line 283, in reset
    self.devicetree.populate()
  File "/usr/lib/anaconda/storage/__init__.py", line 108, in storageInitialize
    storage.reset()
  File "/usr/lib/anaconda/dispatch.py", line 205, in moveStep
    rc = stepFunc(self.anaconda)
  File "/usr/lib/anaconda/dispatch.py", line 128, in gotoNext
    self.moveStep()
  File "/usr/lib/anaconda/gui.py", line 1323, in nextClicked
    self.anaconda.dispatch.gotoNext()
MDRaidError: mddeactivate failed for /dev/md0
Comment 1 Niels Haase 2009-04-05 15:55:00 EDT
Created attachment 338254 [details]
Attached traceback automatically from anaconda.
Comment 2 Niels Haase 2009-04-05 16:10:57 EDT
try to install from vmlinuz / initrd from rawhide from 5th April.

disk layout at the time of installation:

/dev/sda1   *           1        5505     1048701   83  Linux
/dev/sda2            5506      555940   104857867+  fd  Linux raid autodetect
/dev/sda3          555941     1281882   138291951   8e  Linux LVM

the raid is a raid1, but only one drive is attached while installation.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 3 Niels Haase 2009-04-14 07:49:13 EDT
Changing title to reflect the problem better.

Also not installable with Fedora-11-Snap1 graphical installer. After choosing the language and click to next, a empty window aper with "Finding Device" in the title. After a few seconds, an other window is (untitled in this case) is popping up with the following error message:

Unable to mount 107 GB Filesystem. org.freedesktop.DeviceKit.Disks.Error.inhibited: Daemon is being inhibited.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 4 Radek Vykydal 2009-04-16 05:24:48 EDT
I am not able to reproduce the bug.

When I try to reproduce in KVM with rawhide 0414 (anaconda .44),
there is one significant difference in logs:

While in reported case mdadm --assemble starts the device with one member

Running... ['mdadm', '--assemble', '/dev/md0', '--uuid=f52bd83b:c04cc10b:80f1b419:9685ecf7', '--auto=md', '--update=super-minor', '/dev/sda2']
mdadm: /dev/md/0 has been started with 1 drive (out of 2).

in my case (KVM, also raid 1, with only one disk attached), the device assembly
doesn't start the device ("need all 2 to start it (use --run to insist)"),
and therefore, unlike in Description, it doesn't deactivate the device
which caused the traceback. I am not sure if the difference is due
to mdadm version change, anaconda code change, or different configuration.

Also when trying to reproduce with Fedora-11-Snap1 (Live XFCE) I wasn't able
to reproduce what you hit.

Could you try to reproduce with rawhide? There is a chance the
issue has been already fixed.
Comment 5 Radek Vykydal 2009-04-16 11:58:29 EDT
(In reply to comment #4)
For a record,
I succeeded to reproduce the bug by adding --run to
andconda's mdadm --assemble call.
Comment 6 Niels Haase 2009-04-16 16:33:39 EDT
(In reply to comment #4)
> I am not able to reproduce the bug.
> 
> When I try to reproduce in KVM with rawhide 0414 (anaconda .44),
> there is one significant difference in logs:
> 
> While in reported case mdadm --assemble starts the device with one member
> 
> Running... ['mdadm', '--assemble', '/dev/md0',
> '--uuid=f52bd83b:c04cc10b:80f1b419:9685ecf7', '--auto=md',
> '--update=super-minor', '/dev/sda2']
> mdadm: /dev/md/0 has been started with 1 drive (out of 2).
> 
> in my case (KVM, also raid 1, with only one disk attached), the device assembly
> doesn't start the device ("need all 2 to start it (use --run to insist)"),
> and therefore, unlike in Description, it doesn't deactivate the device
> which caused the traceback. I am not sure if the difference is due
> to mdadm version change, anaconda code change, or different configuration.
> 
> Also when trying to reproduce with Fedora-11-Snap1 (Live XFCE) I wasn't able
> to reproduce what you hit.
> 
> Could you try to reproduce with rawhide? There is a chance the
> issue has been already fixed.  

Hello Radek,

thanks you a lot for put your time to help me with this bug. Unfortunately I can't try to reproduce the bug today, because of the bug 495884. Looking forward that the tomorrow available rawhide will get rid of it. If so, I will provide you the missing information.  

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 7 Niels Haase 2009-04-19 06:53:19 EDT
Trying with anaconda .44 from rawhide install.img as of 17-Apr-2009. 

Looks good but than it fails again. But in this case anaconde yust stop and do nothing (after show finding devices). Logfiles copied over scp.

Anaconda starts the md0 device correct (mdadm -D /dev/md0 show as expected state clean, degraded) But under /tmp/syslog it show this wired "unknown partition table" messages:

<6>md: md0 stopped.
<6>md: bind<sda2>
<6>raid1: raid set md0 active with 1 out of 2 mirrors
<6> md0: unknown partition table

that's right I think, because /dev/md0 is itself a partition with an ext4 filesystem on it. It no problem to mount the partition while the installation is running (mount -t ext4 /dev/md0 /test). 

It there anything else that I can do to provide more (debug) logs that help you with this problem?

Thanks for you help and time!

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 8 Niels Haase 2009-04-19 06:56:11 EDT
Created attachment 340223 [details]
tarball with anaconda.log, program.log, storage.log and syslog from /tmp
Comment 9 Radek Vykydal 2009-04-20 11:57:29 EDT
Thank you for retesting and attaching log files. It seems like installer
hanged in mdadm --assemble command (something I've never met before).
For how long time did you see anaconda hanging?

For me in KVM, with anaconda .44, again, the array is not started with
mdadm --assemble - as I described in comment #4 (why? maybe here is a
a clue).
Perhaps it can be due to some difference in contents of our raid
members or metadata used.

Could you reproduce the hang and look in tty2 with ps if mdadm is running?
(output of 'ps aux | grep mdadm')
And also get complete output of 'mdadm -D /dev/md0'? I'm not very optimistic
about seeing useful info there, but I have no better ideas. Maybe I'll
have to try to reproduce on metal machine.
Comment 10 Niels Haase 2009-04-21 04:52:47 EDT
Good News! In short: works with .46

to provide your requested information I do an install with anaconda .46. And it works. Maybe is linked to the change:

Fri Apr 17 2009 David Cantrell <dcantrell@redhat.com> - 11.5.0.46-1 
...
Make sure we "insist" on mdadm commands. (491729) (jgranado)
...

I suggest to close the bug now. Anyway, if you still want the logfiles from the (successfully) installation, or the output of mdadm -D /dev/md0 or anything else, please let me know. 

Again, thanks for your help and time spending on this issue!


-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

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