With the 2008-04-13 install tree and kernel-xen-2.6.25-0.24.rc9, after all the packages have been installed, anaconda hangs. In the log I'm seeing: 08:34:28 CRITICAL: anaconda 11.4.0.71 exception report Traceback (most recent call first): File "/usr/lib64/python2.5/site-packages/rhpl/executil.py", line 81, in execWithRedirect os.execv(command, argv) File "/usr/lib/booty/bootloaderInfo.py", line 666, in runGrubInstall File "/usr/lib/booty/bootloaderInfo.py", line 690, in installGrub File "/usr/lib/booty/bootloaderInfo.py", line 1229, in installGrub File "/usr/lib/booty/bootloaderInfo.py", line 925, in writeGrub File "/usr/lib/booty/bootloaderInfo.py", line 1108, in write File "/usr/lib/booty/bootloaderInfo.py", line 1216, in write File "/usr/lib/anaconda/bootloader.py", line 229, in writeBootloader File "/usr/lib/anaconda/dispatch.py", line 208, in moveStep File "/usr/lib/anaconda/dispatch.py", line 131, in gotoNext File "/usr/lib/anaconda/gui.py", line 1259, in nextClicked File "/usr/lib/anaconda/iw/progress_gui.py", line 80, in renderCallback File "/usr/lib/anaconda/gui.py", line 1280, in handleRenderCallback OSError: [Errno 8] Exec format error Only assigning to kernel-xen-2.6 for now since I'm not yet convinced this isn't Xen specific or that it isn't because the installed kernel doesn't match the running kernel.
Created attachment 302567 [details] anaconda.log
Could be problems with the x86_64 kernel running 32bit binaries?
It happened on both arches, but what you say does make sense - grub is a 32 bit binary and we don't have ia32 emulation on x86_64 xen yet If that is the case, then we need to fix bug #437358
Okay, I haven't seen this again on 32 bit and ENOEXEC is what you currently get if you try and run a 32 bit binary on x86_64 at the moment, so I must just have got something confused somewhere. This is less critical than it sounds - pygrub doesn't require grub-install to have been run, so when the install hangs you should be able to reboot without any problems. Very annoying, though. *** This bug has been marked as a duplicate of 437358 ***
Can we make Anaconda skip running grub-install when under xen domU? It would be safer than trying to get ia32 emulation ready for Fedora 9.
The nice thing about always running grub-install is that it makes it easier to switch the guest to FV later - merely need to yum install the new baremetal kernel and boot it up in a HVM guest.
Okay, re-opening this and putting it on the F-9 blocker. I don't think we can ship it as is and we're not yet sure how we'll fix it for the release. Our options are: + Add patches to implement ia32 emulation on x86_64 (bug #437358) These patches aren't complete yet and we're not comfortable with shipping them (yet, at least) + Patch anaconda to not try and do grub-install on x86_64 xen Domu Something like this should probably work, but I haven't tried yet: @@ -147,6 +147,9 @@ def writeBootloader(anaconda): justConfigFile = not flags.setupFilesystems + # + # FIXME: 32 bit binaries currently aren't supported on x86_64 + # pv_ops DomU, so don't run grub-install (#442685) + # + if os.path.exists("/proc/xen") and rhpl.getArch() == "x86_64": + justConfigFile = True
The problem is that hacks like this aren't sustainable -- they get left around and then someone wonders why things are the way they are and it's entirely unclear whether it's needed or not. The right thing to do is to fix the kernel. anaconda's job isn't working around broken kernels.
(In reply to comment #8) > The problem is that hacks like this aren't sustainable Agreed. But I'd suggest removing it again as soon as the GA install trees are baked. > -- they get left around > and then someone wonders why things are the way they are and it's entirely > unclear whether it's needed or not. Not when there's a big FIXME explaining the rationale and a link to the bug report with even more details. > The right thing to do is to fix the kernel. anaconda's job isn't working > around broken kernels. Wholeheartedly agree. If we don't get ia32 emulation sorted in time, though, it comes down to a choice between a broken installer or a simple temporary hack I'd much rather see the kernel fixed in time (In the mean time we should probably try and fix the genuine anaconda bug where this just hangs, prints a traceback to tty3 and gives the user no indication that something broke)
Created attachment 303163 [details] 0001-Disable-grub-install-on-x86_64-Xen-Domu.patch FWIW, I've tried the anaconda hack out and it works fine. Attaching it here in case we decide to go with it.
Okay, we're not going to get ia32 emulation working for F9 final Re-assigning to anaconda-maint - can we get this hack in?
Okay, Jeremy says we still have until early next week (2008-04-28) to get this working ... taking the bug back again
As Orion noted on fedora-xen, this isn't just about grub-install - if the install hangs at this stage, kickstart's %post never gets run either
Okay, it still looks like we're not going to get ia32 emulation working for F9 final - see bug #437358 Re-assigning to anaconda-maint - can we get this hack in?
Today seems to be kludge day. Committed to f9-branch even though I still don't like it.
Can anyone test/confirm the fix here, or give some quick instructions on how to do so? Do we just need to install x86_64 F9 in a Xen host, or what?
I installed an x86_64 F9 Xen guest yesterday & it worked fine, so consider it tested & confirmed.