omnios-r151046-rc3 PXE Boot fails on Simply NUC Topaz 2 i7 #246
Comments
|
The product page says, "2x 2.5Gb Ethernet port". This means it likely has the Intel I225 or I226 Ethernet chipset, for which illumos does not yet have support. I cannot explain necessarily the usb-boot installer failure, but while illumos may boot on this, it cannot use the built-in I225/I226 Ethernet just yet. |
|
Good point. It has 2 x Intel I225-LM. I have also observed some MAC address strangeness with these two devices. I'm not familiar with how I should have mentioned that I have disabled secure boot (another potential source of problems). |
|
Tried another approach. I have a Plugable USBC-E2500 so I tried using that as suggested on the iPXE Forum. This also fails with both It appears that iPXE is unhappy with the format of Does OmniOS have drivers for USB CDC-NCM or CDC-ECM devices? |
|
Perhaps the EFI boot expects EFI format files? Built a simple x86_64 UEFI application and replaced |
|
Thought I would see if it was possible to PXE boot the Plugable USBC-E2500 without using iPXE. Copied the appropriate UEFI UNDI Driver to This loads the driver during boot but, unfortunately, it doesn't support PXE. The EFI Variables can be removed with: It took me longer than I expected to find out how to set and clear DriverOrder and Driver#### so I have recorded it here in the hope that it will help others avoid a similar search. |
|
As It seems that OmniOS Installation via PXE Boot may need updating for EFI systems. As it appears that neither the Intel I225-LM nor Plugable USBC-E2500 have drivers for OmniOS I suspect I won't be able to investigate further with the limited amount of hardware I have available. I did try on a Hyper-V Generation 2 VM which did something broadly similar. It would be interesting to know if anyone can get further on supported hardware. |
|
Screen capture from the PXE boot on the Hyper-V Generation 2 VM at the point where it sticks. I know that the install from the .iso media doesn't work either. However, it does get as far as loading unix so there might be some insights into why the PXE install fails. |
|
Monitored the tftp requests and discovered that there were files missing from /tftpboot as populated by kayak. Here's the results after adding the missing files: It then looped requesting Changed to serving dhcp, tftp and http from an OmniOS VM. Much better! Both the Simply NUC Topaz 2 i7 and the Hyper-V Generation 2 VM get as far as starting the PXE Installer (see attached). 
So it looks like adding the missing files to kayak will fix that part of the problem. It would also be good to change the comment in the first line of Neither PXE installation attempts run to completion. I'll provide details in a later comment. |
|
There were some Those tagged with (*) are still missing which may be as expected? |
|
Next hurdle. Failing to load And for the Hyper-V Generation 2 VM: Wild guess is that it is using an uninitalised variable. Looking at Might be barking up the wrong tree, but the kernel appears to be an ELF 64-bit LSB executable. |
|
Rebuilt Neither "Reached" message was displayed. Looks like I was barking up the wrong tree. |
|
Think I may have found a problem with the Multiboot2 header in omnios-r151046.unix. Here's the header extracted from the file: and here's the output of Looking at the MULTIBOOT_HEADER_TAG_ADDRESS entry the fields are: The file offset of This may not be the source of the problem but it looks like an error. |
|
The immediate cause of the
More generally, I'm puzzled how this code is expected to load the kernel and why the size of the file containing the kernel is used. I need to take a closer look at the Multiboot2 specification. |
|
The I don't think that the value of Maybe a better approach would be to make the loader ELF aware? This is hinted at in the description of the address tag in 3.1.5 The address tag of Multiboot2 header in Multiboot2 Specification version 2.0: Note: This information does not need to be provided if the kernel image is in ELF format, but it must be provided if the image is in a.out format or in some other format. When the address tag is present it must be used in order to load the image, regardless of whether an ELF header is also present. Compliant boot loaders must be able to load images that are either in ELF format or contain the address tag embedded in the Multiboot2 header. Additional tags may be required in the Multiboot2 header such as 3.1.8 EFI amd64 entry address tag of Multiboot2 header and 3.1.12 EFI boot services tag. |
|
As an experiment, I have tried to use grub2 from Fedora Linux 38. This is what I tried from the grub2 interactive prompt: For the Hyper-V Generation 2 VM the following was displayed on the console: I'm not sure how kernel command line arguments are supposed to be passed in grub2 ... |
PXE Boot fails on a Simply NUC Topaz 2 i7. Displays
NBP file downloaded successfully.then drops through to the next boot option, without trying to get any further files using tftp. Bothpxebootandpxegrubfail. Attached is a Wireshark capture forpxeboot(the capture forpxegrubis similar except for the packet count so is not attached). The server (192.168.88.1) and topaz (192.168.88.2) are connected back-to-back on a single cable.Possibly the same underlying problem as omnios-r151046-rc3.usb-dd fails on Simply NUC Topaz 2 i7.
I have successfully PXE booted Ubuntu Server 23.04 (Lunar Lobster) as far as the selection screen on the same configuration.
topaz.pcapng.gz
The text was updated successfully, but these errors were encountered: