Posts made by jflippen

@Sebastian-Roth That’s fine. Things have been pretty swamped over here so I had to put the issue on the back burner. The issue doesn’t always show up, so troubleshooting has been time consuming.

@george1421 Here is what shows up as mounted on the storage node:

Firewalld stopped and disabled.
sestatus is in permissive mode.

@george1421 I had a meeting this afternoon and will be off the next few days, so I won’t be able to test this until Monday. I will post results when I get in.

@george1421 Okay. I was issuing the debug task from the web GUI instead of deploying an image with debugging.
So, when I try mounting the volume before running the fog command, I get denied:

However when I then run the FOG command the imaging goes without a hitch:

After the imaging completes the share is mapped no problem.

@george1421 Here is a pic of the first command… the 2nd command brought back an empty result on the surface:

The storage node IP is 10.59.181.12.

@george1421 They are just load sharing. The devices being imaged are on a different subnet than the storage nodes and fog server. Network team said there should be no blocking between sites on the firewall or the switch configs.

@Sebastian-Roth Here’s what I get when trying to debug on my surface when I try to run the fog command on the debug. It doesn’t even make it past the first step.

@Sebastian-Roth maybe… I know our network team has been tightening up security. Our main FOG server and our storage nodes are all set up with link aggregation (NIC teaming with LACP) with dual Gigabit ports. However the LAG setup didn’t seem to have issues previous to the 1.5.6 update.

So I have had the following issue for the last few months and haven’t been able to figure out what’s going on. The issue seems to only be with any of my windows 10 images, including ones I have just created… and only on the 1st attempt FOG takes to image the machine. After the client machine reboots from the error it images just fine. The error is that it is unable to locate the image store (/bin/fog.download).

Based on searches it seems to be an issue with FTP… I did notice that somehow my deployment server now has both a “fog” and a “fogproject” user account that it uses. I have to use one for my storage node settings and the other for the FTP username and password under the TFTP settings. If I try to use one account or the other for both I can no longer update my kernel and other functions break.

The only thing I can think of is that somehow things got screwy when I went from being on some test builds for troubleshooting last year back to a stable build when 1.5.6 came out.

Any suggestions for fixing this is greatly appreciated.

@buercky Awesome! Glad to hear it’s working now.

@buercky So, I see one thing in your screenshot that concerns me… you have two option 66 with one as the ipxe.efi instead of your server IP. Here’s what my DHCP options look like after applying the options from the guide:

@buercky This is probably a dumb question but your boot file is set to ipxe.efi, right?
We have our DHCP dishing out different boot files using these settings:
https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy

Is this a 7400 or a E7400? I assume the 1st option since you said the device is new. I just received a 7400 2-in-1 today that I was able to get into the FOG menu by using one of these:
https://www.dell.com/en-us/shop/dell-adapter-usb-c-to-ethernet-pxe-boot/apd/470-abnd/pc-accessories
I had to enable booting through thunderbolt to use this. It may be possible that you can only pxe boot with the one I listed. I know we had trouble with some USB-C Precision laptops that had to use the adapter above. Then there is Microsoft and their surface. Also, mine had an nvme ssd that I had to switch from raid to ahci to get FOG to see the hard drive.
I am using 1.5.6 and bzImage Version: 4.19.48.

@lschnider if you are doing a golden image (one image for multiple models), then I strongly suggest doing sysprep for Windows 10. I sysprep mine from “audit mode”, which became necessary when trying to remove windows store apps from being created when a new user gets created. There are other reasons we had to go that route as well, but my memory is a bit hazy as to what we had to do. I will get to build the golden image from scratch again once the next spring update comes out.

If you aren’t doing much customizing, you may not need audit mode, but I think you need sysprep for the driver injection to work correctly (assuming you are going for a zero-touch installation).

@george1421 @Sebastian-Roth what about a compromise? Is it possible to have accounts for logging into the fog web UI that have limited access? Like only the hosts tab and image / capture from the list of clients. You can protect certain images from being written over already, so he can protect anything he doesn’t want modified and unlock as needed for his lower tier staff.

I think it was back in 1.4.x that FOG had limited user accounts that could deploy images, it seems they were removed though.

@george1421 virtualbox does not. @lschnider make sure you don’t turn off EFI in virtualbox until after the VM has shut down and just before uploading. Otherwise you have to go back to your snapshot do the sysprep again.

Then, as @george1421 said, you get to play musical chairs with your boot files, using undionly.kpxe for uploading and ipxe.efi for deploying.

I set up the DHCP rules on one of our dhcp servers (only one that was 2012…) and I can vouch that it saves a LOT of headaches.

@Sebastian-Roth awesome, thanks! I’ll give it a while on my VM’s tonight.

@Sebastian-Roth No worries, I know you guys have a lot on your plates. I just wanted to make sure it got noted that there was a bug.

I can confirm that your workaround works, thanks. The group printer page still doesn’t reflect the settings applied, but it I go into the members it does seem to have the correct settings. I will use this until a patch can be made. Thanks!

@george1421 said in Dell Latitude 5590 issues after imaging:

change drive controller from raid-on to ahci mode.

Hey George, I noticed that when deploying my UEFI Win10 images, that it didn’t seem to matter if the client was raid-on or ahci. I’m guessing because my image is sysprepped and uses your driver install, but yeah… doesn’t seem to care anymore for me at least. ¯\ _ (ツ)_/¯

in virtual box machine go to settings>system>extended features and check enable efi(special OSes only) correct?

Yes, I have that box enabled. If you created your image with that box unchecked, then your Windows install is set up to install on a legacy BIOS. I had my images set that way initially but ran into BIOS exit type issues from the FOG PXE menu, so started over as EFI. As a side note, I do have to switch the EFI setting back off right after I run sysprep and shutdown, as FOG only picks up up my VM for uploading with EFI off. Virtualbox won’t pxe boot when EFI is on.

where do you enable IPv4 in UEFI

@lschnider I couldn’t find a 5590 nearby, but here is the BIOS settings on a 7040:

Settings -> System Configuration -> Intigrated NIC
Check the box that says “Enable UEFI Network Stack” with Enabled w/PXE selected.

Also… you may need to switch your SATA Operation to ACHI instead of RAID if you have it in legacy mode.