Created attachment 915206 [details] Comment (This comment was longer than 65,535 characters and has been moved to an attachment by Red Hat Bugzilla).
clear beta blocker.
*** Bug 694770 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > clear beta blocker. Definitely! From the Fedora 15 beta criteria page [1] ... "# The installer must boot (if appropriate) and run on all primary architectures from default live image, DVD, multi-CD, and boot.iso install media " We have +2 for Beta blocker on this issue. If we have additional +'s, I believe we can fast track this into whiteboard:AcceptedBlocker [1] http://fedoraproject.org/wiki/Fedora_15_Beta_Release_Criteria
+1 from me as a beta blocker
This sounds like bug 672265, but it shouldn't have gotten this deep into anaconda since liveinst has a check for that file.
If I do an 'ls /dev/mapper' before running liveinst, that file exists, as a symlink to /dev/dm-1 . *After* the first attempt to run liveinst, the file is gone. So the file (symlink) is actually there, but somehow running liveinst causes it to get destroyed?
I notice a couple of messages from device-mapper in /var/log/messages right after anaconda registers all the RAID classes: Apr 8 11:03:15 localhost kernel: [ 49.922420] md: raid0 personality registered for level 0 Apr 8 11:03:15 localhost kernel: [ 49.947900] md: raid1 personality registered for level 1 Apr 8 11:03:15 localhost kernel: [ 49.967360] async_tx: api initialized (async) Apr 8 11:03:15 localhost kernel: [ 50.023723] xor: automatically using best checksumming function: generic_sse Apr 8 11:03:15 localhost kernel: [ 50.028023] generic_sse: 11452.000 MB/sec Apr 8 11:03:15 localhost kernel: [ 50.028025] xor: using function: generic_sse (11452.000 MB/sec) Apr 8 11:03:16 localhost kernel: [ 50.058570] raid6: int64x1 1234 MB/s Apr 8 11:03:16 localhost kernel: [ 50.078537] raid6: int64x2 1742 MB/s Apr 8 11:03:16 localhost kernel: [ 50.096555] raid6: int64x4 1375 MB/s Apr 8 11:03:16 localhost kernel: [ 50.113022] raid6: int64x8 1269 MB/s Apr 8 11:03:16 localhost kernel: [ 50.130028] raid6: sse2x1 5671 MB/s Apr 8 11:03:16 localhost kernel: [ 50.147026] raid6: sse2x2 7046 MB/s Apr 8 11:03:16 localhost kernel: [ 50.164020] raid6: sse2x4 9222 MB/s Apr 8 11:03:16 localhost kernel: [ 50.164022] raid6: using algorithm sse2x4 (9222 MB/s) Apr 8 11:03:16 localhost kernel: [ 50.191765] md: raid6 personality registered for level 6 Apr 8 11:03:16 localhost kernel: [ 50.191767] md: raid5 personality registered for level 5 Apr 8 11:03:16 localhost kernel: [ 50.191768] md: raid4 personality registered for level 4 Apr 8 11:03:16 localhost kernel: [ 50.215279] md: raid10 personality registered for level 10 Apr 8 11:03:16 localhost kernel: [ 50.303665] device-mapper: multipath: version 1.2.0 loaded Apr 8 11:03:16 localhost kernel: [ 50.316743] device-mapper: multipath round-robin: version 1.0.0 loaded
So we've found out a couple of things about this. 1), this fixes it: http://fpaste.org/L9ZN/ 2), it's caused by the udev patch we threw in yesterday to fix https://bugzilla.redhat.com/show_bug.cgi?id=693247 . I built a live image with that patch disabled, and anaconda runs. We're investigating now if the udev patch is causing other issues too.
Both bcl and I hit problems further on in installation after fixing the initial bug - doing automatic partitioning results in 'You have not defined a root partition (/), which is required for installation of Fedora to continue.' On my test live image which has a udev build with the offending patch disabled, I can do a successful install. So it seems the udev patch is definitely problematic. I'm going to re-open that other bug and add some info there, and we'll have to decide how to proceed. I'm not sure we should go too far down the path of trying to 'fix' anaconda for the changes that udev patch introduced yet, it may turn out the patch needs to be reconsidered.
whoops: looks like i'm off. I re-span my testing live image with the 'broken' udev...and it works. so there must be another diff between my test image and rc1 which is the actual problem. here is the diff: http://fpaste.org/YsJw/ (note - lines are packages in my custom image, + lines are packages in rc1). next suspect is dracut; I am spinning my image with the older dracut to test.
okay, so I re-span my image with dracut-008-7 and it breaks. so I'm almost 100% sure the issue here is dracut: works with dracut-009-5, breaks with dracut-008-7.
i've tested back to dracut-009-1, which also works, so it looks like an upstream change between dracut 008 and 009 fixes this. smallest change I can see so far to fix this bug is to push dracut-009-1, unless we can isolate the change from upstream.
So, I'm thinking this is probably down to the support for /run in dracut 009. That's a whole bunch of upstream patches, it may be tricky to isolate it; it may be best to just take 009 as a whole.
okay, I've now double-checked to my satisfaction that the key part here is dracut 008-7 vs. dracut 009-1. toggling those switches between fail and success cases. so, plan: 1) find someone to submit 009-1 as an update, test + approve it, spin rc2. 2) wait for harald and see if he'd prefer to isolate the key change as a patch to 008-7, or alternatively if he thinks we should take a later 009 build if any of the other changes in later 009 builds are really important. votes?
harald, obviously, we would appreciate your input asap :)
Here's how I reproduced it without having to run liveinst: [root@localhost ~]# udevadm trigger --subsystem-match block [root@localhost ~]# ls /dev/mapper/ control live-osimg-min live-rw [root@localhost ~]# udevadm control --env=ANACONDA=1 [root@localhost ~]# ls /dev/mapper/ control live-osimg-min live-rw [root@localhost ~]# udevadm trigger --subsystem-match block [root@localhost ~]# ls /dev/mapper/ control live-osimg-min live-rw [root@localhost ~]# udevadm trigger --subsystem-match block --action add [root@localhost ~]# ls /dev/mapper/ control [root@localhost ~]# udevadm trigger --subsystem-match block --action add [root@localhost ~]# ls /dev/mapper/ control [root@localhost ~]# udevadm control --env=ANACONDA=0 [root@localhost ~]# ls /dev/mapper/ control [root@localhost ~]# udevadm trigger --subsystem-match block --action add [root@localhost ~]# ls /dev/mapper/ control [root@localhost ~]# udevadm trigger --subsystem-match block [root@localhost ~]# ls /dev/mapper/ control live-osimg-min live-rw
I see this "unhandled exception" Trying to use livinst with both /pub/alt/stage/15-Beta.RC1/Live/i686 -Live-Desktop.iso and Fedora-15-Nightly-20110403.17-i686-Live-soas.iso /pub/alt/stage/15-Beta.TC1/Live/i686 worked fine Most likely Anaconda is too blame?
*** Bug 694921 has been marked as a duplicate of this bug. ***
this is fixed in rc2 by https://admin.fedoraproject.org/updates/dracut-009-5.fc15 .
*** Bug 695098 has been marked as a duplicate of this bug. ***
*** Bug 695072 has been marked as a duplicate of this bug. ***
Created attachment 491105 [details] http://koji.fedoraproject.org/koji/getfile?taskID=2988773&name=Fedora-15-Nightly-20110409.16-i686-Live-desktop.iso install to hard disk from mounted CD failure of liveinst to start
(In reply to comment #22) > Created attachment 491105 [details] > http://koji.fedoraproject.org/koji/getfile?taskID=2988773&name=Fedora-15-Nightly-20110409.16-i686-Live-desktop.iso > > install to hard disk from mounted CD failure of liveinst to start The nightly image does not yet include the required version of dracut, needed to resolve this issue. The nightly used included dracut-008-7.fc15.noarch (see http://koji.fedoraproject.org/koji/getfile?taskID=2988774&name=root.log). Can you please retest using F-15-Beta-RC2 (http://serverbeach1.fedoraproject.org/pub/alt/stage/15-Beta.RC2/). Thanks!
Closing since the version of dracut that resolves this issue (dracut-009-5.fc15) has been pushed to stable. This issue is confirmed fixed in F-15-Beta-RC2, and will arrive in a nightly Live ISO image shortly.
works fine in 15-Beta.RC2 live