iPXE discussion forum

I'm having some problems getting netboot to work on a UEFI based arm 64-bit system (Ampere Computing eMAG). Right now I'm just trying to get Ubuntu to work.

I was originally trying to use a file like:


And was getting this error: http://ipxe.org/err/2e0080

My assumption is that the linux image is not EFI compatible. In the Ubuntu path I'm using there's a netbootaa64.efi file, which (and I have limited experience) looks like the right netboot binary for me to use. But I'm not quite sure how to use iPXE in this way.

Some more background:
Ubuntu netbootaa64.efi path: here
iPXE Version: 1.0.255+
Provisioning Platform: Packet
HW Platform: Ampere Computing eMAG (c2.large.arm on Packet)

I did some tests trying to chain load the efi file, something like:

The error above goes away and the efi file is downloaded, but I get dropped straight into the grub shell with no apparently filesystem*.

*ls in the grub shell gives me (hd0) with no partitions listed. ls (hd0)/ gives me a 'no filesystem found' error.

I also found some threads that reference using the or commands in the iPXE script, but those commands are not found and give an error when the script runs.

Anyone have some pointers to how I can get a netboot of Ubuntu working through iPXE on an aarch64 UEFI based system? Really stuck on this one.

you are starting iPXE on ARM correct? Are you from there starting an ARM kernel?

you will also have to load the proper initrd, and make sure that if the file is initrd.gz, the kernel commandline needs to have initrd=initrd.gz - since that is how it knows which file to load.
Don't try to use grub or anything else, unless you know for sure you have to.
All of this can, and should be done directly from iPXE.

Just use the proper kernel and initrd lines and you would be fine.

(2019-05-02 22:56)NiKiZe Wrote: [ -> ]you are starting iPXE on ARM correct? Are you from there starting an ARM kernel?

Yep, using iPXE on arm aarch64 with UEFI.

(2019-05-02 22:56)NiKiZe Wrote: [ -> ]you will also have to load the proper initrd, and make sure that if the file is initrd.gz, the kernel commandline needs to have initrd=initrd.gz - since that is how it knows which file to load.
Don't try to use grub or anything else, unless you know for sure you have to.
All of this can, and should be done directly from iPXE.

Just use the proper kernel and initrd lines and you would be fine.

My one hangup here is that I'm unable to find a kernel image that actually works. I'm not entirely sure what's going on here, my newness to the area contributes to that.

Here's a clear example.

I use in my iPXE file. And I get an Exec format error (2e008081). So the image seems to be in a format that iPXE deems invalid.

But, and here's a confusing part to me. When I use I get a boot menu and can manually install Ubuntu no problem.

My problem with the sanboot option is that I can't figure out how to pass imgargs to it in order to make it fully automated.

So two questions:

