@Eazis Will you do a few things to help us try to sort this out?

Schedule a capture or deploy to this computer, but before you do tick the debug checkbox before scheduling the task. If you don’t have this computer registered with the FOG server manually register it.

Now pxe boot the target computer, it should start to image right away, but instead of imaging it will drop you to a linux console on the target computer. There will be several screens of text you will need to clear with the enter key, but at the end you will be dropped to a linux command prompt.

How I want you to key in the following.

ip a s
lspci -k -nn | grep -i net
grep -i -e firm /var/log/syslog

get a clear picture of all of the values and post it here.

The first command will show us the network adapters
The second command will show us the hardware ID of the network adapters
The last command searches /var/syslog for any message that has firmware in the name.

After you are done with this, delete the capture/deploy task from the fog server.

@Clebboii said in FOG Very Slow to Deploy Image - Lenovo Neo 50Q Gen 4:

(Google Drive open link or GIT et

https://drive.google.com/file/d/1LCmvgmUa8YvbG1fE95Yn_lDBhFXLs8At/view?usp=sharing

@george1421

I’ve reinstalled FOG, using the in-built DHCP server instead of the router.
Worked perfectly first time, after setting the router as a relay instead.

Thank you very much for all your help! 🙂

Greetings.
Same issues here with a LENOVO 50S, realteck chipset.
I’va speed of 9 Gbit/min on capture and 0.6 Gbits/min on deploy.
Debian Fog Server, version 1.5.10.1660, latest and beta kernel : same issue.
Do a bunch of test with an another hard disk, new kernel, same issue.

I tested with 5.15.68 kernel and my download speed go from 0.6 Gib/min to 4.5 Gbib/min !

@Jias94 Hey no worries, I’ve created that error a few times myself so I had a good idea where to look. I’m glad you have it sorted out and can get back to imaging.

@Clebboii Thank you for your comments. I’m following up on your responses below.

It looks like MAC Passthrough is only a thing on Latitude, Precision, and XPS laptops. We utilize Latitudes. We do disable Secure Boot when trying to go into PXE boot. We’re going to try to set up a USB with WinPE to disable bitlocker. What confuses me is that the XPS had bitlocker get triggered when secure boot was off but still made it through PXE. It makes me think Bitlocker isn’t the issue here. The Dell USB-C to Ethernet does not support our Dell Inspirons. We tried an Anker USB-C hub with Ethernet and a usb-Ethernet TP-Link adapter on the Inspirons which didn’t give us the option to PXE boot. 66 and 67 weren’t set up when it worked on the ThinkPads or XPS. We set it up on our Firewall not our Router. It also worked after enabling. Going to look into this once our ThinkPad returns from being issued out as a loaner laptop.

Updating FOG has resolved my issues. Thank you.

@jfernandz https://stackoverflow.com/questions/4713088/how-do-i-use-git-bisect

This is just very basic overview and probably unhelpful.

If you’re familiar with git, you can switch to different points in time (via the dev-branch) to figure out when we last knew things were good. So first, I’d suggest trying to find exactly when that would’ve been.

I’d likely start, using dev-branch as the primary “tester case”

git checkout -b dev-branch

If you haven’t already done so of course.

Then I’d put the branch at the same level as when we pushed out 1.5.10:

git checkout 081d1f4

Run your install and see if things worked, if they do:

git checkout dev-branch git bisect start git bisect bad git bisect good 081d1f4

Of course the 081d1f4 is the hash of the commit where things were good: this might or might not be the 1.5.10 release, so your mileage may very and may need some more adjustment.

You can find these hashes on https://github.com/FOGProject/fogproject/commits/dev-branch/?after=f7fd3a7a3f188b4540f089a7f38c4d368b53376c+174 using the different pages at the bottom to find a point in time, and they show the hashes on the right and side of each commit.

It will iterate through things and you just mark after each install/test what worked (as good or bad) by testing:

If it still fails, you’d run git bisect bad, if it succeeds, you would run git bisect good each iteration.

It’s tedious I know. but it will help us find the exact point things broke and hopefully from what (maybe it’s something we did, maybe something within ipxe, but gives us a starting point to test things out.)

Thanks

@Tom-Elliott
Thanks Tom

However I ran this about 15 times. Post install I was never given an option to update the database or schema.

My initial issue before upgrading was that I was trying to deploy image to Lenovo M625Q tiny with 256gb SSD drive as the PRIMARY drive and the standard Seagate 500gb (SATA0) as the SECONDARY drive. I added the /dev/nvme0n1 as the primary disk, yet FoG wrote to the Seagate drive first every time.

I asked ChatGPT for ideas, and it found a known issue with FoG writing to EUFI SSD drive as Primary drive and stated that I needed to update to the latest iPXE file. Everything been broken ever since. I have spent more than a week trying to get FoG working once again.

I’m updating my Ubuntu server to v20.04 now and I will try the re-install one more time, unless you have any other ideas?

-Jim

For the benefit of others, I had hoped that upgrading CentOS from 7.5.1804 to 7.9.2009 would add the network drivers for a MiniX PC with a RealTek network card but this was not to be.

We have thefore taken the hopefully working step of installing 1.5.10 from scratch on a new Ubuntu 24.04 LTS Hyper-V build.

It is hoped that this will work for us.

@hariskar It looks like your root partition ‘/’ has 1.8T or 1800GB of space. The command I would have run is df -h to give you usage. but assuming that debian is less that 50GB you should have plenty of space to capture a modern computer with 50GB of data. Use single disk resizable to use zstd to compress that 50GB of data down even smaller.

What error message are you getting? A screen shot of the error might help set the context of the error.

@wamis let start by updating your fos linux kernel to something more modern. I think 6.8.86 may be the latest. FOG Settings->Kernel->update kernel. FOG 1.5.7 is old. Lets see if we can update the kernel without needing to update fog.

@brentomp Kernel issues, see
https://forums.fogproject.org/topic/17698/fog-very-slow-to-deploy-image-lenovo-neo-50q-gen-4/14

@pierre-baylet Bonjour, j’ai eu la meme erreur lors de la mise à jour en 1.5.10. J’ai aussi un storage node déporté sur un NAS Synology. J’avais une erreur après la capture, avec un “Update database failed”.
Il faut que tu refasses les permissions sur ton dossier images/dev sur ton FTP.

Pour mon syno j’ai fait la manip suivante :
depuis mon fog en ssh :
sudo mount -t nfs @IPNAS:/volume1/images /mnt
chown -R root:users /mnt/dev
chmod g+s /mnt/dev