Bug 656076

Reassigning to anaconda, as you've clearly gotten past gpxe downloading the first stage installer.

It'd be nice to have the log files attached.

Which logs would you like attached?

/tmp/anaconda.log, /tmp/syslog, /tmp/yum.log during installation.

Does /tmp exist only in RAM during a BFO installation? I'm not seeing these files on the USB stick. And I suppose if /tmp is on the target drive for installation, it would be cleaned up on reboot. And they're not presently on the target drive in any event.

Is ftp or ssh running during a BFO installation, or can either of them be made to run so that I can remotely grab these files?

I had this problem with Fedora 13 BFO installation as well. So it's worth doing another BFO installation just to get these logs if it helps to fix the problem down the road. But I need some explicit information on how to get them before I'd be willing to blow away the installation now on this machine.

Yes, /tmp is a ramfs.  If you complete installation, they will be copied to /var/log/anaconda* afterwards.  sshd is running if you pass the sshd command line parameter to anaconda.

Is there any chance these are copied to the target volume? I ask because I do have a number of anaconda items in /var/log presently on that volume with a date and time stamp of the original BFO installation.


-rw-------. 1 root    root     47175 Nov 22 18:10 anaconda.log
-rw-------. 1 root    root     19745 Nov 22 18:10 anaconda.program.log
-rw-------. 1 root    root    130545 Nov 22 18:10 anaconda.storage.log
-rw-------. 1 root    root     77829 Nov 22 18:10 anaconda.syslog
-rw-------. 1 root    root     35294 Nov 22 18:10 anaconda.xlog
-rw-------. 1 root    root    126557 Nov 22 18:10 anaconda.yum.log

Yes if the installation succeeds, anaconda copies all its log files to the installed system.  If those timestamps match up with the install you were performing when you hit this problem, they'd be helpful.

Created attachment 467327 [details]
anaconda logs

All anaconda logs in /var/log on the system successfully (eventually) installed F14 using BFO.
-rw-------. 1 root    root     47175 Nov 22 18:10 anaconda.log
-rw-------. 1 root    root     19745 Nov 22 18:10 anaconda.program.log
-rw-------. 1 root    root    130545 Nov 22 18:10 anaconda.storage.log
-rw-------. 1 root    root     77829 Nov 22 18:10 anaconda.syslog
-rw-------. 1 root    root     35294 Nov 22 18:10 anaconda.xlog
-rw-------. 1 root    root    126557 Nov 22 18:10 anaconda.yum.log

The logs say things like:


Try 1/10 for http://download.fedoraproject.org/.../dnsmasq-XXX.rpm failed: [Errno 14] HTTP Error 403 : http://mirror.cc.vt.edu/.../dnsmasq-XXX.rpm 
Failed to get http://download.fedoraproject.org/.../dnsmasq-XXX.rpm from mirror 1/1, or downloaded file is corrupt


You'd think it would just move on to the next mirror, but instead it says "Failed to get ... from mirror 1/1". Huh? There should be a lot more mirrors than that, right?

I'm guessing the BFO configuration is using the round-robin redirector URL (http://download.fedoraproject.org/pub/fedora/...) as the only configured URL, so if there's any error, pycurl doesn't know it can just retry and get a new mirror. Except..


Try 1/10 for http://mirrors.xmission.com/.../libsmbclient-XXX.rpm failed: [Errno 14] HTTP Error 404 : http://mirrors.xmission.com/.../libsmbclient-XXX.rpm 
Failed to get http://mirrors.xmission.com/.../libsmbclient-XXX.rpm from mirror 1/47, or downloaded file is corrupt


Now we have 47 mirrors, but it gave up after 1 failure? This doesn't make a lot of sense.

Should probably look closer at how BFO sets up the installation, and how pycurl is configured in anaconda.

download.fp.o is a one-shot HTTP 30x redirect, it doesn't send a mirror list for BFO to try the next in the list...  If BFO would simply do the original URL request again (not the resultant HTTP 30x Location like it's doing), it would get another redirect, likely to a different mirror.  If the client were part of a specific netblock though, it may continue to always get the same answer from download.fp.o, thus would always fail...  teaching BFO to get a mirrorlist would be nice.

So the menu that gets presented to the user is stored here:

http://serverbeach1.fedoraproject.org/pub/alt/bfo/pxelinux.cfg/fedora_install.conf

which starts the install like so:

label Fedora-14-i386
	MENU LABEL Fedora-14-i386
	kernel http://download.fedoraproject.org/pub/fedora/linux/releases/14/Fedora/i386/os/images/pxeboot/vmlinuz
	initrd http://download.fedoraproject.org/pub/fedora/linux/releases/14/Fedora/i386/os/images/pxeboot/initrd.img
	append method=http://download.fedoraproject.org/pub/fedora/linux/releases/14/Fedora/i386/os/