1. Why is the linux image giving me an exec format error when the same image loaded via ISO sanboot method works, boots, and installs Ubuntu?
2. Assuming I wanted to continue with sanboot, since it works (and assuming we can't get #1 to work), how can I pass arguments to the sanbooted image to enable preseed/quiet/auto=true behavior?
   

I think I'm coming to a better understanding about the bootloading process, but need some clarification/validation.

If I understand this correctly, iPXE is a bootloader in a similar vein as Grub. So with iPXE, if you can load the right kernel and initrd images, you can boot/pass control straight to those images. However, in my case, where I use sanboot to load an ISO, I'm loading this image into memory, mounting it as a "CDRom Drive", and booting to it through grub. So in the sanboot case, grub takes over as the bootloader instead of iPXE.

Is this a correct understanding?

If I wanted to continue with the grub method (thought experiment here), could I modify the ISO file's grub.cfg to be something like:


And then repackage the ISO? That, in theory, should tell grub to auto run the first menu item after 3 seconds, and the first menu item would have linux imgargs built into the grub.cfg file? Seems a little hacky, but functional, and within the bounds of what grub is intended to do.

So then where do EFI scripts come in to play? I'm having issues imgfetching the linux image provided by Ubuntu in the arm64 netboot folder. I get error 2e008081 every time I try to load an arm64 linux image from Ubuntu's build repo. My gut is telling me that the image is not EFI compatible (is there a way to test this?). There is however a bootnetaa64.efi file, which seems applicable in my situation.

So back to a question about how iPXE works here - if I try to execute an EFI file through imgload/initrd, does it drop the system into the EFI shell and execute those scripts? Is EFI then responsible for loading and passing control to the right initrd image? Does iPXE ever gain control back?

Do I also need to imgfetch -n any other files from the Ubuntu repo? Like:


Would that work? My current testing is imgloading the bootnetaa64.efi file, but when I do a boot command I get dropped into the EFI shell with no filesystems mounted and no error messages at all.

Small update. I tried:


And same issue, dropping me straight to grub shell with no available file system.

---

Another piece to the puzzle. When I do:


And then:


I see:


Whereas in all of the imgstat examples, an imgtype is auto detected. I've booted this image before via the mini.iso grub method, which makes me think it's a valid linux image, but iPXE is not detecting the img type automatically. Any way to force this?

Going to add one more data point.

Running:

Also gives an 'exec format error'. It seems that iPXE is failing to recognize basically any img type except ISO? Using iPXE v1.0.255+ and EFI is a supported boot method according to the splash page.

that is an x86 / 64 image - it won't boot on arm.
Again you have to use a valid EFI image to boot.
Post the full error message, including ipxe.org url that is shown and try to read that page again.
in EFI the image/boot file is given to the firmware, and started by the firmware, so it has to be valid for the firmware as an EFI image to work.

Fair - the ipxe chain example I just gave was a bad one. I didn't realize that was an x86 build.

The linux images I've been referencing are arm64 specific. They're in the Ubuntu arm64 build tree. Yet in iPXE the image types are not recognized. I'm trying to figure out why that is and what the right images are. The correlated ISO with the exact same image works through iPXE sanboot and subsequently grub.

Here's the screen capture. I've read this page many times. I'm struggling to figure out why the image is invalid and what to do next. I'm especially confused given that a sanboot with an ISO containing the exact same linux and initrd.gz images works, and imgload doesn't.

Alright, I figured it out. Posting my findings here in case someone else stumbles across this in the future.

The main issue is that the linux files hosted in basically all of Ubuntu's builds (netboot, cd-rom, etc) are compressed, but iPXE doesn't have a compression tool built in. So, of course, iPXE doesn't recognize the linux image that I was downloading as a valid file type. I don't know if this is consistent across other Linux distros, that's on my test plan for next week.

The solution was simply to host an uncompressed version of the linux file on an HTTP server. Creating this file was as simple as:


This created a linux file that iPXE could read and then the standard iPXE boot process worked as expected, Ubuntu installed, and all is well in the world.

I might recommend adding to the documented error message. I'm not an expert on the Linux boot flow and I found it confusing that the linux image wasn't explicit in its compression (i.e. with a .gz suffix), while the initrd.gz is (via a .gz suffix).

Thanks for reading and the responses that you gave. I really appreciate the work everyone is doing here.

---

I'll also throw in that bootnetaa64.efi expects local TFTP infrastructure to exist. I feel like a bit of a noob in missing that. I don't have access or the ability to create a TFTP server, so bootnetaa64.efi is a no go. It appears that the EFI file gets successfully executed by iPXE, but fails to get any files ... at all ... but it keeps charging ahead and drops execution flow onto grub. Except that grub has no files, because no files were retrieved by bootnetaa64.efi.

I'm also speculating that the mini.iso method worked because of, well, grub. I'm not confident on this, but it appears that grub CAN handle compressed linux files without fuss. So iPXE successfully sanboots the ISO and hands over flow control to grub, who (a) has access to all the grub files [unlike with the bootnetaa64.efi failure above]; and (b) can uncompress the linux image. So the ISO image works with the exact same images that fail in iPXE, because of grub. That's my guess, anyways.