Hey Tom, take your time and get yourself settled!

I am wondering if this is a good point too where we reach out to the community for people to join into the FOG team to help work on the code, fix issues, improve stuff here and there.

@Tutungzone Maybe there is a quick fix for this issue. It’s been some time since we updated the RAMDISK size and I guess this could fix it: Go to the FOG web UI -> FOG Configuration -> FOG Settings -> TFTP Server and set KERNEL RAMDISK SIZE to 275000. Save settings and try booting into a task again.

https://news.fogproject.org/fog-1-5-8-officially-released/

https://github.com/FOGProject/fogproject/releases/tag/1.5.8

https://news.fogproject.org/fog-1-5-9-officially-released/

@Tom-Elliott, @Developers, @Moderators
I got carried away trying to improve the current iPXE script. Now that I’ve dug into the syntax and found some interesting new stuff I want to see what you guys think about this:

#!ipxe
isset ${net0/mac} && dhcp net0 || goto dhcpnet1
echo Received DHCP answer on interface net0 && goto proxycheck

:dhcpnet1
isset ${net1/mac} && dhcp net1 || goto dhcperror
echo Received DHCP answer on interface net1 && goto proxycheck

: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} && isset ${next-server} && echo Duplicate option 66 (next server) from DHCP proxy and DHCP server && echo Using IP sent by DHCP proxy ${proxydhcp/next-server} && prompt --timeout 5000 || goto nextservercheck

:nextservercheck
isset ${proxydhcp/next-server} && set next-server ${proxydhcp/next-server} ||
isset ${next-server} && goto netboot || goto setserv

:setserv
echo -n Please enter tftp server: && read next-server && goto netboot || goto setserv

:netboot
chain tftp://${next-server}/default.ipxe ||
prompt --key s --timeout 10000 Chainloading failed, hit 's' for the iPXE shell; reboot in 10 seconds && shell || reboot

Feel free to comment and improve. I’ve tested the script and tried to remember all the issues I came across in the last months but I am sure we’re not there yet.

I want to thank Tom again for this! I tried to assist and help but I just don’t know the code (and its history) as much as Tom does. He’s done all the hard work to find and fix this issue. Along the way he also fixed a couple other things as well.

@Tom-Elliott Don’t say sorry. FOG is work in progress and you are pushing things way forward!! :metal:

@TrialAndError said:

Obviously the development of FOG stopped after a long time of hard work.
It would be friendly by the developers to inform the users about that.

I am not sure what exactly you mean. This is an open source project and we have no time schedule for new releases and we don’t have a set list of features to add or bugs to resolve. We simply do what we can and like.

It’s quite bizarre to state that FOG development stopped… totally wrong!

@Wirefall Great you posted the full kernel messages listing. At first I didn’t notice any issue but looking closer I found the issue:

igb: probe of 0000:01:00.0 failed with error -2

The PCI ID perfectly matches the one you mentioned in your fist post. Didn’t take long to find several reports on this issue that came in just lately:
https://lkml.org/lkml/2016/11/24/172
https://bugzilla.suse.com/show_bug.cgi?id=1009911
https://patchwork.ozlabs.org/patch/700615/

Some say that it might possibly work if you disable PXE boot for this NIC in BIOS. I don’t think this is a great solution as FOG heavily relies on PXE booting the clients. Let’s hope that this will be fixed in the latest kernel fairly soon!

We are working towards a most stable release of the 1.5.x line of FOG and will publish release candidates of FOG 1.5.9 for this over the next weeks. We ask people to participate and help test to get the final release as good as we can.

https://news.fogproject.org/fog-1-5-9-rc2-available/

@sudburr Why not re-install the whole system from scratch?

@samdoan said in Multi drive image reversing disks.:

This tells me that it’s deploying Disk1 to /dev/sda AND /dev/nvme0n1

I don’t think this is the case! It’s just the partition layout that was deployed to /dev/nvme0n1 on an earlier run and it’s still like that because for some reason it only deploys one disk right now.

