Bug 621685
Description
James Laska
2010-08-05 19:52:03 UTC
Created attachment 436963 [details]
Attached traceback automatically from anaconda.
Testing F-14-Alpha TC#2 with an updates.img that pulls in all recent anaconda changes, hits the above traceback. This appears to be the result of installing to system on top of a previously incomplete install. Talking to clumens, we agreed this likely won't impact a significant number of F14Alpha users considering the exceptional conditions around the issue. An updates.img will be available for those users. *** Bug 621119 has been marked as a duplicate of this bug. *** Created attachment 437140 [details]
Attached traceback automatically from anaconda.
*** Bug 621100 has been marked as a duplicate of this bug. *** Created attachment 438098 [details]
Attached traceback automatically from anaconda.
After the system encountered bug#590640 with unfinished install, this issue can be reproduced on it. Created attachment 438178 [details]
Attached traceback automatically from anaconda.
When documenting this issue for F-14-Alpha CommonBugs, one can create a updates.img that includes the change referenced at http://git.fedorahosted.org/git/?p=anaconda.git;a=commitdiff;h=1cf0ab74176b8203ffb590c47c508716fb4a5727 Created an attachment (id=438794) Attached traceback automatically from anaconda. Created an attachment (id=438809) Attached traceback automatically from anaconda. (In reply to comment #11) > Created an attachment (id=438809) > Attached traceback automatically from anaconda. The QEMU storage in this case was screwed up by problem in F14alphaRC2 (which I forgot about). It seems such a situation could be more nicely explained to user. *** Bug 624318 has been marked as a duplicate of this bug. *** Created an attachment (id=439666) Attached traceback automatically from anaconda. Created an attachment (id=439670) Attached traceback automatically from anaconda. A workaround is to manually remove the incomplete disk configuration using parted or 'dd'. Alternatively, an updates image is available for test at http://jlaska.fedorapeople.org/updates/621685.img Created an attachment (id=439867) Attached traceback automatically from anaconda. Created an attachment (id=439868) Attached traceback automatically from anaconda. i get over it by removing the existing lvm. (while leaving alone the /boot partition). affects both rc3 and rc4. Created an attachment (id=440323) Attached traceback automatically from anaconda. Created an attachment (id=440340) Attached traceback automatically from anaconda. Created an attachment (id=440515) Attached traceback automatically from anaconda. Created an attachment (id=440651) Attached traceback automatically from anaconda. *** Bug 626993 has been marked as a duplicate of this bug. *** Created an attachment (id=440952) Attached traceback automatically from anaconda. Created an attachment (id=440995) Attached traceback automatically from anaconda. Created an attachment (id=441298) Attached traceback automatically from anaconda. Discussed at today's blocker review meeting. We don't have an exact criterion to cover it, but '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' (final) is close enough. This should be fixed now anyway so we aren't too worried. We may propose a new criterion to cover handling existing disk contents. Created an attachment (id=441790) Attached traceback automatically from anaconda. Created an attachment (id=442272) Attached traceback automatically from anaconda. Created an attachment (id=442800) Attached traceback automatically from anaconda. Created an attachment (id=442801) Attached traceback automatically from anaconda. *** Bug 630254 has been marked as a duplicate of this bug. *** Created an attachment (id=443067) Attached traceback automatically from anaconda. *** Bug 630291 has been marked as a duplicate of this bug. *** Created an attachment (id=446135) Attached traceback automatically from anaconda. Created an attachment (id=446353) Attached traceback automatically from anaconda. Created an attachment (id=446505) Attached traceback automatically from anaconda. Clearing the some 100 MB from the start of the partition I used for an aborted installation before solved this for me. (In reply to comment #38) > Created an attachment (id=446505) > Attached traceback automatically from anaconda. This occurred when I restarted an install after aborting the previous one shortly after packages were being downloaded. IIRC, I aborted with ctrl-alt-del. Partitioning was done with custom layout and had one ext4 and one swap. After booting in rescue mode: blkid can recognize both partitions and reports their UUIDs. e2fsck does not report any problems with the ext4 partition. The partition can be mounted and there are directories and files in it. I recovered by deleting all partitions with fdisk while in rescue mode. $ qemu-kvm -cdrom Fedora-14-Alpha-x86_64-netinst.iso -m 512m -hda foobar.img -boot menu=on $ qemu-img info foobar.img image: foobar.img file format: raw virtual size: 3.0G (3221225472 bytes) disk size: 357M Created attachment 447950 [details]
Attached traceback automatically from anaconda.
Created attachment 447952 [details]
Attached traceback automatically from anaconda.
This issue was not encountered while testing F-14-Beta. Marking as VERIFIED. Created attachment 450633 [details]
Attached traceback automatically from anaconda.
Fedora 14 beta i386 version still exists. I had a 2nd primary partition with F9 on it that I was going to blow away anyway. I will try to fdisk it away and try again. That isn't F14 Beta. your report says anaconda 14.15 and Beta has 14.17 in it. we can close this, 14.17 has been pushed stable. Created attachment 469653 [details]
Attached traceback automatically from anaconda.
Created attachment 469654 [details]
Attached traceback automatically from anaconda.
Created attachment 469655 [details]
Attached traceback automatically from anaconda.
Creating of livecds FC19 with spin-kickstarts ends with this output: [code] Traceback (most recent call last): File "/bin/livecd-creator", line 237, in <module> sys.exit(main()) File "/bin/livecd-creator", lin 218, in main creator.install() File "/usr/lib/python2.7/site-packages/imgcreate/creator.py", line 655 in install ayum.runInstall() File "/usr/lib/python2.7/site-packages/imgcreate/yuminst.py", line 220, in runInstall raise CreateError("Dependency check failed : %s" % "\n".join(deps)) TypeError: sequence item 0: expected string, tuple found [/code] 2013-06-17 Manfred Blankenfeld (In reply to Manfred Blankenfeld from comment #51) > Creating of livecds FC19 with spin-kickstarts ends with this output: > > [code] > Traceback (most recent call last): > File "/bin/livecd-creator", line 237, in <module> > sys.exit(main()) > File "/bin/livecd-creator", lin 218, in main > creator.install() > File "/usr/lib/python2.7/site-packages/imgcreate/creator.py", line 655 in > install > ayum.runInstall() > File "/usr/lib/python2.7/site-packages/imgcreate/yuminst.py", line 220, in > runInstall > raise CreateError("Dependency check failed : %s" % "\n".join(deps)) > TypeError: sequence item 0: expected string, tuple found > [/code] > > 2013-06-17 > > Manfred Blankenfeld Please open a new bug for this against f19, also include the version of livecd-creator and yum that you have installed. |