@Sebastian-Roth Thanks I change the mounting point then it works.

@Tom-Elliott

I hadn’t thought to check in that direction. But you are correct.
BASE64 encoding what is in the database matches what is displayed in the web UI.

Thank you for the help.

@george1421 Thank you very much!

Hey guys,

Thanks for replying. I have found a solution and that was to clear out the Storage Node Disk Usage. It was full.

Thanks again.

Update:

Trying the installation again worked.

¯_(ツ)_/¯

@MikeWall We have a plugin for Product keys already…

https://github.com/FOGProject/fogproject/tree/working-1.6/packages/web/lib/plugins/windowskey

https://github.com/FOGProject/fogproject/tree/master/packages/web/lib/plugins/windowskey

Problem solved !

Thanks a lot !!

sorry for the delay

i solved it.
It was a Pre-Install System from a Distributor with a lot of bloatware, what i first not know.
I installed a Clean Windows 11 System and then i could capture the Image.

@switch_apoc Well, this forum topic is pretty straight forward. Just start reading upwards beginning from this post: https://forums.fogproject.org/post/135069

Hello Sebastian,

this is my original d1.minimum.partitions file:

label: dos label-id: 0x4ff028f0 device: /dev/sda unit: sectors sector-size: 512 /dev/sda1 : start= 2048, size= 2196723, type=7, bootable /dev/sda2 : start= 2198771, size= 75451766, type=7

this is my original d1.partitions file:

label: dos label-id: 0x4ff028f0 device: /dev/sda unit: sectors sector-size: 512 /dev/sda1 : start= 2048, size= 2196723, type=7, bootable /dev/sda2 : start= 2198771, size= 264139264, type=7

What i did is to change the size of sda2 (my windows partition).
The original start was 2198771 sectors x 512 Bytes = 1125770752 Bytes div 4096 equals = 274846,375 - not good !
To align the partition correctly i used 2199552 sectors =
1126170624 Bytes / 4096 = 274944 - that’s good !

You just need to choose a sector start that is divisible by 4096.
I took my size from a aligned partition where AS SSD showed me that
1099776K would be ok. 1099776 x 1024 Bytes = 2199552 x 512 Bytes

Easy maths - but it is annoying , here 512Bytes shown here, 1024 Bytes shown in AS SSD and 4K Bytes needed to calculate the correct sector size.

@lperoma Thanks for the update. Good to hear you found this and were able to fix it. Well done! This is beyond FOG itself and it would have taken a lot of posting forth and back to figure this out for us. Although I don’t know much about virtiofs I can imagine it causing problems when being exported as NFS (as FOG does).

@zaboxmaster Just in case you haven’t found out about post deploy scripts yet: https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script

@FrSainCpel
It appears to me that your block ‘:retry_left’ will cause an infinite loop if it failed to boot.

The line ‘set keep-san 1’ is no longer necessary when sanhooking (or sanboot) is used .

As you are setting up an static IP, you’d need to do an ‘ifopen net0’ first’. With dhcp, it does that for you.

I’d suggest put the net0/ip first before the netmask.

Lastly, @george1421 is correct, you’d need

set net0/gateway 0.0.0.0

@Sebastian-Roth said in Storage Node Kernels:

Yes, that’s another way to do it.

Actually, for us it is necessary (even for the master node) as we’re are isolated from the internet. That means the installer will fail to download inits and kernels.

@Sebastian-Roth Sure, happy to help in any way I can…

@Omar_Medhat How big is the iso image.

There are some limitations you need to be aware of.

Memdisk will only work in bios mode. Memdisk is a 32 bit application so that limits the size of the iso image to 2GB. To boot out of an in memory iso image, your system needs enough ram to contain the entire contents of the iso image AND enough free ram to run the OS from the ISO.

To the second part of the question, can you boot a .efi file via a custom menu. Probably.

Your custom menu configuration will probably look like something similar to this:
Menu Item: os.special_fw_update
Description: Firmware Update for this system
Parameters:
kernel tftp://${fog-ip}/bios_file_updater.efi
boot || goto MENU
Menu Show with: All Hosts

Where bios_file_updater.efi is the name of you unnamed update file. That file will need to be in the /tftpboot directory on the fog server.

ref: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images/9

@naughtydog said in PXE Boot Deploy Image Menu not showing up anymore:

snp.efi is unreliable too. So it looks like a general UEFI problem.

General is a vast phrase. Some devices play nicely with a iPXE binaries but do not when using a different one while other hardware works perfectly fine using the later.

@cammykool OK based on the picture and the “Boot to FOG” message I see you are using dnsmasq and its at least running. Please post the dnsmasq config file here. If the config file looks good, then we will perform a packet capture of the dhcp process to see what the target computer is being told to do.

