@sebastian-roth said in Lenovo E15 Gen2 won't PXE boot (bzImage):
booting into FOS Linux
You must have caught my post just after I posted it. After I hit the submit button I realized that the target computer didn’t ipxe boot directly so I changed my story. I think still getting the PCAP is what we need to see if its actually sending out the dhcp discovery bits.
@adrian-a since you are using a qnap device you might consider converting it into a FOG Storage node. You will give up some flexability but in a way you will make the qnap device the storage location for FOG. Here is an overview. https://forums.fogproject.org/topic/10973/add-a-nas-qnap-ts-231-as-a-storage-node-fog-v1-4
Just one limitation, if you use a qnap device as a storage node AND have all of your data on the qnap device, FOG will not replicate these image files to other storage nodes. Only a full FOG server can become a master node in the storage group.
@imagingmaster21 IMO you have multiple things wrong here, all of them giving you a different error.
I would nuke the fogproject git repo directory and reclone it from github then rerun the fog installer.
Beyond that you need to confirm the FOG server ip address has not changed since fog was installed. You can do this by viewing the hidden config file /opt/fog/.fogsettings if that file contains a different IP address than is currently set you need to fix that too.
Once you have all of that fixed then you need to ensure you have the 5.6.18 FOS Linux kernel installed.
If you still have issues, open a new thread for each issue so we can keep the problems isolated.
@humoss233 First let me say well done!
I have just a few comments, the /r/n issue can be addressed if you want to develop your code on windows, use notepad++ its a much better cross platform text editor. Also if you develop code on windows with an application such as notepad, you can use a linux utility called dos2unix to strip out these extra characters with a single command line utility.
Your coding looks really good. You are doing several fairly advanced techniques. I’m going to post the diffs for both the kernel and the ints so that these changes don’t get lost with time. I may need to rebuild the kernel for another one off issue and your changes will be lost of I don’t get this added into this thread. I’ll do that early next week. That will also give you or someone else the ability to recreate what has been done.
@dungody said in HP ProBook 640 G8 imaging extremely slowly:
i m using FOG 1.5.7
If you don’t want to upgrade to the latest version of FOG we might have you try at least the FOG 1.5.9 init.xz file to see if the updated version of partclone works better with that hardware. I’m still at a loss why using a USB drive would settle down the system, unless they have some kind of strange power saving mode where it would enter a low power state when it thinks there is no user input.
Does other USB devices (external mouse) have this type if impact or is it only usb storage devices that “cure” this issue?
@Kevin-Talbot This thread is almost 1 month old. I take it, its still an issue?
Can you take a clear screen shot of the error so we can see the context of the error? It sounds like the linux user fog’s account password was changed/is out of sync with the webui. I have a tutorial on how to get everything back in alignment here: https://forums.fogproject.org/topic/11203/resyncing-fog-s-service-account-password
The fog service account should exist on the fog master node the storage node should have their own service account too.
@jcrod73 Ok the problem is you are trying to cut the branch you are standing on. You need the fog client to install the snapin to remove the fog client.
So how can you do this (on a high level).
I don’t use the fog client in my environment so I can’t confirm this for you. but look in the registry for the fog client uninstall string. It should be in this area: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer once you have the uninstall string you can then craft msiexec /x <guid> /q to uninstall the FOG client. Or if you have the fog client msi, drop the msi behind on the target computer and then reference that file with the /x command. There are a couple of ways to uninstall it, you just can’t use the fog client itself to uninstall it.
The other option is to no use the fog client (and services it provides) but use a third party tool like pdq deploy to install your packages. This gives a zero footprint on the target computer.
@boombasstic The error would imply you entered debug mode from the advanced options. What Sebastian meant was for you to deploy the image as normally, but before you hit the schedule task button, tick the debug checkbox then submit the task. That will put the target computer in debug deploy mode to allow you to read errors or stop the imaging process with a ctrl-c.
@claw22000 said in Deploy install ISO over PXE with FogProject:
outdated and doesn’t work with new versions of everything
I know I shouldn’t be offended by this comment but I am a bit. The thread I referenced below covers 15 some different OS that you can pxe boot one way or another. They might not be the bleeding edge operating systems, but you should be able to use them as a base for your testing. You are right iPXE is not syslinux, but you can translate between them pretty well.
There are some OS’ that you can’t pxe boot directly, like windows. But if you use a winpe image (which you can pxe boot) you can boot into the windows installer.
As for ISO images you can only really boot them well in bios mode with memdisk which transfers the entire iso file to the target computer and boots it. That’s great if your iso file is < 2GB, but if its larger you can not use memdisk. Also if you have a uefi system (which most are now) memdisk will not work in a uefi system.
For most distros there is an option to netboot them, where you take the iso image and explode it to disk (on the fog server) then mount that location on the pxe booting computer to install from there.
Lets start out with what are you trying to deploy from the FOG server? I might already have a step by step guide.
@robertkwild I have never tried with OEM media. I know that I’ve heard reports of the setupcomplete.cmd file not running unless you use volume license media. As for processing the unattend.xml during OOBE, I guess one would have to try to be sure. I’ve had no need to test this idea. For a business that has 20 or more systems it doesn’t make much sense to not use VLK media. If you are deploying windows 10 pro and you have all windows 10 oem activated computers, you only need one windows 10 pro vlk license. You do have to get to 5 points so just pick up some server CAL licenses to get to 5 points. You can always use extra CAL licenses.
For the legal disclaimer part, MS OEM Eula doesn’t allow for creating a golden image with OEM media and then deploying a custom image. You need the VLK media for that. But in this case we are just talking about theoretical deployments.
@tutungzone There was a change in the partclone version between 1.5.5 and 1.5.9. Really all fog servers and storage nodes need to be at a similar release version for the best workings. The fog developers realize that this is not always possible. There isn’t a backwards compatibility between images captured on 1.5.9 and being deployed on 1.5.5.
BUT what you can test is to look in /var/www/html/fog/service/ipxe directory on the 1.5.9 FOG server for a file called init.xz This is the virtual hard drive for the linux os that gets loaded on the target computer to do the imaging. You can test to see if it works with 1.5.5 (I personally never tested it) by saving the 1.5.5 version of init.xz and copying over the 1.5.9 version of init.xz to the 1.5.5 server. There is a good chance the virtual hard drive will run just fine under 1.5.5. The updated version of partclone is part of this newer init. If it doesn’t work, then you need to upgrade all of your storage nodes. But this simple file copy should do the trick.
@robertkwild said in is it ok to make new dir in /images:
OK to create /images/backup
Yes it is OK. FOG don’t care or will ever see it.
@d2freak82 does it continue to image or does it stop. Some of those acpi error are warnings not show stoppers.
What hardware are you pxe booting on that throws these errors?
What ersion of FOG are you using?
What version of the FOS Linux kernel (web ui->FOG Configuration->Kernel update?
@fogman4 This looks suspicious.
choose --default os.Debian.10.9 Live via ftp --timeout 3000 target && goto ${target}
The tag name should not have spaces. Looking at the actual menu item
param sysuuid ${uuid}
:os.Debian.10.9_Live_via_ftp
kernel tftp://${fog-ip}/os/debian/vmlinuz
initrd tftp://${fog-ip}/os/debian/initrd
imgargs vmlinuz initrd=initrd boot=live components fetch=ftp://${fog-ip}/filesystem.squashfs
I wonder if the underscores are breaking the default option.
:os.Debian.10.9_Live_via_ftp
They are translating to white space characters. Use dashes or dots in the tag name and see if that fixes it.
@b_man There is an option to power off the machine after every execution of FOS Linux (registration, capture, deploy) but its global and not specific to just registration.
But from my standpoint you have your workflow off a bit. If you are making a golden image computer, you should register that computer with FOG BEFORE you build your golden image. That way everything is setup in FOG. Then you sysprep the machine and have sysprep power off the computer. Schedule a capture in fog then pxe boot the target computer and capture the image.
@sebastian-roth said in UEFI can't PXE boot:
but one final piece was still missing
The final bit was / for when the OP of that thread used the bios_and_uefi coexistence process he forgot to activate the policy. I don’t have a windows dhcp server in front of me, but there is a definite option to enable the policy or the scope. Once that was done then the dhcp server was dynamic in the boot file name according to the policy/rules.
@jarvizu OK then lets see what is flying down the wire here. Use the FOG server to capture the pxe booting process. I have a tutorial here: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue
Upload the pcap to a file share site and post the link here. We’ll take a look at the pcap to see what is going wrong.
Side note: If your network doesn’t have a dhcp server I would personally use isc-dhcp server on your fog server over dnsmasq. I would use dnsmasq if you have a dhcp server run by someone else and can’t update settings. In this case dnsmasq would supplement your unchangeable dhcp server.
@tallier You can do that by using a FOG Post install script. This is a bash shell script that runs after FOG pushes the image to the target computer and before FOG reboots the computer at the end. I have instructions on setting this process up here: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed
I know the instructions are a little old but they still work well with current windows 10.
@rabdel OK the intel nic [8086:0D4C] driver has been in the linux kernel since linux version 5.5. The aquantia nic [1D6A:D108] driver has been the linux kernel since 4.11.
So the signs are good in that it should be working. With that said something is missing. So now we debug.
I want you to connect one network interface cable to the intel nic. Have a second network interface cable ready because we will need it during debugging. Get the mac address of the intel nic and manually register (via the web ui create a host definition) this computer with FOG.
Now create a debug deployment/capture it doesn’t matter. Before you select the schedule task button, tick the debug checkbox. Schedule the task then pxe boot the target computer.
The target computer should boot right into debug imaging. After a few screens of text you will be dropped to the FOS Linux command prompt. At that command prompt I want you to key in a few commands.
As soon as you are at the command prompt key in ip a s and see if your intel nic has an ip address.
If yes, then see if you can ping the fog server from the FOS Linux command prompt.
If no, wait 30 seconds then key in this command. /sbin/udhcpc -i enp3s0 --now I think the intel nic’s kernel name is enp3s0 but you can confirm with the ip a s command. You will see both the intel and aquantia nics so you will need to identify which is which by mac address. After the udhcp command completes then type in the ip a s command again to see if the intel nic gets an ip address.
If still no, then try with the aquantia nic interface the same process. My guess is the intel nic will work after 30 seconds. But lets test.
If still no luck then we need to look at the syslog. I am guessing at the file name here, so you may need to confirm by looking in /var/log key in grep firmware /var/log/messages See if we have any errors related to missing nic firmware.
@mesaman0182 Well… You can saturate a 1GbE link imaging 3 contemporary computers at at time. On top of that you are running a type 2 hypervisor which also impacts the performance and throughput.
For a single image what is your transfer rate according to Partclone?
On a well managed 1GbE network you should be able to transfer about 6.1GB/min for a single unicast.