Bug 494222
| Summary: | F11 installation not possible when /dev/md0 has been only 1 drive (out of 2) available | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Niels Haase <arxs> | ||||||
| Component: | anaconda | Assignee: | Radek Vykydal <rvykydal> | ||||||
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | urgent | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | rawhide | CC: | antillon.maurizio, pjones, rmaximo, vanmeeuwen+fedora | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | anaconda_trace_hash:bd9f2b7e8666afc3f132b538a4a3ca6d9b816f8e7668d88df0906790e734004e | ||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2009-04-21 08:52:47 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 472555 | ||||||||
| Attachments: |
|
||||||||
Created attachment 338254 [details]
Attached traceback automatically from anaconda.
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 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 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.
(In reply to comment #4) For a record, I succeeded to reproduce the bug by adding --run to andconda's mdadm --assemble call. (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 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 Created attachment 340223 [details]
tarball with anaconda.log, program.log, storage.log and syslog from /tmp
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. 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> - 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 |
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