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

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