@zagaeski Definitely follow what George suggested! As well I am just wondering if this is a single machine or do you have several of those HP Probook x360 11 G1 EE and all show this issue?
Posts made by Sebastian Roth
RE: NTFS partitions corrupt after capturing resizable image
Created host and single disk resizable image.
Why do you choose resizable if you intend to make a backup copy of this laptop? This backup is supposed to go back to the same machine with the same disk and there shouldn’t be a need to use resizable image type for that reason!
This image type is “messing” with your partitions and therefore I’d not consider this as a “backup save” image type!!
The non-resizable images type don’t take up more space for storing the image on your FOG server either.
Did you disable Windows 10 fast boot and properly shutdown before you started the capture? https://wiki.fogproject.org/wiki/index.php?title=Windows_Dirty_Bit
My previous experience with FOG also resulted in corrupted HDDs when capturing. It seems that FOG just isn’t careful enough with the source disk.
There is no way we can prevent users from all different kinds of situations. We try to make FOG with as much care as we can bit it’s like a swiss knife and if someone uses it the wrong way no one will blame the factory or engineers for having created a dangerous tool, right?!
I am not sure if we are able to help. We will surely try but the situation is not easy with all the things that have gone wrong so far.
Can you boot using a Windows 10 DVD and get into a CMD shell there and run
chkdskcommand? What output do you get from that? We need a picture!
RE: HP Probook x360 11 G1 EE Unable to Image
@zagaeski Try updating to the latest kernel to see if that fixes the core dump.
If that doesn’t work I’d advice you to manually download the latest init files and try those: http://fogproject.org/inits/init.xz and http://fogproject.org/inits/init_32.xz (both go into
RE: DHCP issues
@nelsonnc Sounds a bit like STP issue to me as well. The quickest way to check is to connect a dumb mini switch between that client and your building switch. See if that makes a difference.
How do you know the client can reach the FOG server? When it’s booted to it’s OS from disk, can you open that exact URL in the browser on that client? http://dlk.fog.local/fog//index.php (double slash is not an issue)
RE: Skipping partition restore (MBR Only)
@kkptrck While the message “Skipping partition restore (MBR Only)” is somehow confusing and shouldn’t be printed in your case I don’t think it’s actually causing your system to fail to boot after deploy.
What is the source? Are source and destination machine similar or same? Legacy BIOS vs. UEFI? SATA / SSD vs. NVMe? Other hardware components? Is the image syspreped?
RE: Swap UUID does not match after deploy
One thing I also noticed is that the original system that I capture from uses paths like /dev/nvmeXXXX when I look at the comments in /etc/fstab.
But the system I deploy to shows paths like /dev/sdaX when using lsblk.
I am fairly sure this is where things go wrong… While we do handle the switch form NVMe to SSD and vice versa in most cases it seems like we fail to do so for the SWAP UUIDs. I can think of a fix here (using just the partition numbers instead of full partition device names in
d1.original.swapuuids) but for now I’d suggest you manually adjust
d1.original.swapuuidsto match your target system device names…
RE: Windows 10 Error on deployment only on 1st attempts...