@GorkaAP Ok your explanation is very clear of the problem.

I have a couple of ideas here:

An additional building, located 4 kilometers away, shares the same network subnet.

I have see remote locations connected via a WAN have issue with loading the iPXE boot loaders via tftp. In this case the computers would error out where it can not download the NBF boot file. The issue was related to the tftp block size being larger that the MTU packet size on the WAN. If you are direct conneted between the remote building with fiber this is probably not your issue.

Having both locations on one subnet makes things a bit harder since dhcp works off broadcast domains and your local and remote locations have the same broadcast domain since they are on the same subnet.

The FOG booting process is such
PXE Rom (target computer) boots and queries dhcp to find dhcp options 66 and 67
PXE Rom downloads the bootloader pointed to by options 66 and 67
The iPXE boot loader boots and again queries dhcp for dhcp option 66 to locate the FOG server.
The IPXE boot loader then will chain load to the fog server over tftp default.ipxe
default.ipxe will chain load boot.php.

If you are on the same subnet between the sites and it works at the main campus but not at the remote campus then this is the first time ipxe chain loads to http instead of tftp. From the remote campus can you get to the fog server’s web ui?

It might help to debug if you can snap a clear picture of the error message on the target computer as you get the chain load error.

One additional thing I can think is if you have more than 1 dhcp server within this broadcast domain (such as a primary/slave) make sure both have the proper dhcp option settings. I have see two dhcp servers with one having the setting configured and the other without cause random issues. Whichever dhcp responded first the client would use (one having the proper boot setting and the other without).

Bonus additional thing: You are using dnsmasq to provide pxe boot information. Could there be something filtering out the DHCP Discover packet from the client at the remote site? I can see where/if DNSMASQ would work at the main campus, where the remote campus might not, if the DISCOVER packet is getting lost on its way to the DNSMASQ service. You can test this on the dnsmaq server by using tcpdump and monitoring for port 67 or port 68 Now power on a computer at the remote building, do you see the DISCOVER packet arrive at the dnsmaq server? The DISCOVER packet starts the process in DNSMASQ to send the pxe boot information to the target computer.

Bonus++ thing. If your link speed to the remote location is less than 1GbE you can install a fog storage node at that location and deploy your computers using the storage node. (this assumes you solve the pxe booting issue). You will install the location plugin into fog then assign computers to the remote location as well as the storage node. It will still boot using the main campus dhcp and tftp server, but actual image deployment will happen via the storage node not the WAN link.

@mashina Running this dual boot environment is always a pain to manage. Its probably best/quickest to do this with a virtual machine.

I know this will look like a lot of steps to test out an idea, but if it works then it will also help you with your deployment workflow.

So how I would go about trying to figure this out is to go ahead and deploy/create windows 11 to disk 0 on your mother computer and capture that with FOG single disk resizable.

Now deploy/create linux to your mother computer and capture that with FOG using single disk resizable. This may/will overwrite the windows 11 install with linux on the mother computer.

So what you will have is 2 images (1 Windows and 1 Linux) both captured from disk 0. This will be a complete and bootable image with the efi partition intact.

Now create a target computer (VM) with 2 hard drives. Register that target computer with FOG, and set the target disk to disk 0 (/dev/sda for a sata disk or the nvme disk name for a nvme drive) in the host configuration. Now deploy the windows image to this target computer. Once the deployment is done, verify the computer boots. Go into the fog ui and the host configuration for this target computer, and change the target disk to disk 1 (/dev/sdb). Deploy the linux OS to disk 2. Note: there are other ways to go about this but the goal is to have 2 hard drives with a complete OS with UEFI partition on each disk.

Now that you have the groundwork in place, go into the target computer’s uefi firmware. The uefi firmware should see both disks with valid uefi bootable disks on it. If you made it this far and the firmware can see both disks as uefi bootable, then exit out of the firmware setup and reboot the computer. The next step is to access the target computer’s uefi boot manager. On Dell computers you keep pressing hit the F12 key quickly as soon as you see the Dell logo. In the uefi boot manger you should be able to pick windows 11 or linux boot disk. Test both operating systems. If you can boot both without issue then you are 90% of the way done.

The next decision is how you want the user to select which OS to boot.

1. The UEFI firmware boot manager via F12 key
2. The windows boot manager
3. The linux boot manager (grub)
4. If you PXE boot through FOG, you can create a boot menu using refind (FOG’s UEFI exit boot manager)

Now on the workflow moving forward. The target computer’s configuration still points to disk 1 for all new image deployment. So any new images will be deployed to disk 1 (remember that windows is on disk 0). So if you have it setup the user can pick any OS images from the list and they will always be deployed to disk 1 (the transient disk) without touching the windows boot image.