Please check your image and host settings again. Is the image set to All Disks? Also make sure Host Primary Disk is not set for the host you deploy to.

@hybride said in Trying to "Push" CentOS7 image on Lenovo P620:

NBP file downloaded successfully and then nothing happen

This is way before the kernel (5.10.34) is actually playing a role. The first thing is your DHCP server and iPXE. So you might start by telling us what us serving DHCP in your network and what option 66 (next server) and 67 (pxe file name) you’ve set.

The “NBP file downloaded” sounds as if your Lenovo P620 is set to boot in UEFI mode. In this case you need to use ipxe.efi (or snponly.efi).

@artac There is one step in the installer that should clean up the external repository stuff we used in earlier versions of Ubuntu (“Adjusting repository …” in the last picture you posted). Seems like this did not work on your system as those packages were upgraded to PHP 8.0 already.

I just pushed a change to github (dev-branch 1.5.9.94) to hopefully take care of this. Can you please pull that latest change from github and run the FOG installer again?

@samdoan said in Multi drive image reversing disks.:

So I found in addition to renaming dXpY.*, you also need to edit the dX.size files as they also reference the disk number

Ahhh, good call. This part was added later because of the random enumeration when you have two NVMe drives. I didn’t have that in mind when I told you to simply rename the files. FOS is trying to use the size information to match disk size. So even if you rename the img and partition files it still tried to match to the information found in the dX.size files.

Either edit or delete those dX.size files. If you delete the files FOS will skip the size matching and just do them in alphabetical order as mentioned before - nvme0n1 before sda.

After making this change partclone successfully runs and is correctly deploying disk1 to /dev/sda. However after deploying disk1, the process completes without deploying disk2 to /de/nvme0n1. Is there something else I need to edit in order to tell the fog server that there’s another disk? How does fog server know that there are X number of disks in the image?

FOG enumerates drives/disks using the lsblk command when it boots up and should process both drives. Make sure Host Primary Disk is not set for this host.

@abuadal said in Deploying Image without Data Loss:

I tired that but it didn’t worked.

Please provide more details on why it did not work. Maybe it’s just a minor thing we can tweak to get this to work but need more information! Provide a picture of the error on screen when you deploy with a missing d1p5.img file in the images directory.

@zedx First I suggest you check if there is an update of the firmware for those devices available. Installing a firmware update can help.

You can also try different iPXE binaries for UEFI to see if it make any difference. Instead of the default ipxe.efi try snponly.efi and snp.efi.

If that doesn’t help you can try compiling iPXE from the very latest source code in hope of those fixing the issue. See my post here on how to do that: https://forums.fogproject.org/post/143521

@artac From which version of FOG did you update? As well, which version of Ubuntu did you update from?

Please run dpkg -l | grep -e php -e apache and post the full output of the command here.

@wkratky Please run the following commands and post all output here:

ls -al /var/www
grep docroot /opt/fog/.fogsettings
find /etc -type f -exec grep DocumentRoot {} /dev/null \;

@jarvizu said in Dell Optiplex 3080 - UEFI - PXE Boot E-21: Remote boot cancelled.:

Last note: This works with my old server. FOG on a CentOS VM.

Also exact same dnsmasq.conf??

Maybe there is another DHCP/PXE server in your new network setup that is causing the issue?

@george1421 said in Deploying Image without Data Loss:

I think maybe the easiest solution is to capture your source computer with single disk resizable (yes that will capture that 5th partition too), then we can go into the raw data files and remove any reference to that 5th partition. So you will initially capture it but then remove it from the FOG server so all deployments will only have 4 partitions.

While it sounds interesting I am not sure this will work in this scenario. Though it’s worth a try. The partition layout cannot be stripped as FOS will always wipe and deploy the partition layout as a whole. The only chance I see is remove d1p5.img file and try a deployment.

@abuadal
Be aware that this is not how FOG is intended to be used and there might be drawbacks from this and loss of data is possible if something goes wrong. So make sure you don’t try this with systems where important data could be lost!!