Windows 10 single disk resizable, stuck on BIOS screen after process

[banana123]

Hi All, I have this issue using single disk resizable to capture that I can’t figure out. Using Multiple Partition Image - Single Disk (Not Resizable) DOES work fine. Fog 1.5.7

Windows 10 1903 with the following disk partitions, standard w10 with a Recovery

I do the normal capture task, and when it finishes I get completely frozen at the Dell logo bios screen. I can’t even boot into any F key. It will just show a bar then completely freeze. The ONLY way to fix this is to take the HDD out of the machine and wipe it. The machine is a Dell 3500 Latitude Laptop w/ m2 nvme . I tried multiple times and upgraded to latest firmware. No matter what, it will get stuck at bios bios screen and make me wipe the hard drive on a different machine.

IF I put that same harddrive with this image in a different dell Desktop, it does boot no problem.

Really confused, what can be done here? I will use the non resizable option, but im really curious on why this is happening and if anyone has a resolution on it.

[george1421]

IMO the partition table isn’t created correctly. The first partition must be the uefi boot partition. Without that partition the uefi bios can’t find the boot file and the system won’t boot. You can probably make it work if you modified the the bios setting to look on the second partition for the uefi boot loader, but its probably better if you just fix the partition layout,

Also I question the value of a recovery partition in an enterprise environment where it may be just quicker to reload the image with FOG than trying to recover the system using the recovery partition.

[banana123]

Not sure how the partition table got messed up if that is the case.

Correct on the recovery partition, I can remove it. It would never be used. I can give the process another go with it removed and see what happens.

[Sebastian Roth]

@banana123 Where do you actually capture the image from I am wondering?

IF I put that same harddrive with this image in a different dell Desktop, it does boot no problem.

So it seems like there is some particular issue with this model. While it’s very hard to guess on what might be causing the hang/freeze I could imagine it being some part within the bootloader code that FOG captures and deploys to your target machine. Therefore I asked on where you capture the image from, which model is the source?

As far as I know the EFI partition doesn’t necessarily need to be the first one. Usually the UEFI firmware is able to go through different partitions, check the filesystem to find FAT32 formatted ones and search for known bootloader binaries. But I could be wrong.

@banana123 Would be helpful if you could post the contents of the test files d1.partitions as well as d1.minimum.partitions here in the forum. You find those on your FOG server in /images/#NAMEOFIMAGE#. This way we quickly see if partitions are being messed up. I highly doubt FOG does this.

[banana123]

@Sebastian-Roth said in Windows 10 single disk resizable, stuck on BIOS screen after process:

@banana123 Where do you actually capture the image from I am wondering?

IF I put that same harddrive with this image in a different dell Desktop, it does boot no problem.

So it seems like there is some particular issue with this model. While it’s very hard to guess on what might be causing the hang/freeze I could imagine it being some part within the bootloader code that FOG captures and deploys to your target machine. Therefore I asked on where you capture the image from, which model is the source?

As far as I know the EFI partition doesn’t necessarily need to be the first one. Usually the UEFI firmware is able to go through different partitions, check the filesystem to find FAT32 formatted ones and search for known bootloader binaries. But I could be wrong.

@banana123 Would be helpful if you could post the contents of the test files d1.partitions as well as d1.minimum.partitions here in the forum. You find those on your FOG server in /images/#NAMEOFIMAGE#. This way we quickly see if partitions are being messed up. I highly doubt FOG does this.

I am doing the capture directly from the problem system, a Dell Latitude 3500. Right after donig the capture the stuck @ dell logo will occcur.

I deleted the image from my FOG server, but I have the d1.partitions from my non-resizable image that works [0_1580151032294_d1.partitions](Uploading 100%) if that helps

label: gpt
label-id: E3756D2D-6EEC-459F-BFA3-B0DCB3D4891D
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 500118158

/dev/nvme0n1p1 : start=        2048, size=     1083392, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=B4F54B55-07DE-41E0-932A-9FEC86A30A65, name="Basic data partition"
/dev/nvme0n1p2 : start=     1085440, size=      202752, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=B7155540-CEA7-4F35-BDDB-E3CEF4D40130, name="EFI system partition"
/dev/nvme0n1p3 : start=     1288192, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=FA93F7E5-982E-476F-93D1-8DBC9E9E6ABC, name="Microsoft reserved partition"
/dev/nvme0n1p4 : start=     1320960, size=   498797199, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=AD6ABD0C-959A-491C-A9A5-FDDD31822B65, name="Basic data partition"

[Sebastian Roth]

