@plegrand Since bookworm just was released the developers haven’t had a chance to fully vet the deployment. Unless you have a compelling reason to upgrade, I would hold off if this server is in your production environment. Sometimes walking on the bleeding edge, you could end up with red stuff all over the place.
With the FOG Project and it being summer, the developers are taking it easy for now to spend time with their families.
@Kusa555 So this system just stays at the initializing devices and never leaves? This is rare for undi (bios) mode. The undionly.kpxe boot loader is correct since your computer is in bios mode.
It looks like that hardware was released in 2010 so it should be well supported by FOG.
Check to see if there is a bios (firmware) update for this computer. This issue is specifically between iPXE, bios, and the hardware. Technically FOG hasn’t started in the screen shot.
The last thing I can think of is if this computer has any abnormal add in cards (like networking) where iPXE might have an issue configuring them.
@mdxlp No worries my french is terrible, and my english is not much better 
So we have an example of a post install script for windows, what it does is search through all of the partitions on the deployment disk looking for the windows folder or file. Once that key or flag file is found it knows its the “C Drive”. You should be able to use the same concept with your task. Look for a directory or specific file (like “/etc/hostname”) to know you found the correct partition. From there you can then cat/echo the FOG hostname variable into that file.
Here is the windows focused solution
https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed
Look at the fog.custominstall script. That script locates the partition with the windows directory on it.
This tutorial has the fog variables avaialble for the post install script
https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script/18?_=1686319619362
$hostname is the name assigned to the computer in the FOG web ui
@jeremyvdv If you have a windows dhcp server AND you need to pxe boot both bios and uefi based computers you might want to review this wiki page to setup dhcp profiles so your dhcp server sends the proper boot file name based on the target computer: https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy
@jgibson60 Will you provide screen shots or better explanation of what your error is. Your post leaves a lot of missing details.
Do you get to the FOG iPXE menu?
Do you get an error message from FOS Linux (after the fog banner is displayed)?
@louis-tasse ok the first error is because you did not schedule the task first in the FOG ui. The “NULL” message indicates that there was no task found on the server. This fact is noted in the caveats in the tutorial.
@WT_101 said in RHEL Initramfs unpacking failed: & Kernel panic - not syncing::
snp.efi from Fogproject 1.5.7 & 1.5.8
Unless you are using SANBOOT or EXIT (exit) modes, snp.efi or iPXE for that matter is not responsible for booting a uefi computer. The responsibility for booting uefi computers is handed over to rEFInd. I might suspect that refind version changed between 1.5.8 and 1.5,10.
So do you mean to say if you take snp.efi from fog 1.5.7 or .8 and copy it over to FOG 1.5.10 install you can boot rhel 9?
If you were to recompile iPXE with the very latest code doe it boot rhel 9 correctly (assuming that iPXE is at fault here)?
@Jamaal We are not using the 5530s on our campus so I can only guess its a driver issue, or missing driver issue. The windows “getting devices ready” part is where the drivers are being loaded, its possible that the windows built in drivers are conflicting with the hardware where the real 5530 dprivers are needed to make things work. The drivers being loaded in the setupcomplete.cmd may arrive to late or not at all if the computer never made it to run the setupcomplete.cmd file.
@louis-tasse said in Using FOG without PXE - FOG client on USB key:
if you can provide a starter image for network USB booting that would be awesome.
The instructions for creating the FOS linux boot drive is here: https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image Look at the FOG forum chat for an additional hint.
In regards to what RipAU mentioned that method will also work, you gain the ability of multicast imaging and quick deploy image if you boot using iPXE. As was mentioned you just need to update the boot time script with the IP address of your fog server. FOG has the needed tools built in to compile ipxe, there is no need for the rom-o-matic site that seems to have been retired. I have a tutorial here on how to recompile ipxe on the fog server: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe I would run through the script the first time to compile everything. Now comes the part to integrate what RipAU mentioned. In the based directory where you cloned the fogproject github site (typically /root/fogproject or /opt/fogproject depending on whos instructions you used) There will be a src/ipxe directory. In that directory tere will be a src and src-efi directory, these are the source files used to create FOG’s version of iPXE. If you go into each of those directories there will be a file called ipxescript That is where the startup script for iPXE is.
#!ipxe
isset ${net0/mac} && ifopen net0 && dhcp net0 || goto dhcpnet1
echo Received DHCP answer on interface net0 && goto proxycheck
:dhcpnet1
isset ${net1/mac} && ifopen net1 && dhcp net1 || goto dhcpnet2
echo Received DHCP answer on interface net1 && goto proxycheck
:dhcpnet2
isset ${net2/mac} && ifopen net2 && dhcp net2 || goto dhcpall
echo Received DHCP answer on interface net2 && goto proxycheck
:dhcpall
dhcp && goto proxycheck || goto dhcperror
:dhcperror
prompt --key s --timeout 10000 DHCP failed, hit 's' for the iPXE shell; reboot in 10 seconds && shell || reboot
:proxycheck
isset ${proxydhcp/next-server} && set next-server ${proxydhcp/next-server} || goto nextservercheck
:nextservercheck
isset ${next-server} && goto netboot || goto setserv
:setserv
echo -n Please enter tftp server: && read next-server && goto netboot || goto setserv
:chainloadfailed
prompt --key s --timeout 10000 Chainloading failed, hit 's' for the iPXE shell; reboot in 10 seconds && shell || reboot
:netboot
chain tftp://${next-server}/default.ipxe || goto chainloadfailed
Remove the following lines from that script
isset ${proxydhcp/next-server} && set next-server ${proxydhcp/next-server} || goto nextservercheck
:nextservercheck
isset ${next-server} && goto netboot || goto setserv
:setserv
echo -n Please enter tftp server: && read next-server && goto netboot || goto setserv
now change the very last line
chain tftp://${next-server}/default.ipxe || goto chainloadfailed
Replacing ${next-server} with the IP address of your fog server. Do this for both the fogproject/src/src and fogproject/src/src-ipxe ipxescript files.
Now recompile iPXE and move the updated files to the /tftpboot directory as instructed in the previously linked tutorial.
@WT_101 As I mentioned, FOG doesn’t support imaging over wifi. The first roadblock that you will hit is iPXE because it needs the drivers and then your wifi settings to connect to. The second issue you will have is with FOS Linux, none of the wifi drivers are added into the kernel, nor is any of the wifi utilities compiled into the initrd file system. You would be better served with a usb ethernet adapter.
@louis-tasse said in Using FOG without PXE - FOG client on USB key:
Our organization will not provide its DHCP server to serve our FOG PXE server and thus must rely on a FOG client on a USB key.
is it that your organization provides dhcp services but you can not change its settings? If yes, are your fog pxe clients and fog server on the same subnet? If yes then we can use dnsmask to supply pxe boot info.
I can also give you a starter image for your usb booting if you need it.
@WT_101 please explain what hardware you are trying to pxe boot on. Does it have more than 1 network interface? There is something unique with the hardware where the built in uefi snp driver is not initializing the boot nic.FWIW neither ipxe or fos linux is configured to init wifi adapters. FOG doesn’t support imaging over wifi. While its technically possible FOS Linux doesn’t load wifi networks.
1.) When preparing Windows 10 for cloning (for capturing an image using FOG), is there a need to run and apply the Sysprep /oobe /generalize /shutdown utility. Or FOG, when capturing an image, performs procedures for decoupling Pts from binding to equipment and resets the OS identifier?
Sysprep (system preparation) prepares a Windows client or Windows Server for imaging. Sysprep can remove computer-specific information from a Windows installation (aggregate) so that it can be installed on different computers.
FOG does not react with the target system OS. It is Microsoft’s best practice to sysprep your golden image before image capture. I can tell you from experience if you want to make a neutral image that can be deployed to any hardware you should sysprep the golden image. If you capture from a Dell 5430 laptop and then restore to another Dell 5340 laptop you can image this way without sysprep. Understand that just because it works doesn’t mean this is the best choice. For me always sysprep the image if going to the same hardware or not. That way (for my campus) I have 1 golden image for 12 different hardware platforms both laptop and desktops. I install the required drivers using a FOG post install script, but that is a different discussion.
Quick answer, must sysprep? Yes to different hardware between golden image and target computer. Imaging between the same hardware you should sysprep but I’ve seen people no sysprep cloning and it works.
2.) Does the current version of FOG have the ability to automatically add computers running Ubuntu Server / Ubuntu Desktop to the Active Directory domain when distributing an image?
Quick answer is no, fog will not do this. A bit longer answer is that you can do this when ubuntu boots, and make a bash script to add the computer to AD.
@kamburta The basic steps are here: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images
You will just need to get the right kernel parameters for booting ubuntu live. If you have a live boot CD you can get the parameters from either grub.cfg for the isolinux.cfg files. The steps for live boot are very close to the steps to boot the installer its just the kernel parameters that need to be adjusted.
@mmw_canada lspci and lsusb is already built into the FOS Linux image. You should only need to patch fog.auto.reg if you need extra stuff. There is no need to unpack and repack init.xz unless you really want you. I have a tutorial on dynamically patching the init.xz file here: https://forums.fogproject.org/topic/14278/creating-custom-hostname-default-for-fog-man-reg
@gafferwiles When you use a NAS as a storage node there are a few things that happens.
FOS Linux (the OS that runs on the target computer) loads the image from the target computer onto the storage node (FOG or NAS) using NFS. The files are uploaded using NFS to /images/dev directory which is read write access. Now the user ID and password comes into play. The management user ID and password is used because the FOS Linux OS connects to the storage node using FTP to move the raw data files from /images/dev/<mac_address> to /images<image_name> directory. So you need to make sure the management user ID and password has rights on the NAS to login via FTP and can execute the mv command to move the files.
@RogerBrownTDL First of all, when you delete an image from the list of images (without opening the image definition first) it only removes the image from the database but leaves the raw files on the fog server’s hard drive. From the developers, this is by design. If you open the image definition and delete the image from the buttons inside the image definition it will also purge the raw files from the fog server.
So what to do now?
You will have to manually delete the image file directories using the fog server’s linux command prompt. They are all located in /images on the fog server.
So if you follow the following steps
cd /imagesls -lasudo rm -rf /images/<image_name>There is another command you can run like df -h that will show you the disk partitions with used and free space. You should see the / or /images partition free up as you delete files.
@rivaldydwi I can’t help you with snapins since I don’t use them, but windows itself has a spot to place a batch file that will run just after OOBE/WinSetup and before the first login prompt is displayed.
For this auto execution of the batch file to work you must sysprep your image. If you use sysprep them you can create a batch file called setupcomplete.cmd and place it in a special location. If windows finds that batch file in that location it will run it. Google “windows setupcomplete.cmd” and it will give you directions where to save the file and its exact naming requirements.
The second place you can use if your commands need to have an active desktop is in the unattend.xml file. You can configure the unattend.xml file to auto login as an administrator account, X number of times. There is a section in the the unattend.xml file for firsts run actions. You can have it run 20 different commands if you want. Typically I will set the auto login count to 1 and then the last step in the first run section is to run “shutdown -r -t 0” to reboot the computer.
I know its not what you are looking for with the snapins, but this is an alternate “windows” way to go about it.
@mardonis200 If you get to the fog ipxe menu, then dnsmasq has done its job. Once at the fog ipxe menu dnsmasq is out of the picture. Selecting a menu item will have iPXE transfer bzImage and init.xz. Do you see this transfer or just the flashing cursor?
What computer is causing this problem? Is it just a specific model or all models?
@mardonis200 This all looks good. What seems to be the problem? Is there a specific error you see?
This message is just a notify message: Failed to set DNS configuration: Link lo is loopback device.