@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.

@Tom-Elliott
I thanks you very much,
it’s work fine now, fog can see my nvme disk
Best regards
Thierry carlotti
Corsica’s university Pascal Paoli

In the end I am maintaining a separate image, I was able to get management to let us buy a separate surface go 4 for maintaining the 4k disk image.
I found that bhyve based VMs can be set to 4k blocks but it was cumbersome to get it to boot to fog to capture the image at the end. And when that image was deployed, it did not expand on the surface go.

@jmcooper The fault probably exists with the PXE boot rom on the device.

The answer is probably a bit complicated to explain so I’ll try to keep it simple.

PXE booting can use one of the two protocols bootp or dhcp. Its up to the hardware manufacturer to decide which set of fields it looks at for the pxe boot information.

The second part is kind of a dhcp server / pxe rom issue. On each dhcp/or bootp fields there is a byte counter that tells the pxe rom how many characters are in the field name. Common convention also marks the end of a text string with a null (0x00) character. Its up to the dhcp server and pxe rom programmer to decide which method to use (I’m sure there is an RFC document that describes this). I have personally seen this in which someone was not using a mainstream dhcp server, where it only populated the byte counter field and then never terminated the string with a null character. In this case the pxe rom used the null character as end of string and the name requested from the target computer was ipxe.kpxe<with extra characters at the end until a null byte was found>

While I can explain it, it still sucks that the pxe rom firmware is doing this to you.

@flat4vw I guess a couple of things.

Instead of realtek.pxe you probably want to use realtek.kpxe.

The *?pxe files are for bios based computers. They will not boot on a uefi system.

The file is physically located in the FOG server in the /tftpboot directory.

How do you make the computer load the file? Update dhcp option 67 on your dhcp server. Either by the windows dhcp manager or if linux in /etc directory.

@ntrumpff17 The problem is that if you are using the intel hardware assisted software raid (aka intel fake raid) with the hardware controller in (Dell’s term) Raid-On mode and your computer is UEFI based, the linux kernel can’t see the drives behind this intel controller in raid mode.

Now I do have to say I have not tried with the 6.x generation of linux kernels, but the older versions could not see the drives. So the trifecta of the issue is

Intel Raid enabled + uefi firmware + linux kernel == no drive access. If you change one of the variables fog can image the computer.

The reason historically is that Intel has not released the driver interface details so that a linux driver could be built.

@anothersysadmin The stuck at “iPXE initializing…” is iPXE saying that its having a problem configuring the hardware. I can see this happening on really new hardware.

I would start out with ensuing the firmware is up to date on the target computer. See if rebuilding/compiling iPXE with the latest release solves the issue. https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe

Understand this is a problem between iPXE, uefi firmware, and the hardware. FWIW: iPXE is created by another opensource project.

@Tauric said in Can't deploy/register/debug with parallels:

Also for the initrd=init.xz

That is precisely why you should not trust my memory. For a little clarity this is what boot.php file creates for the auto reg function.

kernel bzImage loglevel=7 initrd=init.xz root=/dev/ram0 rw ramdisk_size=275000 web=http://192.168.50.23/fog/ consoleblank=0 rootfstype=ext4 storage=192.168.50.23:/images/ storageip=192.168.50.23 nvme_core.default_ps_max_latency_us=0 loglevel=7 mode=autoreg imgfetch init.xz

So the command at the IPXE> prompt would be
initrd init.xz or imgfetch init.xz There is no equals = sign in the command.

And just to tag along with what Tom said, when I first read your post I was confused if your target computers are ARM or Intel? You menitoned Intel iMac, and then a little later ARM. But I took the ARM reference as it should work because its not ARM based.

OK by setting the logging to 7 and you don’t see a bunch of text on the screen then the kernel (bzImage) is not starting up. So at the IPXE prompt I would try kernel bzImage to see if it is really transferring it. The boot command at the IPXE> should try to run the kernel.

Thanks! 1.5.10. solved the problem!

The strange thing was that on the opening page of FOG 1.5.9, “Latest Version:” was written as 1.5.9. (I can’t show it anymore because I’ve upgraded it to 1.5.10)

@george1421
Disk controller is not disabled in the BIOS.
There’s only one option AHCI and Off.

I was able to pull out log:
6d30483e-1ed8-4c46-a485-593c85c60369-image.png

@iljared98 Without having the hardware in hand I can’t say it will boot or not.

But in general areas where there might be a problem,

firmware settings that cause it to not pxe boot right New hardware that is not supported by iPXE yet (we can work through the ipxe update process to get the latest version) The FOS Linux kernel won’t boot, but we can debug the kernel to find out why.

@totoro said in JLT 6012 rev 2023 - restor boot:

Because I try de load the compatibility checking, with 6-1-22 it’s working, and after a reboot, no anymore,

Can you explain what exactly you mean?

@Florent
Merci ca marche

@asawtell @george1421 Great to see you have been working on this while I was absent. So far to me it looks like a specific issue on this hardware with the Linux kernel.

Would be great if you can boot some kind of live Linux OS, or maybe just an installer ISO will do as well.

The other option is adding additional print output statements to the kernel source code and compile a custom kernel to boot and see exactly where it hangs. I can guide you on this if you are keen to give it a go, let me know.

Also you might see if there is an UEFI firmware update available (not sure if you talked about this already).

you’re right, you can’t use the RAID. this is already off.
I can image the machines, The point is that is doesn’t flow. it needs another reboot so just a little harder to leave them to it. (got quite a few to do 🙂 )

the 2nd is indeed windows but i was wondering if the FOG agent reboot isn’t a full reboot of some kind (what’s the command used by agent) shutdown -r ??
it’s last task would have been joining the domain.

It feels like a FastBoot thing the more i think about it, just didn’t get time to test. If FOG inventory is “fastbooting” it might be skipping where it then boot back into the PXE to continue the deployment

And windows might apply the auto login details from the unattend.xml but not get a full reboot, more like waking from a hibernate (caused by they way FOG agent reboots the system after joining the domain)

@tcso Surely run this by your network admins but if you use my configuration there is low risk to your network infrastructure. https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server?_=1690230679683

dnsmasq is a swiss army knife of services and if misconfigured will cause problems in your network. But using it in a proxydhcp configuration it will only provide pxe boot information only for your network. When the fog server is powered off then no pxe boot information, which you can’t pxe boot without fog anyway. So no harm no foul here. FWIW, proxydhcp is what windows wds uses to configure the target computers for pxe booting. A ProxyDHCP announcement will override anything configured in dhcp options 66 and 67.