@zguo There are two things I can think of to create the initial error message.
@rdfeij said in Problem Capturing right Host Primary Disk with INTEL VROC RAID1:
Intel Corporation Volume Management Device NVMe RAID Controller Intel Corporation [8086:a77f]
FWIW the 8086:a77f is supported by the linux kernel, so if we assemble the md device it might work, but that is only a guess. It used to be if the computer was in uefi mode, plus linux, plus raid-on mode the drives couldn’t be seen at all. At least we can see the drives now.
@rdfeij Well the issue we have is that non of the developers have access to one of these new computers so its hard to solve.
Also I have a project for a customer where we were loading debian on a Dell rack mounted precision workstation. We created raid 1 with the firmware but debian 12 would not see the mirrored device only the individual disks. So this may be a limitation with the linux kernel itself. If that is the case there is nothing FOG can do. Why I say that is the image that clones the hard drives is a custom version of linux. So if linux doesn’t support these raid drives then we are kind of stuck.
I’m searching to see if I can find a laptop that has 2 internal nvme drives for testing, but no luck as of now.
@Mr_____T If you have a router that can’t be managed or doesn’t support pxe booting, then dnsmasq is the best answer.
@Mr_____T I agree with Tom. Many soho routers will put thier IP address as the {next-server} value instead of the FOG server’s IP address even if there is a spot to configure the {next-server} / dhcp option 66 value.
With wireshark you should be able to capture the DORA (discover, offer, request, ack/nak) process since its transmitted with broadcast messages. So any computer connected to the same subnet as the target computer should be able to detect this messaging. In wireshark you can set a capture filter of port 67 or port 68 or use a display filter of bootp. Once wireshark is setup and you have the filter applied you should see at least 4 packets that align with the DORA communications. Look at the OFFER packet coming from your authorized dhcp server. (hopefully there is only one offer packet, or you might have a rouge dhcp server breaking the process). In the offer packet, look at the dhcp header fields there should be two if interest {next-server} and {boot-file}, if they exists and are correct look in the dhcp options section for options 66 (boot-server) and dhcp options 67 (boot-file). Both sets of fields need to be properly filled out.
If your dhcp server is setting itself there and you can’t change the values then as Tom suggested we use dnsmasq to configure a proxy-dhcp configuration to override what the client is being told from your main dhcp server in regards to boot file and boot server.
@bsedash You are going to have two areas where you will have difficulty here.
Where the booting process is failing is where iPXE tries to get an IP address. This is where ipxe boots and then tries to get an ip address, none is received. FIrst make sure you are using nic1 on the server since this ipxe build is configured for workstation class computers and it will stop looking after the 3rd found network interface. Also since you are using fog 1.5.9 the version of delivered ipxe is quite old. Lets recompile and install the latest version of iPXE. If that gets you to the fog iPXE menu then that will solve the first problem. https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe
For the next problem, update the fos linux kernel (bzImage) but going to the webui and fog configuration -> kernel update. Update to the latest 6.x kernel to get the latest hardware support.
@El-Fogito ok lets get our hands a little dirty to debug this issue.
Schedule another image capture on this troubled server. Pick a target computer that is available for you. Before you schedule another capture tick the debug checkbox then schedule the deployment.
On the target computer you will see several screens of text that you must clear with the enter key. Eventually you will be dropped to the FOS Linux command prompt. At the command prompt try to ping the troubled fog server.
now lets try to mount the images/dev share. On the target computer issue the following commands
mkdir /ntfs
mount 10.20.10.38:/images/dev /images
If the mount is successful then issue a ls -la /images this should show the content of the /images/dev directory on the fog server.
umount /images
If everything is good then you can single step through the deployment by keying in fog at the fos linux command prompt.
@El-Fogito Hmmm everything looks good. I should have verified this question first but is 10.20.10.38 the IP address of the correct fog server?
Is the target computer on the same subnet as the fog server?
The print out of your troubled fog server told me that things are setup as they should be and you didn’t create an unknown configuration.
@alessandro19884 said in HP Z8 Fury G5 Workstation Desktop PXE boot:
Update:
I’ve also follow this instruction:
Just to verify did you follow the instructions to rebuild ipxe? I’m finding it suspicious that the autoexec.ipxe file wasn’t found. That is something that should be compiled into ipxe. (fwiw: pictures speak better than words because we can see that its failing in ipxe (at least this time) ). The FOG delivered ipxe files has its own script built in and doesn’t use autoexec.ipxe (akin to DOS’ autoexec.bat file from 30 years ago).
@bmick10 Just to be clear recompiling and installing the updated version of iPXE address your init.xz stop issue?
@alessandro19884 This issue is tricky in that it could be iPXE or FOS linux that is failing. I don’t think this has anything to do with your disk subsystem on the target computer. Its not to that point yet in the booting process.
Lets first rebuild iPXE to the latest version because it could be the hand off from iPXE to FOS linux. Use these instructions to recompile iPXE on your fog server. https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe
The second part is lets update the FOS Linux kernel to the latest. In the Web UI under FOG Configuration -> Kernel update. Update to the latest version of version 6 of linux kernel.
I would do one of the above at a time so we can identify what was actually at fault.
@El-Fogito will you post the output of the following commands executed on the fog server. You may need to execute the sudo su - command to allow you to run all of these commands.
df -h
ls -la /images
showmount -e 127.0.0.1
cat /etc/exports
Where it is failing is the fos linux engine (OS running on the target computer), it connects to the FOG server using NFS as ‘root’. For some reason this connection is being blocked. Lets see the configuration so we can know what to test next.
@bmick10 a quick google-fu search of the error shows your ubuntu install is missing a needed library to completely compile the updated version if iPXE.
sudo apt-get install -y liblzma-dev
@bmick10 said in Fog stops at init.xz...18% and other percentages:
So it will load to Fog stops at init.xz…and different % each time.
This sounds like an iPXE issue, where its not loading FOS Linux’s virtual hard drive completely for some reason. Lets start out by having you rebuild/compile the latest version if iPXE using these instructions: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe Lets see if there is an update to iPXE that solves this issue.
@maximefog said in Deploy Image:
it is mandatory to register the workstation
This is not a requirement under certain conditions. There is a method I call “load and go”. It is a process that system builders use where once they load the OS on the target computer they never see the computer again. In this method you can not use the FOG Client for any of its function. The install process must be self contained or use a FOG post install script to make the install time adjustments to the target computer. Using this method you do not need to register the computer with FOG. Once the image is deployed to the target computer FOG forgets it ever saw this target computer. Once you have the master image setup as needed you deploy the image from the FOG iPXE menu “Deploy Image” menu. You never have to touch the FOG web ui for image deployment.
@jenesis I’m going to say that since this is a hardware security device its not possible to pxe boot it. I can see the device manufacturer using the hardware security key as part of its integrity control to ensure its OS hasn’t been tampered with.
But I would not rely on my guess alone. I would contact the company’s support team and ask if the software can be pxe booted. If yes, then we can probably get it to boot via iPXE. You also want to ensure you are not in violation of the manufacturers EULA by pxe booting something you shouldn’t.
@jenesis The quick answer is maybe you can, but also maybe no.
There are some iso images you can convert to ipxe boot. Lets first start by getting the name of the software you want to pxe boot. What is the name of the software?
@pilipp_edv said in general questions about storage / master storage nodes:
After that, I configured the windows DHCP servers in the other locations to point to the main FOG server.
FWIW: You can (should) point the remote dhcp server to the remote storage node so the clients doesn’t need to transfer the ipxe boot image across your wan. The storage node will instruct the clients to “check in” with the fog master node.
The part you are missing is the FOG server plugin “Location”. With the location plugin you first identify your different locations. Then assign storage nodes to the “location” then assign existing client computers to the location. As you full register new clients there will be an added prompt for location during registration. This plugin pulls all of the bits together to make the clients find the proper storage node.
@Bhav Just for clarity, do you have an isolated imaging network or are you trying to image on your business network?
If you have an isolated imaging network then you should have configured FOG to setup a dhcp server. The configuration will work for both bios and uefi computers.
If you plan to image on an existing business network, then your primary dhcp server needs to be configured to support pxe booting.
So lets start with how do you plan on imaging?
Second if you are planning on imaging using your business network, what device is your current dhcp server?