@george1421 I’ve tested partclone over NFS to m.2 under Ubuntu 18.04 now.

The exact same issue is happening there with partclone.

I ran partclone.restore to /dev/null, from the FOG NFS images share to get a non-writing baseline of network performance, and it showed 6.8GB/min.

Then I ran partclone.restore to the m.2 drive, and it started at 14GB/min, and by 4% it was down to 2GB/min. By 50% it was down to 450MB/min.

The /var/log/partclone.log showed multiple writes per buffer, like I outlined in another post.

I guess it’s time for me to post in the partclone forums?

@Tom-Elliott That was the ticket!

The snapins from a pre-1.x version of FOG imported many moons ago to have the full path in the snapins table, and had 0 in the sgaStorageGroupID field for the storage group in the snapinGroupAssoc table.

I removed the full path in the snapins table and set the sgaStorageGroupID to 1, and now I can get to the snapins list page and the host page.

Thanks for the pointer!

@Tom-Elliott That was the ticket!

The snapins from a pre-1.x version of FOG imported many moons ago to have the full path in the snapins table, and had 0 in the sgaStorageGroupID field for the storage group in the snapinGroupAssoc table.

I removed the full path in the snapins table and set the sgaStorageGroupID to 1, and now I can get to the snapins list page and the host page.

Thanks for the pointer!

@Tom-Elliott According to the Storage page, the DefaultMember has the correct path for Images and Snapins:

I can’t get to the Snapins list page, probably for similar reasons. According to the snapins table, some of my older snapins have the full path, and the newer ones don’t. Is there another table or set of fields where I can verify the correct storage group is associated with the snapins?

@Tom-Elliott I was able to post it just now, so whatever you did seems to have worked!

Thanks!

I’ve been nursing a pretty old FOG install on CentOS for a few years and decided to spin up a new server running Ubuntu and transfer everything instead of trying to update in place.

I successfully got the images and database transferred, and the installer runs without error, but then when I get into the new system, clicking on any host or a Deploy button results in a partially rendered page.

There is an underlying PHP error when this occurs:

[Thu Aug 29 19:43:25.376709 2024] [proxy_fcgi:error] [pid 65111] [client 192.168.10.85:53400] AH01071: Got error 'PHP message: PHP Fatal error:  Uncaught ValueError: min(): Argument #1 ($value) must contain at least one element in /var/www/html/fog/lib/fog/snapin.class.php:392\nStack trace:\n#0 /var/www/html/fog/lib/fog/snapin.class.php(392): min()\n#1 /var/www/html/fog/lib/fog/snapin.class.php(344): Snapin->getPrimaryGroup()\n#2 /var/www/html/fog/lib/router/route.class.php(1327): Snapin->getStorageGroup()\n#3 /var/www/html/fog/lib/router/route.class.php(487): Route::getter()\n#4 /var/www/html/fog/lib/pages/hostmanagementpage.class.php(1806): Route::listem()\n#5 /var/www/html/fog/lib/pages/hostmanagementpage.class.php(3264): HostManagementPage->hostSnapins()\n#6 /var/www/html/fog/lib/fog/fogpagemanager.class.php(220): HostManagementPage->edit()\n#7 /var/www/html/fog/management/index.php(58): FOGPageManager->render()\n#8 {main}\n  thrown in /var/www/html/fog/lib/fog/snapin.class.php on line 392', referer: http://fog.molecularmedia.com/fog/management/index.php?node=host&sub=search

The new system is running Ubuntu 24.04 which comes with PHP 8.3. Are there known problems with this version of PHP with FOG Project, or is there something else wrong with my install?

This error is happening with both the stable branch and the dev branch.

Here’s what the partially rendered host page looks like:

I can’t post a Linux technical question to this forum because Akismet keeps flagging it as spam.

I don’t know if this post will go through until I click the button.

@admin - any insight?

@george1421 I might just try that, just for troubleshooting purposes.

Re: firmware - There is a BIOS update for the machines, and a firmware update for the NVM Samsung drive. Sadly, trying these was my first troubleshooting step (not listed here, because it was before I suspected components of FOG). I sure was holding my breath that it was the drive firmware though!

We bought 50 of these machines and one arrived with a cracked screen. I just received the replacement from the RMA of that broken machine, and of course it images at full speed.

The replacement machine came with a Samsung m.2 drive, part: MZVLW256HEHP-000L7

The other 49 machines have the Lenovo equivalent: LENSE20256GMSP34MEAT2TA

I’ve contacted my Lenovo rep with the hopes that I can work with an engineer to narrow down a fix.

@tom-elliott I’m pretty stumped myself.

And why does it matter on the FOS Client that it is not NTFS? Fuse NTFS version differences between FOS and Ubuntu?

So apparently on the Ubuntu machine, as long as the partition is mounted, a restore is fast.

On the FOS Client, the partition has to be formatted as a FS other than NTFS and mounted.

I’m too far down the rabbit hole to see how this makes any sense.

@sebastian-roth Thank you, Sebastian.

This is getting weirder by the day.

I went back to the Ubuntu test machine today to try and look for differences, and partclone.restore from NFS to the m.2 SSD ran at expected speeds!

Going back through my shell history, I noticed I had never unmounted the partition I was cloning onto.

So, after the restore completed, I unmounted the partition and ran the partclone.restore again. Boom, slow.

Then remounted, re-ran command, boom, fast again.

I did this a few more times to make sure I wasn’t seeing things, but sure enough, on the Ubuntu machine, when the target partition is mounted, partclone.restore writes at GbE speeds. When the target partition is not mounted, the restore speed falls to about 450MB/min.

I tried this on the FOG Client machine, but partclone exits because it knows the partition is mounted.

Thinking this might be due to the partclone version 0.2.89 on FOS, I copied over the 0.3.11 binaries and libraries.

This allowed it to run the clone despite the partition being mounted, but it was still slow.

I looked back at the history on the Ubuntu machine, and the FS I had mounted the first time I had a fast restore was ext4. Subsequent times it was NTFS (from the image).

So, I did an mkfs.ext4 on the partition on the FOS machine, mounted it, and ran the partclone. IT RAN AT GbE SPEEDS!!!

However, subsequent unmount/remount did not allow another restore to run quickly. I’m just about to test formatting as ext2 and trying the restore with that mounted to see if it matters which FS.