D-I install menu, select "Boot from first hard disk" and it goes back to Language selection

[C de-Avillez]

Server install, 201013. Machine has Quantal B2 installed.

Boot from installer media (in my case, a USB stick);
select Language (English, in my case)
on the installer menu, select "Boot from first hard disk"

You are thrown back into "Select Language", then the installer menu again.

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1066387

[Colin Watson (cjwatson)]

The best we can do in syslinux is to boot from whatever it thinks BIOS disk 0x80 is - if your BIOS lies about that and claims it's a USB disk, not much we can do about it.

[Scott Kitterman (kitterman)]

Also seen in Raring Alpha 1. Today's discussion on #ubuntu-release:

<infinity> menu label ^Boot from first hard disk
<infinity> localboot 0x80
<slangasek> "Boot from first hard disk" is done via BIOS calls; if the "first hard disk" it's booting isn't the one you want, that's a BIOS issue
[queuebot] Builds: Edubuntu DVD i386 [Raring Alpha 1] (20121203.1) has been added
<infinity> And yeah, that's just booting 0x80, so if your BIOS is remapping your stick, that's correct.
<infinity> And it's arguably correct for your BIOS to remap your stick when you select it as the boot device.
<ScottK> Hmmm.
<infinity> (Though this behavious varies wildly between machines)
<slangasek> solution: upgrade your firmware to UEFI
<infinity> behaviour, too.
<slangasek> then you can't run syslinux at all, problem solved
<infinity> Hahaha.
<ScottK> So does this option actually do any good?
<infinity> "solved".
<infinity> ScottK: It made a lot more sense on CDs, which were never remapped.
<ScottK> Right.
<infinity> ScottK: And it makes sense for people who burn our images to DVDs (same argument).
<slangasek> right, if the issue is that you're booted *from* the USB stick, it should probably detect that and translate it to 0x81 instead
<infinity> That's probably still more common than USB sticks, except for serial reinstallers.
<ScottK> slangasek: That sounds sensible.
<infinity> slangasek: That's a fair chunk of extra magic to ask of syslinux.
<slangasek> IIRC the same el-torito boot image is used for both CD and hybrid USB booting, so this magic would have to be in syslinux
<slangasek> infinity: it doesn't hurt to ask
<ScottK> Also it doesn't have to detect it's a USB, it would have to detect that the device it's about to try to boot from is the same one it's already booted from.
<infinity> But yeah, one could do an "if current device = 0x80, shift all menu lookups by 1" or something. I guess.
<ScottK> From the discussion, it seems like that would do it.
<infinity> I'm not sure if it can even reliably know this.
<infinity> Not without more code than it has room to run.
<infinity> Still, yeah, a mildly annoying buglet.
<ScottK> I'll file it and then it will be what it will be.
<ScottK> Turns out there is an existing bug.

[Adam Conrad (adconrad)]

We could switch to using "localboot -1", which calls int 18h, which asks the BIOS politely to "try the next boot device". Whether this would have a higher or lower success rate than blindly trying to boot 0x80, I can't say.

[Emmet Hikory (persia)]

Setting the syslinux status to "Invalid" for now: currently syslinux is being instructed to "localboot 0x80" from the boot menu, which relies on the BIOS actually setting the first (non-syslinux-containing) disk to this address. For folk booting from remapped drives, this fails. Note that there may be a syslinux bug related to this issue, that syslinux may not have sufficient syntax to allow a menu item to express "boot from a hard drive other than the one that just booted" beyond reliance on BIOS calls (e.g. -1 to send 18h): in such a case, if someone wants to repoen this issue against syslinux to address that, rather than creating a new bug, I encourage them to unset the invalid status.