@banana123 Ok, this might seem strange on first sight as we only see three partitions in Windows disk management picture but four in the partitions listing. Though Windows does hide some partitions and it seems like partition three (size=32768 blocks/16 MB, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE) is not shown in disk management.

I deleted the image from my FOG server, but I have the d1.partitions from my non-resizable image that works [0_1580151032294_d1.partitions](Uploading 100%) if that helps

Not really as we need the actual figures

I am doing the capture directly from the problem system, a Dell Latitude 3500. Right after donig the capture the stuck @ dell logo will occcur.

Ok, that’s definitely an issue we should look into. FOG (or FOS, the FOG OS) tries to shrink the partitions for a resizable capture and ends up leaving an unbootable system behind. The best way to find the issue is to restore the machine to default (using your non-resizable image), then associate a resizable image to this host, schedule another capture task but select debug mode (checkbox in the web UI) this time. Boot up the machine and hit ENTER twice to get to the console. Here you set a temporary root pasword (command: passwd) and get the current IP address of this machine: ip a s

Now go back to your working PC, download and open Putty or any other SSH tool and connect to the IP and login. To start the capture task you simply issue the command fog. Now you can step through the whole process and copy all the output text over to a text file or directly to the forum. Please get all text output from start to end and post that here.

[banana123]

@Sebastian-Roth This is done. I have attached the log file. FOGDEBUGLOG.txt and the partition files from /images , I am still at the debug menu after the capture, should I do anything else where I am here?’
Thanks

label: gpt
label-id: E3756D2D-6EEC-459F-BFA3-B0DCB3D4891D
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 500118158

/dev/nvme0n1p1 : start=        2048, size=     1083392, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=B4F54B55-07DE-41E0-932A-9FEC86A30A65, name="Basic data partition"
/dev/nvme0n1p2 : start=     1085440, size=      202752, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=B7155540-CEA7-4F35-BDDB-E3CEF4D40130, name="EFI system partition"
/dev/nvme0n1p3 : start=     1288192, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=FA93F7E5-982E-476F-93D1-8DBC9E9E6ABC, name="Microsoft reserved partition"
/dev/nvme0n1p4 : start=     1320960, size=   498797199, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=AD6ABD0C-959A-491C-A9A5-FDDD31822B65, name="Basic data partition"

d1.minimum.partitions

label: gpt
label-id: E3756D2D-6EEC-459F-BFA3-B0DCB3D4891D
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 500118158

/dev/nvme0n1p1 : start=        2048, size=      813238, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=B4F54B55-07DE-41E0-932A-9FEC86A30A65, name="Basic data partition"
/dev/nvme0n1p2 : start=     1085440, size=      202752, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=B7155540-CEA7-4F35-BDDB-E3CEF4D40130, name="EFI system partition"
/dev/nvme0n1p3 : start=     1288192, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=FA93F7E5-982E-476F-93D1-8DBC9E9E6ABC, name="Microsoft reserved partition"
/dev/nvme0n1p4 : start=     1320960, size=    58814296, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=AD6ABD0C-959A-491C-A9A5-FDDD31822B65, name="Basic data partition"

[Sebastian Roth]

@banana123 said in Windows 10 single disk resizable, stuck on BIOS screen after process:

I am still at the debug menu after the capture, should I do anything else where I am here?’

Not right now. Just shut it down (halt). I need a bit more time to look at all the information closely. Will do this as soon as I have a bit more time.

[Quazz]

@banana123 Looks like your first partition is incorrectly identified as being resizable, which is likely at the root of your problems.

Though, it looks like that partition has been altered in some way.

Currently, FOS uses partition flags to attempt to identify “non-resizable” partitions.

As far as I can tell, your first partition is missing essential flags (namely System and Active), causing FOS to misidentify the partition as a normal NTFS data partition that should be resized.

[george1421]

@Quazz said in Windows 10 single disk resizable, stuck on BIOS screen after process:

your first partition is missing essential flags (namely System and Active),

Only adding color commentary here: That is because it (the first partition is neither). The first partition is a recovery partition which isn’t typically bootable. While the partition layout is functionally ok, its not standard or correct. In almost all instances the uefi boot partition should be the first partition on the disk so the uefi firmware can find the boot files. It is possible to update the uefi firmware by creating an entry in the uefi boot manger to look for the uefi files on the second partition, that seems a bit awkward to do that for every system this image is deployed to. Its best to fix the partition table to match the MS standard layout. And again the recovery partition is not typically needed in an enterprise environment.

[banana123]

@george1421 I am not sure how to fix this partition layout in its current state, since If I delete the recovery partition it won’t be adjacent to extend with my data partition. I looked into some freeware partition tools but it didn’t seem to cover what I need to do.

