@Tom-Elliott This did resolve the issue.

@Keating178 The Invalid Storage Group error you were seeing should be fixed if you can upgrade to the latest within the dev-branch from GIT.

Hopefully this will fix the issue you were seeing too.

@george1421 said in issue with netcard of dock gen2 of lenovo l390:

@JJ-Fullmer The r8152.c from the torvalds github site failed to compile on 4.19.65, I’m suspecting its for a later release of linux. The version from the torvalds site was 1.10.10. The version in 4.19.65 was 1.9.9 of the realtek driver.

I was able to compile the realtek driver from the wget github site. This version is 2.12. Here is a link to that kernel with the 2.12 driver built in. I also enabled the usb-c code in the kernel that appears to have not been set. I don’t know if its relevant, but it should be on for other applications. https://drive.google.com/open?id=1wZwwOwbEr0nR3mnPLKg7AsulwJaGhO0A

Download this as bzImageRT (watch your case) and copy it to the ipxe directory with the other kernel images. Manually register the host and then in the host definition add in bzImageRT as the kernel for that host. Then pxe boot into FOS Linux debug mode to see if the network adapter inits correctly with this updated driver.

@John-L-Clark I realize that this is a few months old, but this problem sounds similar. Give this solution a try, download the kernel @george1421 made and set it on that host. It worked for me with the lenovo usb-c ethernet adapter, I imagine you’re using that or a similar adapter, this kernel fixed the issues we were having with the L390 and X390

Thanks everyone for the support.

@Daniel-Miller and @Sebastian-Roth I opted for the approach you suggested of making TFTPD ‘correct’ the filenames. The affected PC now goes to the FOG menu. I missed Sebastian’s map file and ended up writing my own which is:

# Workaround for PXE clients that misinterpret the DHCP options # because they expect a null-terminated string # match the extensions followed by any characters and replace it with # just the extensions r \.pxe.* \.pxe r \.ipxe.* \.ipxe r \.kpxe.* \.kpxe r \.kkpxe.* \.kkpxe

@george1421 I wouldn’t even have guessed that proxy DHCP was a thing. I’ve decided not to go for it this time but I’ll keep it in mind for future.

@george1421 said in issue with netcard of dock gen2 of lenovo l390:

@JJ-Fullmer The r8152.c from the torvalds github site failed to compile on 4.19.65, I’m suspecting its for a later release of linux. The version from the torvalds site was 1.10.10. The version in 4.19.65 was 1.9.9 of the realtek driver.

I was able to compile the realtek driver from the wget github site. This version is 2.12. Here is a link to that kernel with the 2.12 driver built in. I also enabled the usb-c code in the kernel that appears to have not been set. I don’t know if its relevant, but it should be on for other applications. https://drive.google.com/open?id=1wZwwOwbEr0nR3mnPLKg7AsulwJaGhO0A

Download this as bzImageRT (watch your case) and copy it to the ipxe directory with the other kernel images. Manually register the host and then in the host definition add in bzImageRT as the kernel for that host. Then pxe boot into FOS Linux debug mode to see if the network adapter inits correctly with this updated driver.

@Interrupt Give this solution a try, download the kernel @george1421 made and set it on that host. It worked for me with the lenovo usb-c ethernet adapter, it stands to reason it will work for the dock too.

@rwilsonadvantage You are welcome! I just marked it as solved (Topic Tools -> Mark as solved, not sure if you have access to this).

@Baessens In this special case I’d suggest you use basic Linux commands to export/import image definitions and sync the image files to your other node.

Optional: Create a sync user account on your main master node - otherwise you’d use the root account to do that but don’t use the fogproject account! Setup SSH keys to be able to login using the sync (or root) account from node B to node A Setup a cron job on your node B to do the DB and file sync Make sure rsync is installed on both nodes.

Here is just a quick outline of how you might do this (untested!):

#!/bin/bash ssh syncuser@nodeA mysqldump -u root -pPassw0rd fog images >/tmp/images.sql mysql -u root -pPassw0rd </tmp/images.sql rsync -ave ssh syncuser@nodeA:/images /images >>/var/log/fog/myimagesync.log 2>&1

