Topics created by Greg Plamondon

@george1421 ok so lets wrap this thread up nice and neat.

On the HP EliteDesk 705 G5 computers, they for what ever reason, do not like the unidonly.kpxe iPXE boot loader. iPXE undionly.kpxe will issue a dhcp request and the dhcp servers will send an OFFER packet but iPXE rejects the offer and just sends a DISCOVER packet again. And it continues over and over with the DISCOVER and receiving an OFFER but rejecting the given OFFER.

We did find that ipxe.kpxe did work correctly on these HP systems. So this kind of tells me the UNDI firmware driver in the network adapter is faulty. I’m suspecting a future firmware update will address the issue. In the mean time we had to work out a solution to send ipxe.kpxe to these computers only and send undionly.kpxe to all other bios based systems. Luckily the OP had linux dhcp servers on this subnet so we set out to see if we can identify these systems based on their UUID. Through testing unfortunately the UUID on these HP systems are globally unique instead of encoding the model and unique ID in the UUID field like Dell does. So the OP settled on identifying the systems based on mac prefix. This is the following setting we added to the isc-dhcp server on his network.

class “Legacy-hpbroken” { match if (substring(option vendor-class-identifier, 0, 20) = “PXEClient:Arch:00000”) and (substring(hardware, 1, 3) = 00:01:02;); filename “ipxe.kkpxe”; }

@Greg-Plamondon Well that bit of code is held over from the WinXP days and worked in Win7. It no longer works in Win10.

I’ve left that in the code because it shows you how you can poke things into the windows registry from linux (which should not normally be possible).

If you are working on drivers and importing them look at this tutorial. The short read is that you need to use the pnputil.exe command in your setupcomplete.cmd file to load the hardware specific drivers during winsetup. https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed?_=1596483356960

@george1421 said in Wrong Partition is mounted during deployment. (FOG 1.5.7.56):

@Greg-Plamondon You might want to update your partition detection script to the one used here:

#!/bin/bash . /usr/share/fog/lib/funcs.sh [[ -z $postdownpath ]] && postdownpath="/images/postdownloadscripts/" case $osid in 5|6|7|9) clear [[ ! -d /ntfs ]] && mkdir -p /ntfs getHardDisk if [[ -z $hd ]]; then handleError "Could not find hdd to use" fi getPartitions $hd for part in $parts; do umount /ntfs >/dev/null 2>&1 fsTypeSetting "$part" case $fstype in ntfs) dots "Testing partition $part" ntfs-3g -o force,rw $part /ntfs ntfsstatus="$?" if [[ ! $ntfsstatus -eq 0 ]]; then echo "Skipped" continue fi if [[ ! -d /ntfs/windows && ! -d /ntfs/Windows && ! -d /ntfs/WINDOWS ]]; then echo "Not found" umount /ntfs >/dev/null 2>&1 continue fi echo "Success" break ;; *) echo " * Partition $part not NTFS filesystem" ;; esac done if [[ ! $ntfsstatus -eq 0 ]]; then echo "Failed" debugPause handleError "Failed to mount $part ($0)\n Args: $*" fi echo "Done" debugPause . ${postdownpath}fog.copydrivers # . ${postdownpath}fog.updateunattend umount /ntfs ;; *) echo "Non-Windows Deployment" debugPause return ;; esac

This one uses a bit more intelligence to find which partition actually has windows on it. I think your script is just picking the last partition and calling it good enough.

ref: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed

Thanks, That fixed it!

@Greg-Plamondon Ok, fog-client log looks fine. What about the other things I mentioned?

@Greg-Plamondon Is this still an issue or did you find what was causing this?

@ddo Do you have some GPOs or other means of software deployment in place that would install 0.11.16 after 0.11.17 was installed?? I have done some intense testing on this back in the days when this came up and I am fairly sure it’s not FOG doing this by itself. But it is possible due to missing checks in the MSI installer if you use other means of deployment alongside.

Solution: Uninstall both, re-install one, maybe even use the latest release 0.11.19.

Found and should be fixed if you do the latest pull.

Thank you,

Of note, I’m calling it 1.6 because when we do release it, that’s what this will become.

It is using the current latest version (1.5.7) and the .XXX after is the number of commits ahead of the master branch the working-1.6 branch is at.

Also done in 1.5.x dev-branch…

I noticed that the fog version after the upgrade was not showing:

alt text

After I manually changed the fogstorage password in MySQL the versions started populating for the storage nodes that were upgraded but not for the storage nodes that were not upgraded.
is it possible that the upgrade corrupted the fogstorage MySQL password in the database on upgade or was it the mysql dump that was generated by Configuration Save> Export Database in the fog gui?

The more I think about it it would have to be the MySQL dump… I installed fog on a new Centos 8 build and imported the database after installing fog.

snapins are now downloading with the correct file sizes.

Thank you everyone for helping me with this issue!

I’m not fully sure how to implement proper login checking. This is a feature that is kind of in flux. When initially coding the ipxe stuff, there was a lot of ties in to protect things that were “natural” to the main menu. However, this made making password protected items less possible because there isn’t a nice easy api in ipxe to call back and check “login” against a url.

The current password protected items have 2 different elements. The first is to pass the login stuff to the second element, and that second element cross checks login capability and passes through if all passes properly. It’s because of this double step that currently custom pxe items can’t just have a password protection nicely integrated. It would need a secondary element tied in to the main boot code. This could be done with hooks I’m sure, but it’s still fairly complicated. The simplest methods would be to do as you did (use ESC to force all menu items to be login protected) or use the advanced menu with login enabled.

@george1421 Thanks!

@Sebastian-Roth Thanks for the input,
I was able to figure out what was going wrong. when I was ssh-copy-d root@storagenode it was copying the sshkey i use to login to the server. I needed to use ssh-copy-id -i /root/.ssh/id_rsa and then your suggestio of rsync ... -avze "ssh -i /full/path/to/ssh_private_key" /images/Sync root@$i:/images/ ... worked great.

Thanks!

what if you cleared the template but not the data?

@Sebastian-Roth Thank you for finding and fixing the issue.
@Greg-Plamondon Thanks for reporting. This fix is also set for 1.6 now too.

Awesome job everybody!

Thank you,

@Sebastian-Roth said in Fog 1.5.5 - Snapin replication loop:

dev-branch

Thanks!

@Tom-Elliott Thanks!

For now, I have created a fog AD user that has rights to join the domain. the only issue with that is the helpdesk tech needs to have one of the domain admins remove the PC from AD if it’s preexisting.

@Greg-Plamondon My fault, sorry for this. I just pushed a fix to the dev-branch. Please pull the latest changes any try again.

Thanks that worked!

@greg-plamondon said in Windows Boot manager set as default after imaging:

Windows Boot Manager after successfully imaging a PC.

My bet is after FOG pushes the image and the workstation reboots, LAN will still be set until Windows OOBE runs, then windows set the boot order to WBM. I’ve seen this happen on my VM I use for MDT reference image build.

If you were using Dells, Dell has a CCTK tool you can use to reset the boot order.

A little google-fu shows that this is a particularly annoying issue when you have a dual boot computer. One solution that was posted was to set a firmware password once the boot order is set. From the one post I saw, if there is a firmware password, windows can’t mess with firmware settings.