Windows 10/Dell Latitude 3400 Stuck On Bios Splash Screen After Imaging



  • FOG Version: 1.5.6
    Server OS: Ubuntu 16.04
    Image: Windows 10 - 1903 - Single Disk (resizable)
    Laptop Drive: SSDR,256G,P32,30S3,TOSHIBA,BG3 (m2)

    After updating our district image we are having an issue with Dell Latitude 3400 laptops. After imaging, the machine will only boot to the Dell BIOS splash screen, if you are lucky enough to catch it just right while frantically hitting the F2 or F12 key you may get it to show the loading bar at about 30% complete and it just sits there.

    If you pull the drive out of it you can boot to BIOS without issue, the only fix is to wipe the drive and re-format it, then you can image again but end in the same spot.

    I can image the 3400 laptop and then move the disk to different model laptops (5400 for example) and it will boot as expected and have no issues. I can also deploy the image to other models including desktops without issue, it is only the 3400 in our fleet that is displaying this behavior.

    We have been deploying the previous version of the image that was captured in November 2019 without issue to all models including the 3400.

    • Have tried 6 - 3400 model laptops between myself and my co-workers, all with the same result(s).
    • I have rolled the image machine back in the VM and installed updates and captured a second time to try and be sure it was a valid image on all levels.
    • I have both tried resetting the TPM keys both through Windows and BIOS without success.
    • I have tried a different brand SSD in the 3400 with the same result
    • I have wiped the SSD and used Dells built in (in BIOS) image recovery which fails with the error that it can not read the drive after it downloads everything
    • I have updated the FOG kernel to 4.19.101

    Image files

    d1.partitions

    label: gpt
    label-id: 91521D8F-4B1C-4155-BDAF-EFE1EF2B9D94
    device: /dev/sda
    unit: sectors
    first-lba: 34
    last-lba: 245759966
    
    /dev/sda1 : start=        2048, size=     1083392, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=4CC1E3E3-8352-45A0-96AA-9F072E2549F7, name="Basic data partition", attrs="RequiredPartition"
    /dev/sda2 : start=     1085440, size=      202752, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=E9037FBB-7056-4139-AE72-C7414CACC1C3, name="EFI system partition"
    /dev/sda3 : start=     1288192, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=26BC2AE0-6F79-4D6C-BFA4-058A28A64D9A, name="Microsoft reserved partition"
    /dev/sda4 : start=     1320960, size=   244436992, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=EC783155-21D1-4128-994D-09D41031763D, name="Basic data partition"
    

    d1.minimum.partitions

    /dev/sda1 : start=        2048, size=     1083392, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=4CC1E3E3-8352-45A0-96AA-9F072E2549F7, name="Basic data partition", attrs="RequiredPartition"
    /dev/sda2 : start=     1085440, size=      202752, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=E9037FBB-7056-4139-AE72-C7414CACC1C3, name="EFI system partition"
    /dev/sda3 : start=     1288192, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=26BC2AE0-6F79-4D6C-BFA4-058A28A64D9A, name="Microsoft reserved partition"
    /dev/sda4 : start=     1320960, size=    70536514, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=EC783155-21D1-4128-994D-09D41031763D, name="Basic data partition"
    

    d1.fixed_sized_partitions

    :2:3:1:1:2:3
    


  • @Sebastian-Roth - I will try these things when I get into the office on Monday morning. I believe that I have the 1903 image that was working prior to this last batch of windows/software updates that I can get the data from.


  • Developer

    @dclark Ok, seems like I was wrong when saying that partition layouts are usually different in the other topic. It’s not in this case and there really might be a connection. Though I still think it’s good to have two topics to not mix things up and confuse others who read it. So I will just cross link those topics: https://forums.fogproject.org/topic/14147/windows-10-single-disk-resizable-stuck-on-bios-screen-after-process

    Do you still have the image from before updating to Win 10 1903? Or maybe just a single PC that still has the old image/partition layout on it? Best if it’s a 3400 but others should do as well. Can we get the partition listing from that as a start to see why it worked before?

    So far I’d call this an ugly UEFI firmware issue not being able to boot from that partition layout. But there might be more to it. If you still have the old image on your FOG server I’d also test the following: Deploy the old image (or use a machine that still has this) and do the 1903 build update on that machine manually. Then see if it boots and how the partition layout looks like (boot into some Linux live ISO or FOG debug task and run sfdisk -d /dev/sda or sfdisk -d /dev/nvme0n1 depending on the drive you have in this machine.



  • Once a year I start a fresh base image of the version we are targeting, has been the **03 version so far, and we are currently using 1903. Throughout the year I will roll my VM back to just before the last SYSPREP and pull in any updates (we do not do any version upgrades and they are blocked in WSUS) and any software changes/updates needed. Then SYSPREP again and capture with FOG.

    I have noticed the Dell logo change intensity during boot but it has not seemed to be a factor, although it may be. When the BIOS starts to boot it just hangs. I will say these 3400’s have the newer BIOS with the more modern point and click GUI.

    Don’t even get me started on the WD19 dock…


  • Moderator

    I guess I have a comment and a question.

    We have the 7400s here and they drove me frick’n nuts until I understood them a bit better.

    1. The power on/off button is just a suggestion to power off if you hold it for 5 seconds. Sometimes I take 10 seconds of holding the power button in for computer to actually power off.
    2. If you want to hit the F2 or F12 keys, now this is a tricky part. If its from a cold boot the Dell logo will be 100% solid white. During booting the Dell logo will change to a 80% white (my guess) intensity. As soon as it changes to the 80 % intensity it will take the F2 or F12 keys. If you wait too long after the change it won’t take the key press. Now here is the kicker. If you reboot the computer from either the uefi firmware, vPro or Windows, you will never see that 100% to 80% change and you will not have a chance to enter bios or F12 boot manager.

    Understand these comments/opinions were created when the 7400s first came out. Later uefi firmware may address these issues and the issue with the WD19 dock not always presenting as a pxe bootable device.

    Now to the question. How do you build your reference image. Do you sysprep it and capture with FOG. Then when you want to update it again you unseal it it, update it and then resysprep and capture, or do you rebuild it every time with the updated features from the master WIM image? I have seen issues with the former especially if you do a version upgrade (i.e. 1703 to 1803)


Log in to reply
 

398
Online

6.6k
Users

14.0k
Topics

132.4k
Posts