@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

@Atyrrellead said:

1: Am i doing this correctly in general?

Sounds ok from what we know so far.

2: Is there a way to make all of these series multicast at the same time?

You can define groups with hosts independently of the image they use but you cannot schedule a multicast task for those.

This takes us back to question 1. Is it wise to maintain an image for the three different laptop models you have? You should be able to generalize the Windows install

Also I have a separate microsoft account for each laptop to let clients be able to edit their presentations. I have to image my laptops without the account on the computer or it will copy it over.
Is there a to have FOG save those accounts to those specific laptops so I don’t have to log in after every deploy?

Its not advisable to ask two or more unrelated questions in one forum topic because usually one or the other is going to go lost. Probably best if you open a new forum topic for this. Please tell us more about what you mean by “save those accounts to those specific laptops”. I can imagine you can do this using either the fog-client or post-imaging scripts but I would need more information on what exactly needs to be done.

@gn_ro so i should use http on my master node as well, also when i check the /images dir on the storage node it shows all the images on the master node , so i guess its connected some how.

Just checked the firewall on both and they are disabled on both, and i tried http and https on teh storage server with the same issue, so i i guess the only way to is to see if http on the master node would fix it.

@stephanvaningen php-php-gettext is the module it’s looking for, but you can safely remove this. I believe php-common module now provides php-gettext naturally moving forward. Which is part of why Ubuntu/Debian has renamed php-gettext to php-php-gettext.

This is how I addressed the same type of issue with working-1.6, not sure what the best approach with Ubuntu/Debian will be in regards to this though.

@CavArmy We still want to help you but there is a lot of information missing.

@sow20 Are there any error messages that appear when it restarts the capture?

Can you try building your image in a VM so you can take advantage of snapshots? Snapshot before SysPrep, snapshot after SysPrep, reboot the VM and check things work, then revert to the snapshot and try to capture the image.

@cdutko said in Slow Image Deployment Speeds after Updating BZImage Files:

Am I supposed to run this command on a Client that I am deploying to?

Yes, and the client needs to be registered for it to run a debug deploy task. If you want to figure this out you need to look into the details and run those kinds of commands which you can’t if the client is not registered.

Also would it make sense to do this with the Old Kernel? Since that is working… I’m assuming we want to run this Debug command with the new kernel that is ‘not working’ for me.

Well I suggest you do the first round of tests using the new kernel to get some figures. This will tell us if it’s disk IO causing the slowness or not.

@lukebarone Thanks for looking into this.

Can you confirm for me that when you say the POST is failing that you are, in fact, talking about the POST process through the motherboard starting up, and not about Windows attempting to start up?

Yes. When the server powers on it hangs on a “hardware summary” screen. I am unable to even enter the BIOS setup menu (I hit F2 and it continues to hang).

Have you ran a memory test on this system?

I have run a memory test which passed with no errors reported.

I’m going to attempt to take and deploy a raw image and see if that makes a difference.

@Zaqen Looks good I reckon.