Dell Latitude 5590 issues after imaging
-
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.
-
Can you reset the configuration back to uefi mode, enable uefi pxe boot stack, disable secure boot, change drive controller from raid-on to ahci mode. Also as stated below, your golden image needs to match the target computer. UEFI golden to UEFI target, and BIOS golden to BIOS target. You can’t mix the image/firmware formats.
-
@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. ¯\ _ (ツ)_/¯
-
@jflippen said in Dell Latitude 5590 issues after imaging:
it didn’t seem to matter if the client was raid-on or ahci
Unless Sebastian was able to work it out, there is an issue (at least historically) with linux (in general), uefi mode, Dell computers with disk mode in raid-on. In this configuration the FOS engine can’t see the disks behind the disk controller with raid-on mode. This isn’t specifically an issue with FOS, but a linux / intel rapid store disk controllers in uefi mode. With that said newer kernels may now contain that intel raid driver. I haven’t checked since 4.16.x.
If you can image dell uefi system with the raid-on mode set then that will fix a whole lot of evils. I have a working model for pxe booting when secure boot is on. Getting that integrated into FOS, would fix some other pains too.
-
@george1421 @jflippen Well I am more than happy to add those things if possible. I don’t have the hardware to test around - only using VMs for testing.
Please open new topics for those issues and give more information and I will look into it.
-
@jflippen said in Dell Latitude 5590 issues after imaging:
you need to use ipxe.efi as your boot file
So we also have some HP’s that i have setup for legacy and they work great, does that mean when im going to image a legacy bios i have to change the dhcp boot file to undionly.kpxe for those and then to ipxe.efi for the uefi computers?
@Sebastian-Roth @george1421 -
@lschnider The short answer is yes to your question. Each firmware type needs the proper boot loader.
A bit longer answer is if you have a linux dhcp server or MS windows 2012 or newer dhcp server you can have the dhcp server automatically switch to the right bootloader based on the type of computer is pxe booting. The instructions are covered here: https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence
-
@george1421 okay i might try to follow that tutorial, so for now i changed the option 067 boot file name to ipxe.efi and changed all the appropriate settings on the laptop. and then heres how it goes. it says checking media presence>media present>start pxe over IPv4>station ip is 10.2.227.200>nbp file name is undionly.kpxe> nbp file size is 97003 bytes>downloaded nbp successfully> then it doesnt boot into fog or anything
Im not sure where its getting the filename undionly.kpxe unless you have to change it in multiple spots. -
@lschnider said in Dell Latitude 5590 issues after imaging:
nbp file name is undionly.kpxe
if you see NBP that means the system is in uefi mode. Loading undionly.kpxe will give you no joy.
Do you have multiple dhcp servers like primary and backup? Or do you have subnet zone specific settings. Are you using dnsmasq to override dhcp pxe boot values?
The pxe booting client will only get is boot file name from dhcp option 67 or from a proxy-dhcp service request.
-
@george1421 we do have 2 dhcp servers but i made sure i changed that setting on both.
-
@george1421 actually i think it was an issue with the way our dhcp server replicates the backup, for some reason the primary changed itself back to undionly.kpxe when i changed that the second time, it started working and can boot into fog. now i will create my efi image and test it to see if it works.
-
@george1421 @jflippen so when i create the base image in virtualbox as efi, i do sysprep and then turn of efi, do i need to change my dhcp server back to undionly.kpxe boot file to take the image from virtualbox as legacy and then change to ipxe.efi to push the image out to the uefi laptop?
-
@lschnider Does virtual box pxe boot in uefi mode? If not you will need to do what you suggested, switch back to bios mode on the vm to capture, change the boot file to undionly.kpxe, capture the image. Then change your boot file back to ipxe.efi and deploy the uefi image to a uefi computer (hint: setting up dhcp to dynamically handle this would save you troubles later)
-
@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.
-
@jflippen okay sounds good i will do that with our dhcp servers as well, they are 2016 though. Also you stated the thing about doing sysprep, is there any big benefit to doing sysprep before capturing the image? is it just since its a new windows experience everytime(is that the only benefit)? We use FOG for our computers in house but when i do sysprep it basically just adds a couple more steps so it doesn’t help me unless there is something major that im missing.
-
@lschnider said in Dell Latitude 5590 issues after imaging:
Also you stated the thing about doing sysprep, is there any big benefit to doing sysprep before capturing the image?
Yes there is. Sysprep prepares the system for cloning and gets it ready for OOBE on the next boot (to be used once the golden image has been deployed to the final target computer). You should use the sysprep command line option to power off the windows computer to ensure its power off correctly. In windows 8 and later the start menu shutdown doesn’t actually power off the computer, but puts it into a deep sleep leaving files open and the disk marked as dirty. FOG will not backup a disk with the dirty bit set. If you don’t let sysprep power off the computer, then use
shutdown -f -s -t 0to power off the computer. -
@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).
