@sebastian-roth said in Linux kernel:

Just not sure if it’s worth sending it around the world as I am located in Germany.

His org could just buy you one and have it shipped to you. Of course you are deserving of much more than a crap hardware model, Sebastian. 🙂

@george1421
I got it fixed, seems to be working.

@smcadm Seems like google is your friend here - see this:

Updating the Bios firmware has done the trick and PXE boot is working now…

I really don’t understand what’s wrong with HP notebook’s firmware?! We’ve see the weirdest things happening (fatally wrong initialized registers would cause the linux kernel to freeze when booting on the HP x2 210 devices - they send us a patched firmware more than a year ago but have not released a patched firmware officially yet…). So to make a long story short, I really wouldn’t wonder if PXE booting is going to work for you after firmware upgrade.

#wiki worthy

@Psycholiquid thank you for the pictures and steps! I will get them included into the wiki when I can. @moderators and @testers if you have wiki access, you can help too!

@abrowning just for clarity, there is an issue between the linux kernel, uefi mode, and Dell systems using the intel sata adapter when the sata adapter is in “raid-on” mode. Switching the sata adapter to achi mode will (mask) the issue. This is a documented linux kernel issue and not specifically a fog issue. Commercial linux distributions suffer from the same issue.

NOTE: I moved all the posts about testing the iPXE binaries: https://forums.fogproject.org/topic/10789/boot-file-testing-for-sr

@Tywyn As suggested try updating the machine’s firmware or disabling ACPI in the linux kernel. For the later add acpi=off as kernel parameter in the host’s settings and see if the messages are gone. As George already said, those messages shouldn’t be a show stopper.

@kandresen Which part was it? Just for those that might find the thread in the future.

@george1421
Yeah… I understand the whole meeting thing. Sucks to start working on something and constantly get pulled away on other less interesting things.

I’ll look at that article and see what I can do to integrate it into my processes.

Will report back when I have more information to share.

@sebastian-roth

Hi sorry, I couldn’t answer any sooner.
“Nevertheless we ought to try out using the SNP binary (debug enabled - DEBUG=snp:3,nii:3 to start with). So find 01_snp.efi here. Just give it a try and post pictures or video. Make sure when you take those to place the camera or phone on a stack of books in front of the screen so we have a good picture.”

Here you go, not much to say from my side but here goes: video

Thanks!

@Crixx Did you get to take a picture of the error yet?

@joesay You are welcome! Feel free to ask again and even open new threads if you run into issues again. We will try to help and get things fixed!

@mrcur Great!! rEFInd is a great boot loader (once you tell it where to and not to look).

What’s the contents of that system’s image d1.fixed_size_partitions.

What’s the contents of:

cat /images/<imagename>/d1.fixed_size_partitions cat /images/<imagename>/d1.partitions cat /images/<imagename>/d1.minimum.partitions

This, too me, sounds liek the image was captured before our tests for “fixed” partitions became a little more proper and it resized something that was expected to be fixed size. What partition was it giving this issue on?

@firej8 if your fog server and pxe booting client are on the same subnet you can use the fog server to eves drop on the pxe booting process. Here is a tutorial: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

Upload the pcap file to a google drive or dropbox. If you are uncomfortable posting the link to the form use the forum direct message and send the link to either Sebastian or myself and we’ll take a look at the pcap and keep it private. When we have an answer then you are free to tear down the pcap from your google drive.

it’s all about network througput and storage fastness comparing to the network speed 😉
would be interesting to see the deployment speed with a native 10gbit lan and ssd raid for storage 😛 …and sure the client should have ssd too.

But i can tell you 1gbit lan and hdd in the storage node can easily deploy a 16gb image within 2 minutes to a system with ssd 😉 i see it daily happen again and again hehe

Here is one way to go about it.

Acquire a usb flash drive that is at least 4MB in size (yes I said only 4MB, larger will work but we only need 4MB of space). Format that usb flash drive - fat32. You can do this on a windows box or a linux box. The format must be fat32. On that newly formatted flash drive create the following path \EFI\BOOT (case should not be important, but use all caps as I posted). Now you will need 2 of the iPXE files from the fog server. Copy /tftpboot/ipxe.efi to \EFI\BOOT as BOOTX64.EFI Copy /tftpboot/i386-efi/ipxe.efi to \EFI\BOOT as BOOTIA32.EFI Eject the usb flash drive and then attempt to boot this Dell laptop device from the usb drive using the device’s boot menu.

Taken from here: https://forums.fogproject.org/topic/7435/uefi-pxe-boot-asus-t100-tablet/79

What we will be doing is bypassing the on board pxe roms and loading iPXE right from usb flash drive. Understand this method will only work if iPXE has the drivers built in for this usb network adapter. If this route won’t work for us we have one more last chance option.

I’ll get that info for you tomorrow morning when I am back in my office. I’ve actually yet to open the laptop up. All other stuff isn’t going to be a problem.

Thanks…

@theterminator93 I dug through the iPXE code and read Intel’s PXE spec but I am still not sure why it would hang/loop/lock up (?) right at this point. This is where iPXE calls basic PXE functions (provided by the NIC’s PXE code) to cleanup the base memory before handing over (e.g. to the linux kernel) - explained here. As far as I understand the PXE specification was never very clear and therefor different vendors implement those PXE functions in a different manner.

Years ago in the early days of iPXE (was called Etherboot then) the developers were not sure about the order to call those functions.

There are other PXE boot loaders out there doing things differently. For example see the pxelinux code. It even mentions that iPXE is doing it differently in a comment. Would be interesting to see if pxelinux is doing fine on your USB NIC. This is easy to test as we still have this stuff from the old days. Please change your DHCP option 67 from undionly.kpxe to pxelinux.0.old. As well you want to change the timeout in /tftpboot/pxelinux.cfg/default to TIMEOUT 05 so it’s not just flicking through. Boot up your client and see what happens. My guess is that you see the pxelinux menu and then it properly chainloads ipxe.krn which then probably hangs as it used to with the other iPXE binaries. In case it hangs on a kernel panic then we are hitting a different spot.

As well I added more debugging statements to the code and compiled a new 10_undionly.kpxe (download, compiled with DEBUG=undinet) for you to test. Please post a picture of the messages on screen again. By the way I don’t see the pictures hosted on photobucket anymore - says “please update your accound to enable 3rd party hosting”.

I think we are good folks, sorry to bother!

Thanks for timely answers and support.

Cheers