@GorkaAP I hate to begin with this, but that referenced document deals with a 10 year out of date version of FOG.

Lets see if we can work out a solution using a current release. Please state the problem you are trying to resolve.

@mashina I guess you will need to decide your best method for deploying these linux distros to the target computer.

1. As in the referenced post netboot into the native linux distro installer and install linux that way.
2. Create a standard image and capture that standard image for the user’s to deploy.

The method you use is really dependent on the skill of the user that will install linux. Both methods have their advantages. With option 1 you get the most flexability, but also requires more technical skills on the user. Option 2 you can create a custom linux install with all of the required apps preinstalled.

@professorb24 I can read your post a number of ways. Let me see if I understand the intent. Let me use my words to describe your issue as I understand it.

You imaged a computer with the same image that works with an HP laptop onto a Lenovo. When you boot through the FOG iPXE menu on the HP, it exits correctly and the target computer boots as expected. But when I boot through the FOG iPXE menu with the Lenovo it fails to boot saying inaccessible boot device.

If I understand the issue correctly, then if you changed the boot order on the lenovo so that it boots directly from the hard drive does it boot correctly? In my mind its not clear if it is an image issue (something wrong with the information on the disk) or is it an iPXE or refind issue.

@plyons7890 The error message about an unclean file system is typically related to the source computer not being powered off correctly and files are still marked open.

If the source computer is a ms windows computer I can understand this error. You must not use the standard “shutdown” command because it is not really a shutdown/power off command but more of an advanced sleep command, leaving files open.

You can/should do the following

1. Let sysprep power off the computer before cloning with FOG.
2. Turn off fast startup in windows, this will switch shutdown into its traditional shutdown mode.
3. Use the windows shutdown command shutdown -s -t 0 command to power off the computer before cloning.

@plyons7890 said in Creating image - permission denied:

x.x.x.x:/images2/dev/

Where is this path coming from? Its not a fog standard path.

What is the output of this command showmount -t 127.0.0.1 if you execute the command from the fog server’s linux command prompt.

@AdKlSc There was an issue with the FOG Project web site in 2018 or 2019 where we lost all uploaded images. Unfortunately I see that post lost it images. Are you having a specific problem following the tutorial?

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

@professorb24 I’m not sure I understand your problem. I can read your post a few ways.

First let me say does the target computer download the NBP files? Does iPXE kernel start but iPXE is unable to obtain an IP address?

@GlaDio For reference.

bios firmware needs a bootloader like: undionly.kpxe
uefi firmware needs a bootloader like: ipxe.efi or snp.efi

If you have a linux or windows dhcp server then this guide will help you setup a dynamic pxe boot: https://docs.fogproject.org/en/latest/kb/how-tos/bios-and-uefi-co-existence/#example-1

If you are using some other dhcp server it might have the feature for dynamic pxe booting built in. If not we can use dnsmasq to provide the pxe boot information that is dynamic.

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

@coolpolo76 This thread may be helpful to your cause: https://forums.fogproject.org/topic/17186/how-to-update-memtest86-to-6-20

@unknown56 The answer is its complicated but not impossible.

Lets take this one step at a time.

1. Is is possible to use a synology NAS or most other NAS’ that have nfs, and ftp support. I have a older tutorial on how to configure a synology nas for a storage node. https://forums.fogproject.org/topic/9430/synology-nas-as-fog-storage-node

2. Within FOG ecosystem, only master nodes (typically fog servers) can capture images from target computers. You can not capture images to Storage nodes. There is one way replication from a master node (fog server) to a storage node. This replication only runs on the master node or fog server. So you would normally have a storage group with the FOG server as the master node, and then add additional storage nodes to this storage group, as storage nodes. One way replication happens as expected master node to all storage nodes. (stick with me, I’m almost at the point). If you were to change this storage group to an unsupported configuration, where the synology nas was listed as a master node and the fog server was listed as a storage node, then the roles would be reversed. You could then capture and restore the files from the synology nas only. There would be no replication between the reversed roles of synology nas and FOG server since the replication service only runs on a real fog server. The only gotcha here is that the FOS Engine (software that runs on the target computer) connects back to the nfs share (on the fog server or synology nas) as user root. So when the nfs share is setup you will need to ensure that a user by the name of root can mount the share, this is typically done with a share level parameter of no-squash-root

@mashina Ok now for the hacky path.

You can view the menu program behind the fog ipxe menu by pointing your browser to http://<fog_server_ip>/fog/service/ipxe/boot.php in the following example I’m going to use 192.168.50.23 as the fog server’s IP address.

You will see that the text behind the fog server’s ipxe menu is akin to a computer program.

You will see the “Deploy Image” (old name is Quick Image or qi) menu where it calls the boot.php program once again but adds in the parameter qihost=1

So now if we call that url again with the new parameters http://192.168.50.23/fog/service/ipxe/boot.php?qihost=1&username=fog&password=yourpass note you will need to enter a valid user ID and Password for your fog server to get past this menu. So in this case there are 3 parameters that need to be passed (qihost, username, password).

At this next screen it will list out all of the images you have defined in fog with its image id.

Each section will look something similar to this

set imageID 1
params
param mac0 ${net0/mac}
param arch ${arch}
param imageID ${imageID}
param qihost 1
param username ${username}
param password ${password}
param sysuuid ${uuid}
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme

Now we add the imagid to the parameters list and call the boot.php program once again.

http://192.168.50.23/fog/service/ipxe/boot.php?qihost=1&username=fog&password=yourpass&menuAccess=1&imageID=1

That will produce this menu structure similar to what you are creating in your custom ipxe menu which is bootable via iPXE.

#!ipxe
set fog-ip 192.168.50.23
set fog-webroot fog
set boot-url http://${fog-ip}/${fog-webroot}
set storage-ip 192.168.50.23
kernel bzImage loglevel=7 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=275000 web=http://192.168.50.23/fog/ consoleblank=0 rootfstype=ext4 nvme_core.default_ps_max_latency_us=0 mac= ftp=192.168.50.23 storage=192.168.50.23:/images/ storageip=192.168.50.23 osid=9 irqpoll chkdsk=0 img=Dell3630Base imgType=n imgPartitionType=all imgid=1 imgFormat=5 capone=1 type=down
imgfetch init.xz
boot

So this ipxe menu then will instruct the client to boot into imaging download mode.

Now to rewrite this into fog ipxe menu params block format

set imageID 1
params
param mac0 ${net0/mac}
param arch ${arch}
param imageID ${imageID}
param qihost 1
param username fog
param password yourpass
param sysuuid ${uuid}
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme

Now you can create multiple fog ipxe menus just use a different image ID for the image you want to deploy. You can see what these image IDs are from the FOG web UI when you look at the images in list form.

@mashina Let me start with a bit of a statement and then a hacker way to go about it (1980’s hacker term not black hat term).

With FOG there is a iPXE menu… called Deploy image. This lets you start the imaging process right from the iPXE menu without having to register the computer with the FOG ui, all from the iPXE boot menu. (system rebuilders use this menu to deploy an image to a computer that will never be managed by fog, so no need to register the computer) With FOG you can have this deploy image menu display all images on the FOG server or in the case of a registered computer, only the defined image for the computer. So the options are all images or only the image that is defined for the computer. So in a way you can set it up so that the end user can redeploy the defined image or any image to the target computer.

Now working from that is possible to drive down to the actual ipxe command to deploy the image you are interested in. Understand this is all ipxe so we should be able to drive to the proper command that gives us a deployment.

@mashina I’ve seen the unknown type :: null error message when booting from the usb stick and selecting deploy without a deployment task being first created on the fog server.

I think that is akin to what you are trying to do here, deploy directly from a ipxe menu without a matching deploy task be scheduled in FOG.

@footbolvova Can we get a clear and complete shot of the kernel variables?

We need to know much more to be able to help you. The message says the target computer can’t access the nfs share on the fog server.

Is this a new install of fog or did just this one client have this issue?
Is the client on the same IP subnet as the FOG server?
On the fog server linux console, what is the output of showmount -e 127.0.0.1 ?

@geardog I think I understand what you did. Let me say this with my words. You built a FOG server but did not have the space on the small VM, so you connected via NFS to an external NAS. You mapped the /images over to the remote NFS server wanting to borrow space from that external NAS.

If that is the case, then you can’t do that with NFS. Basically you are trying to reshare a network connected drive. This is akin to taking server A and mounting a directory from server B as the W drive, then trying to share the mapped W: drive to a third computer.

The only way to make the above scenerio to work is via mouting the remote disk as an iscsi LUN on the fog server. map that external iscsi lun over the /images directory. Then install FOG. That will work because the iscsi lun is a block device, and nfs is a file level device.

@tadziuuu Just to be clear on a few points.

The .iso / memdisk route only works for bios based computers. This will not work for uefi based computers.

With the .iso image files and the parameter block I previously provided, you get the error message about initramfs? If yes, then I suspect the fetch command is not downloading the squashfs filesystem. I copied that command over from your initial parameter block. It looks like we need to focus on that bit then.