Description of problem: Previous installation: root on software RAID0 I removed second harddrive (one raid member) then I started new installation. Version-Release number of selected component: anaconda-18.24 Additional info: libreport version: 2.0.17 cmdline: /usr/bin/python /sbin/anaconda kernel: 3.6.5-2.fc18.x86_64 description: :The following was filed automatically by anaconda: :anaconda 18.24 exception report :Traceback (most recent call first): : File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devicetree.py", line 778, in addUdevMDDevice : devicelibs.mdraid.mddeactivate("/dev/" + name) : File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devicetree.py", line 1058, in addUdevDevice : device = self.addUdevMDDevice(info) : File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devicetree.py", line 1902, in _populate : self.addUdevDevice(dev) : File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devicetree.py", line 1850, in populate : self._populate() : File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 398, in reset : self.devicetree.populate(cleanupOnly=cleanupOnly) : File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 104, in storageInitialize : storage.reset() : File "/usr/lib64/python2.7/threading.py", line 504, in run : self.__target(*self.__args, **self.__kwargs) : File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 91, in run : threading.Thread.run(self, *args, **kwargs) :TypeError: cannot concatenate 'str' and 'NoneType' objects
Created attachment 638503 [details] File: anaconda-tb
Created attachment 638504 [details] File: product
Created attachment 638505 [details] File: type
Created attachment 638506 [details] File: ifcfg.log
Created attachment 638507 [details] File: storage.log
Created attachment 638508 [details] File: version
Created attachment 638509 [details] File: environ
Created attachment 638510 [details] File: executable
Created attachment 638511 [details] File: anaconda.log
Created attachment 638512 [details] File: syslog
Created attachment 638513 [details] File: hashmarkername
Created attachment 638514 [details] File: packaging.log
Created attachment 638515 [details] File: cmdline_file
Created attachment 638516 [details] File: release
Created attachment 638517 [details] File: program.log
*** Bug 873361 has been marked as a duplicate of this bug. ***
I got it too by booting F18b TC7 with only two of four raid5 members.
Proposing as F18 Blocker. Alpha release criterion: 12. The installer must be able to complete an installation using automatic partitioning to any sufficiently large target disk, whether unformatted, empty, or containing any kind of existing data
neither of those sounds like valid configurations. anaconda intentionally refuses to treat incomplete raid arrays like this as separate disks and just install to them, iirc. you have to wipe the RAID array first. could do with input from clumens and dlehman, but right now i'm -1 blocker.
Anaconda doesn't support installing to degraded raids, but we also shouldn't blow up when one is encountered. This should be fixed for final, but I don't think we need it for beta since there is no data loss involved and you can easily work around it by wiping the disks with wipefs -a /dev/XXX
Discussed 2012-11-07 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-11-07/f18beta-blocker-review-7.2012-11-07-17.03.log.txt . Rejected as a Beta blocker as we won't support installing to this config anyway and the bug is only that we crash instead of erroring politely, but accepted as Final blocker per criterion "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above" (which is a kludge, but never mind).
Sigh. Sorry, I suck today.
I believe dlehman has plans for dealing with this fairly soon.
could not even accept fate. Package: anaconda-18.29 OS Release: Fedora release 18-Beta-TC9
reartes: same reproducer as before, an incomplete RAID array?
In comment #24, anaconda boots directly to the black screen + the 'unknown error' reported. There is an mdadm array (most likely partial) on sdc, but in this case i do not reach the welcome screen.
(In reply to comment #26) > In comment #24, anaconda boots directly to the black screen + the 'unknown > error' reported. > > There is an mdadm array (most likely partial) on sdc, but in this case i do > not reach the welcome screen. Reaertes, feel free to keep plugging away with incomplete md arrays if you want to, but we aren't ready to start working on handling for such things at this point. Incomplete lvm/md setups is mostly something that we see with uber-testers like you and the occasional user who move drives from box to box. Once we have most of the normal/real-world operations working well we can move on to these more esoteric problems. Until then, don't expect this stuff to work.
commonbugs -> we need to document that incomplete RAID, LVM, btrfs etc multi-disk devices may cause crashes.
Had four virtio disks configured as a RAID volume. Shut down guest, removed the last three virtio disks and left one, started new install, hit this. Package: anaconda-18.29.2 OS Release: Fedora release 18-Beta
*** Bug 749064 has been marked as a duplicate of this bug. ***
I tested a patch for this today. It works well, but needs some ui handling before I can call it done.
anaconda-18.37.4-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/anaconda-18.37.4-1.fc18
Package anaconda-18.37.4-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-18.37.4-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-20677/anaconda-18.37.4-1.fc18 then log in and leave karma (feedback).
anaconda-18.37.4-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
Michal (or anyone else who reproduced the problem), can you please verify the fix with smoke9 image? http://dl.fedoraproject.org/pub/alt/qa/20121219_f18-smoke9/
When I started installation on system with one RAID0 member, select INSTALLATION DESTINATION, select harddrive, click on continue, click on Reclaim space, delete all partitions, click on Reclaim space, traceback report occured and system is rebooted directly. When I clicked on "I don't need help; let me customize disk partitioning", removed partitions and create new disk layout, then installation finished successfully.
(In reply to comment #36) > When I started installation on system with one RAID0 member, select > INSTALLATION DESTINATION, select harddrive, click on continue, click on > Reclaim space, delete all partitions, click on Reclaim space, traceback > report occured and system is rebooted directly. Obviously a different error, but reproducible here.
New bug reported to track crash reported in comment 36: 889330
So can we close this one?
Yes, to hit the bug from comment 36 you must have already passed the code that triggered this bug.