This will wipe the images table on your node B and import all the definitions you have on node A.

@rankinc This partition number 5 is a recovery partition which FOG doesn’t move on the disk. So it’s unable to shrink your main Windows partition.

@crustyjeff said in HP PROBOOK 450:

No, so how can i remove the recovery partition from the clone?

Well just delete it from your master host, maybe even expand the third partition using the Windows disk management view and re-capture the image.

Probably a good idea that you leave the image Accessing2019 on your FOG server and create a new image definition for the capture you take after removing the forth partition. This way you can always go back to the original state in case you figure that you’d need it for some reason.

Deleting partitions is kind of a dangerous task. Do it on your own risk and if unsure take another backup copy of the whole system before you go ahead!

Updated /var/www/html/fog/lib/fog/task.class.php getStorageGroup method to do:

return new StorageGroup($this->get('storagenode')->get('storagegroupID'));

This way it’s not relying on a potential return from the group that may not be assigned to the tasking. It relies on the storage node that was associated to the tasking.

I will update the main codebase with this issue and fix.
Thank you,

@ziomario Thanks to Tom’s work the installer now works with Ubuntu 19.10 as well. Just finished a test install with dev-branch. Though you need to choose one of the development versions. Either go with working-1.6 (upcoming version 1.6 with new GUI) or dev-branch (latest development version of FOG 1.5.x).

sudo -i cd /home/ziomario/Scaricati/Linux/ git clone https://github.com/FOGProject/fogproject cd fogproject git checkout working-1.6 cd bin ./installfog.sh

Choose the version at the above command where it says “git checkout …”

@Tom-Elliott Thank you for figure this out. Here is the correct query.

Insert into groupMembers (gmHostID,gmGroupID) Select hostID,'212' from hosts where Right(hostName,6) in ('D02595','110563')

@ismith-hpu To clarify, this will fix for any RAW imaging types.

Fixed now in latest version of FOG: https://github.com/FOGProject/fos/commit/5600a5adf952d6cef50f60c4fde1a1551c2ba7ee

@ismith-hpu There are numerous posts on this topic in the forums!

https://forums.fogproject.org/topic/12714/option-to-delete-files-when-deleting-multiple-images-snapins
https://forums.fogproject.org/topic/13292/images-won-t-be-deleted-in-filesystem-when-using-the-webui-delete-option
https://forums.fogproject.org/topic/13472/pb-free-space-fog-1-5-5
https://forums.fogproject.org/topic/13731/image-deletion-issue-if-mass-mode-used

@sgoodman said:

I have been updating FOG on a regular basis and never changed the encrypted string to clear text and it always worked.

There was no change of that code since Feb 1, 2018.

Was an encrypted string “semi-supported” for some time after the commit? Did a recent update nullify that?

From what I understand about the code it seems to try both ways - un-encrypted and encrypted - line 40ff. This has not changed since Feb 1, 2018. Neither hast the fog-client code changed since Apr 10, 2018 (0.11.16 released together with 1.5.1). Is it possible you changed your AD logon credentials in the last weeks and somehow hit some kind of special case with character encoding that we were not aware of? Just guessing here.

I use “technicians” to help me deploy (students) and they are not normally given this credential as it could create a security concern.

We are working on this - see github issue. Tom added it to the working-1.6 branch already and I will adapt this to dev-branch today.

@rwilsonadvantage How on earth did we miss this post?!?! Sorry for that.

I am cross linking those topics here: https://forums.fogproject.org/topic/13906/ssd-fails-at-restoring-partition-tables-gpt-with-error-code-4

what if you cleared the template but not the data?

@DeRo93 said in HP Elitebook 840 G6 - UEFI PXE Boot not working.:

Elitebook

Same network segment for both PCs ?

I had an issue with UEFI with non-standard netmasking and after weeks of messing around with it learned that the I needed to have the broadcast address of 255.255.255.255 instead of the what should have worked (only on the router - router was a Cisco). Basically I use to hardwire in the correct broadcast address on the appropriate Cisco interface, I took that out (let the Cisco set up the default) and it worked… Don’t ask me why, it was “legal” from a networking perspective.

@zaboxmaster /usr/share/fog/lib/funcs.sh