method=XXX will use the given URL *only*, for everything.

At least for Fedora 14 and earlier, I think we can fix this bug by changing that line to:

append stage2=http://download.fedoraproject.org/pub/fedora/linux/releases/14/Fedora/i386/os/images/install.img

which will allow the booted anaconda to use its repo config / mirrorlists to fetch packages.

I'm not sure how we should handle this for F15 and later, where we'll have One Big Image. Maybe no 'append' line is necessary at all?

Chris, could you try a BFO installation like this to see if it fixes the problem?

That is: in the BFO Install menu, choose the item you want and hit Tab to change options - then change'method=.../os/' to 'stage2=.../os/images/install.img'. 

If you do that, can you get through the install without having to hit 'Retry' over and over?

have had same 'dumb monkey' problems as in description, for bfo install of f14 (gave up) and now f15 alpha (in _incredibly_tedious_ progress, 'packages completed: 658 of 1098' after 20 somewhat attended hours)

if this fails, i would try the fix of comment 13, except:
for alpha is it expected that there be no images/install.img to be used in stage2?

searching thru the directory (and thus random(?) mirror) as given in comment 13 stage2 for f15, i find:

/fedora/linux/releases/test/15-Alpha/Fedora/i386/os/images/
(boot.iso, but no image.iso)

same for /fedora/linux/development/15/i386/os/images/

if this is the case, will have to wait for f15-beta to try this fix.

To be clear: this is not a bug in anaconda, it's a problem with the configuration used by boot.fedoraproject.org. This was fixed for Fedora 14 and earlier on February 28. 

As suggested in comment #12, for Fedora 15 no "method=xxx" line is necessary. Remove it and the install will proceed without the constant "Retry? message.

(Apparently, whoever added the Fedora 15 configuration sections on boot.fedoraproject.org didn't see the email telling them to leave out the "append method=..." part. Oh well.)

If anyone can confirm that removing "method=xxx" from the boot commandline makes the install proceed as expected, we'll change the configuration on boot.fedoraproject.org and close this bug.

I have not had a chance to test because I'm unwilling to blow away the installation on the original test machine.

However, I now have a new test machine I can try this with, but it is an Intel EFI 1.1 Macbook Pro and the bfo.usb file use to create the BFO USB stick will not boot this machine at all. It also will not boot a different Macbook Pro which is a UEFI 2.x machine.

So there appears to be other problems with the state of BFO when it comes to (U)EFI machines. If someone has a suggestion on how to proceed, let me know.

Ugh. EFI is basically black magic, and Apple's EFI implementation is so different from others as to basically be its own completely different type of black magic.

I'll just set up a virt guest to test this with.

(In reply to comment #17)
> Ugh. EFI is basically black magic, and Apple's EFI implementation is so
> different from others as to basically be its own completely different type of
> black magic.

http://fedoraproject.org/wiki/Anaconda/Features/UEFI
"Other install methods (USB, PXE) are working; only CD/DVD has this problem"

Supposedly it is working or workable. It's just that there isn't a (U)EFI specific BFO image available. UEFI booting is totally different so it stands to reason there'd need to be a different BFO image. Heck maybe one isn't even needed (see below).

I know early Apple hardware is neither Intel EFI nor UEFI. It's something in the middle. The current hardware (last couple of years) should all be UEFI 2.x compliant. I have GRUB Legacy EFI and GRUB2 EFI working on both kinds of hardware. In theory I should be able to plug in the URLs for Fedora 15 found in the BFO GRUB menu from a conventional machine, into either GRUB Legacy EFI or GRUB2 EFI by command line, on either hardware variety, and it would work. But then is this really a BFO test?

There are ample explanations for why Apple did not implement Intel EFI 1.1, all other hardware vendors puked at the early EFI concept, and thus UEFI was born, abstracted away from Intel.

But if either UEFI or Apple's present implementation of it is inadequate or not conforming to the standard, then this needs to be demonstrated clearly so I, and others, can post a bug with Apple. It may go nowhere, but it certainly will go nowhere if it's not reported/complained about. 

For true blackmagic, see the incoherent abomination that is GRUB2 and associated (non)documentation. That's much worse than anything in the UEFI spec, or Apple's implementation of it. That is a project that demonstrates utter lack of discipline and has fractured developers on bootloader support and methods. It's not due to laziness that Red Hat continues to hack GRUB Legacy.

...interesting, but wildly off-topic. You might consider filing a separate bug about making BFO handle (U)EFI hardware.

In the meantime, I've successfully completed a F15 install after removing the "method=..." argument from the boot commandline. So that's the workaround, and once the infrastructure folks fix the existing config file I'll close this bug.

should be fixed now. Please confirm. ;)

Works fine on my test system. Thanks very much!