@skyhawk3355 I remember awhile ago I needed to create a one-off kernel for a system that had a 486 cpu. I checked but I don’t have that kernel any more.

I just recompiled the linux 6.6.85 for a 586 based CPU. I can recompile for a 486, but I don’t know if that is going to get us anything better.

Here is 6.6.85 586 version
https://drive.google.com/file/d/1GAzFjbtpDVXXCRpe6bIZ5mwySSXeDHko/view?usp=drive_link

Here is 6.6.85 586 where I stripped out some drivers like scsi, nvme, uncommon network drivers, virtualization drivers, etc. I was able to strip out over 1MB of kernel size from the previous one above. Did I through out too much?? YMMV.
https://drive.google.com/file/d/13dE7BLgofsFiNJj_Q8nLDknplRbWRqkJ/view?usp=drive_link

Updating FOG has resolved my issues. Thank you.

@Ced58 I use this model. It’s best to get either the official Lenovo usb c ethernet adapter or the proprietary Lenovo adapter for the special ethernet port on these. Also in the bios there’s a Mac pass through option that you want to set to internal or second Mac address. With the latest version of fog and kernel it should see that internal mac even if you share an adapter for imaging multiple of that device.

@rodluz said in Lenovo ThinkPad L14 Gen 5 - kernel panic:

@jflash Great! Did you use the default kernel from FOG after the update, or did you use the kernel from my repo?

I don’t try older kernel, just put new one 🙂

@pilipp_edv I had a very similar issue to this a while back but it was with an HP laptop. It turned out to be a hardware defect. I was able to get the motherboard replaced under warranty, so maybe you can too for this laptop.

Hello All! (Especially Wilsol)

I used the top configuration ideas from Wilsol, and before I could get through the entire list, darned thing started working. (yeah probably secure boot, thanks Tom for pointing us in the right direction)

Thanks to everyone for the assist.

-Jim

@aurfalien If you are still on this quest. What we would need is the hardware id of this network adapter. You can get this from windows in the device manager. We would need the vend and device IDs.

If in linux then use lspci -nn to get the device IDs. They will be 2 sets of 4 character hex numbers within the square brackets separated by a colon. i.e. [8086:1b4e].

With that code we can see if there are standard linux kernel drivers for this network adapter.

I got this fixed.
i think they fixed it without me but i had an open ticket and was talking iPXE and swapping files and all sorts.

Anyway new firmware 1.21 now working.

@Nyeine I’ve got an Orin Nano at home and an AGX at work. I’m not sure you can image them with FOG. TBH I have never tried, so it would be interesting to find out.

One comment before I get too deep into this, if you use for your dhcp server either WIndows 2016 or later or linux as your dhcp server, you can setup profiles with your dhcp server to automatically send the right ipxe boot loader based on the pxe booting computer. You won’t need to mess with the ipxe.efi files like you have. You can surely continue to do it that way, I just wanted to let you know there might be an easier way to go about it.

So you are able to pxe boot into the iPXE boot loader, as soon as you pick a menu option that is where the wheels come off, so to say. Looking at the screen shot the process is failing at the handoff between ipxe and FOS Linux (arm_Image+arm_init). Its hard to tell if its ipxe or fos linux at fault.

I have a process to create a debug usb image for x64, but I haven’t tried to create one for arm. In theory if you have a working Jetson Orin running ubuntu you should be able to follow this to create a FOS linux usb boot image: https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image In your case you don’t want to use bzImage and init.xy but use the arm_Imag… (to replace bzImage) and arm_init (to replace init.xz). The idea here is to see if you can select register from the grub menu to get FOS Linux to boot on the jetson nx. If it can then the issue is with ipxe. If it doesn’t hopefully you can debug with the usb boot image.

You may need to build a custom linux kernel for the Jetson. Just for reference https://docs.nvidia.com/jetson/archives/r36.3/DeveloperGuide/SD/Kernel/KernelCustomization.html

@yardk Okay, good news, bad news, so good news is the code loading the Arm architecture seems to be working correctly.

Bad news, we haven’t really had much time to troubleshoot against all potential arm devices and I believe this is a semi-known issue that we just haven’t been able to narrow down and/or fix at this point.

If you’re able, can you try loading a 6.1.22 arm kernel or maybe 6.1.89?

I suspect, and it’s just a sneaking suspicion, what you’re seeing is similar to the issue we’re seeing with hyper-v/proxmox and efi loading.

Thanks for clarifying on iPXE and FOS Linux.

@george1421 said in iPXE "Boot from hard disk" not working with RAID.:

Why refind is working is it is configured to find “windows” and boot it out of the box.

I tried configuring refind to boot grub and it partially works.
Grub shows and I can boot windows from it, but when booting Ubuntu Server I get error: failed to install protocols even though I manually installed grub with --disable-shim-lock and disabled secure boot.
Looks like it’s not secure boot related, but more like driver issue and I probably should try that iPXE chain load thing.

@george1421 said in iPXE "Boot from hard disk" not working with RAID.:

What you need is for iPXE to chain load grub.efi from the first partition so that the grub menu starts up correctly so you can dual boot.
I guess that I need to modify default.ipxe?
Could you direct me?

@rodluz , Thanks for your help, this solved the problem.

@george1421 This seems positive, looks like we may have a working solution by the end of the year. Unfortunately as the laptops we are testing this on are the CEO’s and CTO’s new ones, I will not be able to keep hold of them much longer and so they will be unavailable for testing in 2 weeks time. I will keep following the progress of this forum but wont be able to lend a hand to testing.

@Tom-Elliott The stack is as follows: There is a Debian 11 virtual system with a FOG server deployed on it. There is a DHCP server (settings in the screenshot) . There is an MSI Cube 5 12M client from which you need to make an image.
dhcp.jpg
next-server is ip address FOG server

@JJ-Fullmer Thank you for these suggestions. Yes, I am using an install package when doing it manually. I have looked all through device settings, and while I can find the punching feature, I can’t enable it.
I will look into FOG printer settings as well as FogApi powershell module. Haven’t delved into these yet.
Thanks again.

@george1421 Ok thanks for your reply. In the past i already did some research and found the arch 7 flags.

I will check out the uuid and come back with results. Thanks.

@JJ-Fullmer -y does indeed automate the schema updates.

@george1421 There seems to be an issue with the Dell boot manager.
Configuration is as follows:
Boot mode: UEFI
First boot option: Network boot
Second boot option: RAID drive (it is in HBA mode but the same behavior is observed in RAID mode as well)

Exit option from FOG GRUB is configured as EXIT right now.
Default boot option in GRUB is Boot Local Disk.

Booting the Network option is successful and GRUB menu is called. I can reimage the system as needed. But when just waiting to let it boot into the local drive it fails to recognize that it is supposed to go to a second option in the Dell boot menu, and instead of booting from SSD, it goes back to the Dell boot menu.
It can successfully boot into Windows if I choose this option directly from the Dell boot manager and if I put RAID as a first option it goes into Windows fine. But this disables FOG GRUB by default and requires manual interaction in case the system needs to be re-imaged.

I can put a PCIe NVMe drive and disable RAID completely for a sake of experiment.
On Supermicro servers FOG GRUB exits and boots into local drive just fine.

@Bristow-0 That IS very strange that going to the older kernel solved the issue. I’m glad you have it worked out, but maybe the devs need to look into the 6.x kernel a bit more. I can understand that there was a big jump in the kernel code with the 6.x release.