@Backpain This looks like a normal FOG config file. It is setup exactly how you need it.

So let me ask a bit more about your network.
1, It looks like all devices (fog server, pxe booting computer) are on the same subnet. Is that correct?
2. If yes is that vlan 4 an isolated network used just for imaging or is it a general purpose vlan with many types of devices on it?
3. Is there any chance another dhcp server is responding to the pxe boot requests? Either by a dhcp-relay / helper service on your vlan router or by directly having a second dhcp server on your network?

Beyond the questions, I think our next step is to see if we can get a packet capture of the pxe booting process to see where the client is being directed and by whom. I have a tutorial here: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue?_=1673391869214

Upload the pcap to a file share site and post the link here and I’ll take a look at it. If you want to review it yourself, use wireshark to open the pcap file. Look at the dhcp OFFER packet. This will be from your dhcp server. Look at the dhcp header for the next-server and boot-file fields. They should contain data… but there are two many what-ifs here, its probably best to let me look at it

Hey !
I’m back … with some good news : it’s works !
After deployed the new 21h2 clean image, i can see the C:\Windows\DRV\x64 on the 640G2 !
Youpiiiiiiiiiiiiiii … but … the script fog.copydrivers can used .CAB with DELL or not ?
Because i tried to deploy my 21h2 clean image on a o7050 … and no DRV folder after deploy … maybe we need just use x64 folder for all machines instead of .CAB for DELL now ?

#!/bin/bash ceol=`tput el`; manu=`dmidecode -s system-manufacturer`; dots "Identifying hardware" case $manu in [Ll][Ee][Nn][Oo][Vv][Oo]) machine=$(dmidecode -s system-version) ;; *[Dd][Ee][Ll][Ll]*) machine=$(dmidecode -s system-product-name) ;; *I[Nn][Tt][Ee][Ll]*) # For the Intel NUC and intel mobo pick up the system type from the # baseboard product name machine=$(dmidecode -s baseboard-product-name) ;; *) # Technically, we can remove the Dell entry above as it is the same as this [default] machine=$(dmidecode -s system-product-name) ;; esac # if the machine isn't identified then no need to continue with this script, just return to caller if [[ -z $machine ]]; then echo "Unable to identify the hardware for manufacturer ${manu}"; debugPause; return; fi echo "${machine} Identified"; # Removes Spaces in machine name, works better with path definitions machine="${machine%"${machine##*[![:space:]]}"}"; # Jeffrey Boulais posted that the above code did not work for his install. He # supplied this code as an alternative. If you run in to a problem using my code # comment out my code and see if his code works better for your installation. The # only right way is the one that works. Thank you Jeff for your input. # machine="$(echo -e “${machine}” | tr -d ‘[:space:]’)" dots "Verifying we've found the OS disk" if [[ ! -d /ntfs/windows && ! -d /ntfs/Windows && ! -d /ntfs/WINDOWS ]]; then echo "! OS root Not found !"; debugPause return; fi echo "Found"; dots "Verifying target Arch" system64="/ntfs/Windows/SysWOW64/regedit.exe" [[ ! -f $system64 ]] && arch="x86" || arch="x64" echo "${arch} found"; debugPause # set osn path names based on the osid set in the FOG WebGui case $osid in 5) osn="Win7" ;; 6) osn="win8" ;; 7) osn="win8.1" ;; 9) osn="Win10" ;; esac dots "Preparing Drivers" clientdriverpath="/ntfs/Windows/DRV" # remotedriverpath="/images/Drivers/$machine/$osn/$arch" remotedriverpath="/images/Drivers/$osn/$machine/$arch" debugPause if [[ ! -d "${remotedriverpath}" ]]; then echo "failed"; echo " ! Driver package not found for $osn/${machine}/$arch ! "; debugPause; return; fi echo "Ready"; debugPause [[ ! -d $clientdriverpath ]] && mkdir -p "$clientdriverpath" >/dev/null 2>&1 echo -n "In Progress" rsync -aqz "$remotedriverpath" "$clientdriverpath" >/dev/null 2>&1 [[ ! $? -eq 0 ]] && handleError "Failed to download driver information for [$machine/$osn/$arch]" debugPause # the following code is only valid for Windows 7 operating systems since Windows 8 and beyond # relies on the unattend.xml section to locate OEM drivers. If you are no longer deploying Win7 # you may exclude this section. regfile="/ntfs/Windows/System32/config/SOFTWARE" key="\Microsoft\Windows\CurrentVersion\DevicePath" devpath="%SystemRoot%\DRV;%SystemRoot%\inf;"; reged -e "$regfile" &>/dev/null <<EOFREG ed $key $devpath q y EOFREG