Created attachment 600190 [details] libvirt log Description of problem: When setting up a guest and configuring it to boot using ipxe, they just fail. It seems the room has some kind of hardcoded url. Version-Release number of selected component (if applicable): qemu-kvm-1.0-17.fc17.x86_64 Steps to Reproduce: 1. Create a regular VM 2. Set it up to boot on PXE 3. Start it Actual results: It fails to boot and no ipxe prompt is available. Expected results: Am iPXE prompt should be provided. Additional info: I will add the log file. I am using virt-manager/libvirt for trying this out.
Created attachment 600191 [details] no pxe prompt this screenshot shows the resul.
It seems as if this is a regression, because it is possible to enter the iPXE prompt in libvirt under F16. Maybe the firmware was build without the prompt?
Re-assigning this to ipxe as it seems that F16 is using gpxe and F17 ipxe.
It seems that the patch http://pkgs.fedoraproject.org/gitweb/?p=ipxe.git;a=blob;f=ipxe-banner-timeout.patch;hb=HEAD is disabling the prompt: https://git.ipxe.org/ipxe.git/blob/HEAD:/src/core/main.c#l47 But why is this?
That patch stops IPXE delaying boot for several seconds even when PXE is not requested by the BIOS. If you request PXE with 'qemu -boot n' then the PXE prompt will still be displayed
(In reply to comment #5) > That patch stops IPXE delaying boot for several seconds even when PXE is not > requested by the BIOS. If you request PXE with 'qemu -boot n' then the PXE > prompt will still be displayed On F17 with all updates(-testing) libvirt starts a pxe guest with "… -boot order=n,menu=on …" and this doesn't bring up the iPXE shell/prompt. Am I doing something wrong?
(In reply to comment #5) > That patch stops IPXE delaying boot for several seconds even when PXE is not > requested by the BIOS. If you request PXE with 'qemu -boot n' then the PXE > prompt will still be displayed You are right. I must have been blind.
Please don't disable that patch ...
(In reply to comment #8) > Please don't disable that patch ... But, is there a workaround while using libvirt/virt-manager?
Created attachment 600566 [details] Screenshot of the boot screen. This is a screenshot of a simple VM - without the iPXE prompt. Maybe it shows up before the screen can be seen (time to connect spice/vnc to instance).
Created attachment 600567 [details] pxe guest domain definition
(In reply to comment #7) > (In reply to comment #5) > > That patch stops IPXE delaying boot for several seconds even when PXE is not > > requested by the BIOS. If you request PXE with 'qemu -boot n' then the PXE > > prompt will still be displayed > > You are right. > I must have been blind. I must have mixed stuff up (suppose I tried on a F16 host again). But now I got a screen shot of it (see above).
Created attachment 600569 [details] Screenshot of a guest on F16 with a gPXE prompt The prompt - on this F16 shot - disappears after a short amount of time (~3secs).
(In reply to comment #5) > That patch stops IPXE delaying boot for several seconds even when PXE is not > requested by the BIOS. If you request PXE with 'qemu -boot n' then the PXE > prompt will still be displayed How long is it going to be displayed? Maybe the virt-viewer is taking to long to get the first picture so that the prompt has already disappeared again, which makes it unusable. But I also can't confirm this theory.
In Fedora 17, there is not prompt. I can only see this error message "Nothing to boot: No such file or directory (http://ipxe.org/2d03e13b) I will attach a screenshot of the error with this message. This was done using: qemu-kvm -boot n
Created attachment 600574 [details] ipxe error message The command issued was: qemu-kvm -boot n
For F16 it is correct that $ qemu-kvm -boot n get's an iPXE prompt. But you don't get the prompt on F17 using $ qemu-kvm -boot n or $ qemu-kvm -boot order=n,menu=on This opens just the boot device menu, but not the iPXE prompt.
(In reply to comment #8) > Please don't disable that patch ... No, the patchs hould not be dropped. But the timeout should be increased to something like 3 secs (which could still be a bit low for remote connections, but I suppose that's a corner case ...)
If there are no objections to adding a timeout of 2 or 3 seconds, why not just add them?
Fabian, though it wasn't clear, there _is_ objection to adding back the banner timeout, because it slows down every boot regardless of the -boot options passed (although a guest with no network devices seems to skip any ipxe bits). This is particularly bad for libguestfs which launches a guest appliance for all its functionality and has no need for pxe. I'm pretty ignorant here, but I don't see why pxe should even be asking for a prompt if we don't specify -boot n or -boot menu=on. Maybe we just skip loading ipxe altogether if -boot n isn't explicitly requested. (I guess -boot just specifies boot order, and doesn't impact what devices are actually marked as bootable? Is there any way to say a device is 'not bootable', or disable booting from network entirely like you can do with a physical machine bios?) Alex (or gleb, or paolo, or anyone), any thoughts here?
Increasing the default timeout for -boot menu=on should be fine. I think that's what Fabian was requesting.
Cole, I wasn't aware that libguestfs is using PXE boot. But Paolo is right, there should just be some way to get the iPXE prompt - It does not need to be default. Just offering the prompt when -boot menu=on is selected would be a good way.
(In reply to comment #22) > Increasing the default timeout for -boot menu=on should be fine. I think > that's what Fabian was requesting. There is no fw_cfg support in ipxe as far as I know.
No, there is none. It would require an iPXE patch.
Is there now a way how the iPXE shell/prompt can be accessed?
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This is still an issue in rawhide
Hi, is there any workaround for F18? I need to boot from iscsi using sanboot command. Or is there any other way than via iPXE prompt? Thanks
(In reply to Radek Vykydal from comment #29) > Hi, is there any workaround for F18? I need to boot from iscsi using sanboot > command. Or is there any other way than via iPXE prompt? Thanks Radek, I think it could work if you would be booting an ISO containing the iPXE rom, then you could go into that iPXE prompt to do your boot. But honestly, maintainer, can't we get this back? Or an improved version?
Do you guys care about this in VMs or physical machines? Maybe we can ship two versions, one with timeout and one with no timeout. qemu would default to the latter but you can override it on the command line or through libvirt. Is that acceptable?
(In reply to Cole Robinson from comment #31) > Do you guys care about this in VMs or physical machines? Maybe we can ship > two versions, one with timeout and one with no timeout. qemu would default > to the latter but you can override it on the command line or through > libvirt. Is that acceptable? I don't think shipping two versions is a good approach. I think the PXE BIOS needs to be able to read the timeout from the firmware config (in the same way seabios is able to read boot order), then QEMU needs to provide a CLI flag to let libvirt set the timeout for PXE BIOS. Then we wouldn't have to hack the source to force disable the timeout in this way.
I need it in VMs. I'd be fine with possibility of overriding through libvirt.
(In reply to Daniel Berrange from comment #32) > (In reply to Cole Robinson from comment #31) > > Do you guys care about this in VMs or physical machines? Maybe we can ship > > two versions, one with timeout and one with no timeout. qemu would default > > to the latter but you can override it on the command line or through > > libvirt. Is that acceptable? > > I don't think shipping two versions is a good approach. I think the PXE BIOS > needs to be able to read the timeout from the firmware config (in the same > way seabios is able to read boot order), then QEMU needs to provide a CLI > flag to let libvirt set the timeout for PXE BIOS. Then we wouldn't have to > hack the source to force disable the timeout in this way. Nobody is really lining up to do that work though. And the complaints here are a side effect of how Fedora does a non-default build of ipxe. Shipping two roms sucks but at least it would give people a workaround until fwcfg support appears.
(In reply to Cole Robinson from comment #35) ... > Nobody is really lining up to do that work though. And the complaints here > are a side effect of how Fedora does a non-default build of ipxe. Shipping > two roms sucks but at least it would give people a workaround until fwcfg > support appears. I also don't like the idea of two roms ... Is there a bug to track the progress of thw fw_cfg support in ipxe?
(In reply to Fabian Deutsch from comment #37) > (In reply to Cole Robinson from comment #35) > ... > > Nobody is really lining up to do that work though. And the complaints here > > are a side effect of how Fedora does a non-default build of ipxe. Shipping > > two roms sucks but at least it would give people a workaround until fwcfg > > support appears. > > I also don't like the idea of two roms ... > Is there a bug to track the progress of thw fw_cfg support in ipxe? There's a RHEL7 bug for the same issue bug not sure if it's appropriate to publicly post the bug number, either way there isn't any progress reported there yet. The reason I proposed two ROMs is because there's no indication if or when the proper fix will ever be implemented.
Fixed in ipxe-20140303-1.gitff1e7fc7.fc21
I've verified that the new ipxe-qemu-roms package doesn't affect libguestfs.