I am a bit confused though, since I am seeing other w10 GPT disks with Recovery being on partition 1

Is my best course of action here just starting a new w10 image?

[banana123]

@banana123

I installed a fresh W10 and compared the log files and how it handled this partition. I changed the flags on the recovery partition so it matched. I ran these on the Recovery partition from diskpart to get it back to normal. Went to do a resize capture, saw it not resize in log file, but still got stuck on Dell Logo http://prntscr.com/qu632u

set id="de94bba4-06d1-4d40-a16a-bfd50179d6ac"
gpt attributes=0x8000000000000001

label: gpt
label-id: E3756D2D-6EEC-459F-BFA3-B0DCB3D4891D
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 500118158

/dev/nvme0n1p1 : start=        2048, size=     1083392, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=C0E109E0-E41D-47CB-8798-38C184966E0C, name="Basic data partition", attrs="RequiredPartition GUID:63"
/dev/nvme0n1p2 : start=     1085440, size=      204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=D8942D98-D71D-4348-8909-A6BC265A8BBB, name="EFI system partition", attrs="GUID:63"
/dev/nvme0n1p3 : start=     1290240, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=E9F36812-1E24-4028-873E-83C84B42E9DE, name="Microsoft reserved partition", attrs="GUID:63"
/dev/nvme0n1p4 : start=     1323008, size=   498794496, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=C0AECA45-A5CD-4B3C-AB8A-F3102F545114, name="Basic data partition"

label: gpt
label-id: E3756D2D-6EEC-459F-BFA3-B0DCB3D4891D
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 500118158

/dev/nvme0n1p1 : start=        2048, size=     1083392, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=B4F54B55-07DE-41E0-932A-9FEC86A30A65, name="Basic data partition", attrs="RequiredPartition GUID:63"
/dev/nvme0n1p2 : start=     1085440, size=      202752, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=B7155540-CEA7-4F35-BDDB-E3CEF4D40130, name="EFI system partition"
/dev/nvme0n1p3 : start=     1288192, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=FA93F7E5-982E-476F-93D1-8DBC9E9E6ABC, name="Microsoft reserved partition"
/dev/nvme0n1p4 : start=     1320960, size=    59195110, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=AD6ABD0C-959A-491C-A9A5-FDDD31822B65, name="Basic data partition"

[Sebastian Roth]

@banana123 said in Windows 10 single disk resizable, stuck on BIOS screen after process:

Went to do a resize capture, saw it not resize in log file, but still got stuck on Dell Logo

We might need to look into that state a bit more. Any chance you can get some more information on what happens at this point? Does is wait or freeze? Caps lock, Num lock still working? Maybe disable fast boot in the UEFI setup to hopefully get some more hints on what the issue is?!

While this partition layout might now be standard (George you are absolutely right) I still don’t have a clue why you can capture and deploy as non-resizable but it seems to be doomed when capturing as resizable.

[banana123]

@Sebastian-Roth just stuck at Dell logo. I can press caps lock to toggle, I can alt + ctrl + del. If I try to quickly boot into an F Key, it will show a bar but get stuck at 30%. Fast boot set at minimal… .

[george1421]

@banana123 As a point of data collection, how did this disk get created in this state? This is not how the M$ installer creates the disk layout.

Through MDT its efi, c drive 99% of free, recovery partition 100% of free space.

Someone/thing had to create this format structure intentionally.

[Quazz]

@banana123 I agree with George.

The type matches a normal Windows first partition, but it appears to have been heavily modified afterwards to be “recovery”.

And it seems your second partition is now getting resized for whatever reason…

If you don’t need the recovery partition it seems best to just start over.

[banana123]

Not sure what happened, I originally created the image on another physical machine.
I am going to restart with a new image.

Thanks all

[dclark]

@banana123 Did the new image fix the issue for you? I am having the same issue with the Latitude 3400 model. If it did what changes did you make? Ours was working and then I updated the image with the latest Windows updates and a couple of testing apps needed by the users and now the 3400 exhibits the same behavior as you describe. All other models here are working fine with the latest image. (Windows 10)

[Sebastian Roth]

@dclark I kind of doubt you are having the exact same issue. While it might look the same at first I am fairly sure your partition layout is differnt and that is playing a big role in this case. Please open a new topic and post all your details so we can help properly: FOG version, Linux OS version, image type (resize or not), contents of d1.partitions, d1.minimum.partitions and d1.fixed_size_partitions…

[banana123]

@dclark I ended up just redoing my image for my Latitude 3500s with a clean install of latest W10 from USB. I gave up trying to fix the partitions/issue.

No issue with new image and deployed a bunch so far (single disk resizable)