mirror of
https://github.com/netbootxyz/netboot.xyz.git
synced 2026-04-25 15:15:56 +03:00
[GH-ISSUE #865] booting fails after version 27 #240
Labels
No labels
Hacktoberfest
Hacktoberfest
bootloader
bsd
bug
confirmed
documentation
duplicate
enhancement
enhancement
enhancement
eol
experimental-merged
freebsd
help wanted
invalid
investigate
ipxe
linux
live-os
memdisk
menu
no-issue-activity
no-issue-activity
pull-request
released
todo
upstream
windows
windows
work-in-progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/netboot.xyz#240
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @klara31 on GitHub (Apr 4, 2021).
Original GitHub issue: https://github.com/netbootxyz/netboot.xyz/issues/865
Describe the bug
When chainloading netboot.xyz.efi version 28 (or higher), netboot.xyz does not boot. netboot complains about a wrong version (1.x, where 2.x is available).
Screen shows initialising devices and reboots. Using version 27, it works OK.
I am using ipxe.efi to boot into boot.ipxe containing:
If I replace this with:
where netboot.xyz.efi is version 27 it works. I have also tried replacing the line with
http://boot.netboot.xyz/ipxe/netboot.xyz.efi, same result.To Reproduce
Chainload version 27 works OK. Version 28 or higher fails.
Expected behavior
I guess this should work for any version, but at least the latest version. But it doesn't.
Additional context
I am struggling on this for quite some time now and cannot figure out why this is not working.
@antonym commented on GitHub (Apr 4, 2021):
Have you downloaded the latest version of netboot.xyz? Are you using an older build of netboot.xyz or coming from stock iPXE?
@klara31 commented on GitHub (Apr 4, 2021):
I have downloaded netboot.xyz.efi version 2.0.35, and it fails. Using netboot.xyz.efi version 2.0.27 works.
Chainloading from stock ipxe.efi version 1.21.1 (g1192e), downloaded from http://boot.ipxe.org/ipxe.efi
@antonym commented on GitHub (Apr 4, 2021):
Does netboot.xyz 2.0.35 work standalone? It just fails when going from stock to netboot.xyz? Each release tracks the latest version of iPXE at that time. Probably would just need to see if there's anything that either changed in iPXE or the netboot.xyz code from the 2.0.27-2.0.28 that would introduce that type of issue.
@klara31 commented on GitHub (Apr 4, 2021):
My dnsmasq.conf contains:
What happens, is that first
ipxe.efiis loaded and nextnetboot.xyz.efi. This works for version 2.0.27 but not for 2.0.35If I put a # in front of the 1st boot line - EFI client (disabling loading
ipxe.efi), booting goes straight intonetboot.xyz.efiand that works for both 2.0.27 and 2.0.35.So booting straight into 2.0.35 works, but chainloaded from ipxe.efi does not.
@github-actions[bot] commented on GitHub (May 5, 2021):
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
@berlin4apk commented on GitHub (Jul 23, 2021):
Not stale
@commonism commented on GitHub (Jul 29, 2021):
I think this may be a problem with the ipxe version used, current ipxe does not chain boot itself here.
For me, this fails:
(can be added as custom in netboot.xyz easily)
I'm using vCenter/ESXI with e1000e nics in the vms.
@antonym commented on GitHub (Aug 19, 2021):
I haven't been able to reproduce this with Proxmox, does it happen with the latest builds?
@commonism commented on GitHub (Aug 19, 2021):
Yes, it is stuck at "iPXE initializing devices…"
For the previous version I enabled debug for the embedded ipxe build - including vmware console debug logging - extracted logs.
I think this was chainloading the ipxe image:
this is a repeating loop
and - I think this was for the snp image or snp-only …
@github-actions[bot] commented on GitHub (Mar 15, 2022):
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.