Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

unsupported client firmware type '0' (please file a bug!) #132

Open
coolty opened this issue Jul 29, 2021 · 7 comments
Open

unsupported client firmware type '0' (please file a bug!) #132

coolty opened this issue Jul 29, 2021 · 7 comments

Comments

@coolty
Copy link

coolty commented Jul 29, 2021

sudo pixiecore quick xyz --dhcp-no-bind
[DHCP] Offering to boot 08:00:46:45:c1:bf
[PXE] Unusable packet from 08:00:46:45:c1:bf (192.168.0.10:68): unsupported client firmware type '0' (please file a bug!)
[PXE] Unusable packet from 08:00:46:45:c1:bf (192.168.0.10:68): unsupported client firmware type '0' (please file a bug!)
[PXE] Unusable packet from 08:00:46:45:c1:bf (192.168.0.10:68): unsupported client firmware type '0' (please file a bug!)
[DHCP] Offering to boot 08:00:46:45:c1:bf
[PXE] Unusable packet from 08:00:46:45:c1:bf (192.168.0.10:68): unsupported client firmware type '0' (please file a bug!)
[PXE] Unusable packet from 08:00:46:45:c1:bf (192.168.0.10:68): unsupported client firmware type '0' (please file a bug!)

Trying to boot a Sony PCG-SRX3E/BD Laptop that originally ran Windows XP and has a Celeron CPU...

@PMunch
Copy link

PMunch commented Aug 19, 2021

Just faced the same issue trying to boot a Fujitsu Lifebook B2154 that also runs a Celeron but is intended for Windows 98 or 2000. Booting it yields the same message (with a different MAC address of course). The device itself says "Intel UNDI, PXE-2.0 (build 071)" and simply spins on the DHCP stage of the boot.

@frantisekhanzlikbl
Copy link

Just wanted to say that I have bumped into this as well, on two different devices. I am not sure what details are relevant, but one of them was ARM (RPI4) which, as I understand #72, is not supported, but the other one is a pretty normal x86-64 machine with an AMD CPU and an AORUS motherboard.

@RaitoBezarius
Copy link

Just run into that issue on a Proxmox VM, uncertain how to debug this further.

@Ognian
Copy link

Ognian commented Feb 27, 2023

Same problem, no Idea what to do

@mudler
Copy link

mudler commented Mar 2, 2023

hey @danderson 👋 anything we can do from our side to collect more logs and help?

Can you provide some guidance on how to debug so we can try to come up with a fix/PR?

@danderson
Copy link
Owner

Pixiecore is not being actively developed, so you should not expect bugfixes at this time. I may dust it off and do some poking at some point, but no promises.

Almost certainly you are all trying to netboot arm64 computers, which were all but unheard of for consumers at the time I wrote pixiecore, and so it doesn't support booting arm64 computers. Assuming ipxe knows how to compile for arm64+UEFI, at least some of them should be easy to make bootable. arm64 uboot is harder because those tend to require exact out of band knowledge of the system being booted, so that the right kernel and devicetree can be selected. And apparently raspberry pi rolled their own different thing, I've not looked at what that would take.

I did however find that there is an intermediate different bug, which is that the error you all posted was unconditionally reporting firmware type 0 for all unknown firmware, instead of the correct value. I've fixed that, so you can at least find out how the client is asking to boot (list of values: https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#processor-architecture). To save you the time of digging through the spec and translating hex, you might see one of the following things pixiecore doesn't currently handle:

  • 10: arm32 with UEFI
  • 11: arm64 with UEFI
  • 15: x86 (32-bit) with UEFI and HTTP boot
  • 16: x86_64 with UEFI and HTTP boot
  • 17: UEFI bytecode with HTTP boot
  • 18: arm32 UEFI with HTTP boot
  • 19: arm64 UEFI with HTTP boot
  • 20: pc/at bios with HTTP boot (??? I think it means x86_32 with legacy bios? Dunno ask HP they defined it)
  • 21: arm32 with u-boot
  • 22: arm64 with u-boot
  • 23: arm32 with u-boot and HTTP boot
  • 24: arm64 with u-boot and HTTP boot
  • 41: raspberry pi with rpiboot

Unless y'all want to gift me some computers that use the unsupported architectures, I don't have any of them myself and so am unlikely to add support. Getting a new firmware type to boot is an iterative process of discovering the bugs and quirks of that implementation, and how it needs to be cajoled into booting stuff reliably. I've tried in the past to do this through Q&A on github, and it's just frustrating for everyone involved and doesn't work out, sorry.

If alternatives to netbooting are acceptable, https://netboot.xyz on a USB stick is a handy thing to have around, although of course you need a physical console to do that.

@PMunch
Copy link

PMunch commented Jun 1, 2024

Completely understandable! I was just curious to see which Linux distro I could get running on an ancient machine. For what it's worth the Celeron is x86 (32-bit) and I'm not sure UEFI wa invented yet, but could be category 20 in your above list

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants