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

@marsface Well done finding the solution, the regex expression might need to be updated in the tutorial then. It could have been FOS linux changes since the tutorial was written, or a different way that the dell firmware is reporting the model. Either way well done.

@tadziuuu I haven’t had a whole lot of time to look into this but it looks like this distro is debian based.

From the iso image it looks like the important files are

/live/vmlinuz, initrd.img, filesystem.squashfs

Just looking at your param field I would say the problem is probably in here

initrd=initrd.img config boottype=usb root=/dev/ram0 rw ramdisk_size=1300000

looking at the grub config file it says this:

	  linux /live/vmlinuz initrd=/live/initrd.img boot=live config live-media=removable nopersistence noprompt timezone=Etc/UTC splash noautologin module=Tails slab_nomerge slub_debug=FZ mce=0 vsyscall=none init_on_free=1 mds=full,nosmt page_alloc.shuffle=1 randomize_kstack_offset=on FSUUID=${rootuuid} quiet
	  initrd /live/initrd.img

So I would probably make the imgargs command look like this

imgargs vmlinuz initrd=initrd.img boot=live config live-media=removable fetch=http://${fog-ip}${path}/filesystem.squashfs nopersistence noprompt timezone=Etc/UTC splash noautologin module=Tails slab_nomerge slub_debug=FZ mce=0 vsyscall=none init_on_free=1 mds=full,nosmt page_alloc.shuffle=1 randomize_kstack_offset=on quiet

Lastly I would use the ISO image instead of the usb image for pxe booting. You might have better luck.

@marsface So outside of the autopilot thing, are you having any specific issues with FOG?

@NX06 Well researching this a bit more it seems like the if/then/else command is a bit more primitive than in my example.

Lets change this:

  if  iseq ${platform} efi {
    kernel memtest64.efi
    boot || goto MENU
  }
  else {
    kernel memdisk initrd=memtest.bin iso raw
    initrd memtest.bin
    boot || goto MENU
  }

Into this

goto mem-${platform}

:mem-efi
    kernel memtest64.efi
    boot || goto MENU
    goto mem-exit

:mem-pcbios
    kernel memdisk initrd=memtest.bin iso raw
    initrd memtest.bin
    boot || goto MENU
    goto mem-exit

:mem-exit
    goto MENU

If everything works correctly it should never get to the :mem-exit location tag.

As I said I never tested it only glued it.

@marsface said in Time for a New FOG Tutorial:

I recently got a FOG environment set up, but it was a huge pain. The documentation is all over the place, and often very outdated, but we got it done.

How much exactly did you pay for the rights to install and setup FOG?

Probably not the way I would go about asking for help from a forum driving support system. There is always room for those folks who would want to update or create the perfect FOG documentation.

My question is now, is there a new tutorial or method for using FOG with autopilot that will inject drivers without having to create a new golden image for each type of device, or need to include drivers in the golden image. I have the CAB files set up in the FOG server, so why do I need to put the drivers on the C drive as well?

As the person who wrote the tutorial on drive injection using FOG that was written before autopilot. And truth be told autopilot is a windows “thing” not a FOG thing. FOG only moves data blocks from here to there. I can tell you at the time I was deploying a single golden image to 14 different hardware platforms by injecting the drivers as I had laid out in the tutorial. The issue you have is that FOG is linux based and not MS Windows based (as with SCCM/WDS/MDT) so there are only a limited things FOG can do during deployment (move data blocks from here to there). FOG can’t step in and run windows applications. Once FOG imaging is done, its up to the target OS to complete the setup.

@NX06 I have not tried this update before so this will mostly be an educated guess to get you started. Note that you should not need to hack any FOG programming to make this newer version of memtest work.

Note1: Understand the version of memtest86 that ships with FOG only works with BIOS based computers. For UEFI computers you will need a uefi compatible kernel.

The FOG iPXE menu is created by the boot.php program. If you want to view the contents of the FOG iPXE menu just key in the following url into a brower. http://<fog_server_ip>/fog/service/ipxe/boot.php Looking at the programming code you will see this section that creates the menu on the screen.

item fog.local Boot from hard disk
>> item fog.memtest Run Memtest86+
item fog.reginput Perform Full Host Registration and Inventory
item fog.reg Quick Registration and Inventory
item fog.deployimage Deploy Image
item fog.multijoin Join Multicast Session
item fog.sysinfo Client System Information (Compatibility)
choose --default fog.local --timeout 3000 target && goto ${target}
:fog.local
sanboot --no-describe --drive 0x80 || goto MENU
>> :fog.memtest
>> kernel memdisk initrd=memtest.bin iso raw
>> initrd memtest.bin
>> boot || goto MENU

I’ve highlighted the section of the code that is most important to you with the >> symbols.

You see when you select the Run Memtest86+ menu item it runs the commands

kernel memdisk initrd=memtest.bin iso raw
initrd memtest.bin

So the Kernel loaded will be memdisk which will intern load and run memtest.bin.

Note2: When you update the FOG settings General Settings->MEMTEST KERNEL its changing the iso image that will be loaded by the bios program memdisk. This is why with your configuration is failing. You are trying to chain to a uefi program (memtest64.efi) from a bios program (saying it using simple words).

So how should you fix this? Simply by creating a new FOG iPXE menu to replace the FOG supplied Run Memtest86+ Your new FOG iPXE menu will be a bit smarter than the FOG supplied menu in that (if this works) when you pxe boot a bios based computer the legacy bios memtest will be used and when you pxe boot a uefi computer the uefi memtest will be used.

iPXE is actually a programming language that creates and runs the FOG iPXE menu. Knowing this will will try to create a script that will call the bios files for a bios computer and uefi files for a uefi based computer.

  if  iseq ${platform} efi {
    kernel memtest64.efi
    boot || goto MENU
  }
  else {
    kernel memdisk initrd=memtest.bin iso raw
    initrd memtest.bin
    boot || goto MENU
  }

Note3; I have not tested this to see if this script will work. I just glued bits of code together into a logical script.

We test to see if the pxe booting platform is uefi or bios. If its uefi then we load your new memtest64 uefi file and boot it. If its bios then we call the FOG supplied commands.

ref: https://ipxe.org/cfg/platform

Now you have that script go into FOG Settings-> New iPXE menu.

Set the following fields
Menu Item: util.memtest64
Description: Run Memtest64+
Parameters:
if iseq ${platform} efi {
kernel memtest64.efi
boot || goto MENU
}
else {
kernel memdisk initrd=memtest.bin iso raw
initrd memtest.bin
boot || goto MENU
}
Menu Show with: All Hosts

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

Now pxe boot a uefi based computer and check to see if the new memtest program boots, then confirm that a bios based computer works.

@smazzola Well a question back to you is, what is your dhcp server? What is the manufacturer and model of the dhcp server. If its a linux or windows dhcp server then you are in luck. Here is a tutorial on how to create a dynamic dhcp server that will send the proper boot file based on the pxe booting computer. https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence

@GlaDio said in Boot in PXE uefi:

Server IP address is 192.168.42.233

Just confirming if this is indeed your fog server’s IP address??

If yes then would there be anything that might block the download of this file?

If this a new FOG install, where this is the first time you are trying to pxe boot “any” computer? If yes, please confirm that there are files in the /tftpboot directory? If there are no files in that directory then your installation has failed. The install has 3 steps. 1) install fog from the linux command shell. 2) When instructed go to the web ui and install/upgrade the database. 3) Return to the web ui and complete the installation. Some people miss this last step to go back to the linux console and complete the install. There are several fog specific packages that get installed at step 3.

@smazzola Specifically what do you have set in your dhcp server, dhcp option 67? For uefi based computers you need either snponly.efi or ipxe.efi. None of the bios based ipxe boot loaders will work, like undionly.kpxe. It must be a uefi boot loader.

@Krautkopf said in Batch-File from Snapin is just partially executed:

I think I’ll give it a try with your suggested solution of injecting the drivers with the post install script

In my tutorial I deliver the drivers during the post deployment scripts so the drivers are already on the the computer when it boots for the first time into windows and then after oobe completes I have the pnputil command run from the setupcomplete.cmd. The setupcomplete.cmd batch file is run as part of windows oobe and is executed as SYSTEM user.

Now in your case you have one snapin copy the files over and a second snapin install them. The fog client executes the snapins and the fog client runs as SYSTEM user. So in theory it should work.

Here are some random thoughts on the issue

One thing I do is use the start /wait "" <some_command> (so in this case the command would be start /wait "" pnputil.exe /add-driver “C:\Drivers\*.inf” /subdirs /install >>c:\drivers.bat hint: the 2 double quotes are needed to work around a quirk in the start program) to start a program and then wait for its execution before going on to the next step in the batch file. I’ve ran into situations where a batch file will spawn an application and then not wait before going to the next line in the batch file.

Its strange that you are not getting “anything” from the pnputil program. If you log into this computer and run this batch file does it work?

Is it possible that the path variable is not being used during a fog client snapin install where you need to provide the full path to the pnputil.exe program for it to be called.

Another check you might do in this batch file is verify a key or specific file exists in the drivers directory to confirm that the drivers are installed before this batch file runs, or at least log that it found the drivers.

Why not combine the driver copy and uncompressing with this script to install the pnputil command. By using the start /wait command you can ensure the execution is sequentially.

@Krautkopf said in Batch-File from Snapin is just partially executed:

pnputil.exe /add-driver “C:\Drivers*.inf” /subdirs /install

I see one issue that will cause a problem. Its your path where the drivers are located. So what you have is that pnputil will look in C:\ for any .inf files that match Drivers*.inf.

I assume you have the drivers in “c:\drivers” ? If that is the case you are missing a backslash in front of the start in your command.

i.e. pnputil.exe /add-driver “C:\Drivers\*.inf” /subdirs /install

The second part is that the log file can’t be created in the root of C drive, so I would change the path to c:\drivers\install.log or something like that. I should have posted that ppnputil couldn’t find any driver files. So its strange that the log is blank.

Just a side comment, copying over the drivers should be done as a post install script in case you need a driver to boot the system or communicate on the network. Snapins runs after windows is booted, but if the nic driver is missing the target computer will not connect to the network. This is just an opinion, if it works for you the way its configured then you have the right process that works, no need to change.