@george1421 said in Error capturing Win 10 image after updating to the latest dev version - Resize Test fails:

Would it just create a larger disk image?

Yes exactly.

If yes then 7 or 8 might be a good start if size is the only penalty.

Ok, will 7 do for now.

@x23piracy Sorry for the long delay! This is a known issue in an older version of FOG and fixed in 1.5.9 and later.

@Mightmar Sorry for the long delay. Have been pretty busy.

I suggest you try to figure out what hash sums should be correct. Grab a copy of the file on the host machine, e.g. C:\Program Files (x86)\FOG\tmp\run_wpkg.bat and calculate the SHA256 hash sum for it. Also check the contents of the file on the host.

@ksrvpvl Hostname is allowed in the latest dev-branch version (1.5.9.140).

@mrp Added to the official FOS inits now. Can’t wait any longer for you to test.

@george1421 Yes i already try this. Works fine but already my problem with Bitlocker.
Actually my problem is our computers are configure to boot on pxe when receive wake on lan.
And Bitlocker ask recovery key if order boot has changed.
But i notice if i reboot “normally” even after that, Bitlocker don’t ask recovery key Bitlocker.
My problem is for our computers “Refind EFI” is the only mode who work with pxe. If i use other option, i have an error like “Chainloading failed”.
This is why i was thinking to have a “reboot” mode, because i don’t find how to make it work the “Exit” mode

@joanmarzo ?? OK but I don’t think the problem is FOG but if you want to reinstall that is your choice. We will be here to help if you need it.

I’ve never run into this specific problem until today. Generally, issues with resizing can be fixed by increasing the CAPTURERESIZEPCT in Fog Settings > General Settings. I agree with what @Quazz said about certain kinds of fragmentations causing issues with the theoretical minimum partition size. I’ve found that the more used (fragmented?) a drive is, the more likely it is to fail during resize. I was able to get past the no space left on device and numerical result out of range errors by increasing the CAPTURERESIZEPCT to 15%.

@george1421 0e6dce0b-716b-4019-86f7-09c37e7b1902-image.png IT’S WORK!!! THANKS A LOT!

The fog kernel version is 5.15.19,

I have created the Linux os image from laptop model hp probook440G8 in the fog server.

while I am trying to deploy the image with the same laptop model, it’s showing me the options as I have shared the previous image.

@TaTa The default NFS in FOG is still version 3 which has no concept of user authentication/authorization. Sure you can try to lock things down a bit by setting access rights on the FOG server filesystem.

But if you want to go beyond that you will need to look into NFSv4 which is not implemented yet: https://forums.fogproject.org/topic/14791/feature-request-for-fog-1-6-x-configure-image-capture-to-use-nfsv4-instead-of-nfsv3

Final update: Got everything working! The monitor not waking up after sleep was fixed by adding in some extra graphics drivers to the kernel and we’ve found some solutions to wiping difficult machines (like Lenovo’s) which normally force you to use tools built into the UEFI or a special Lenovo wipe program that only works on certain models and asks you to confirm 5 times and gives you a random generated key that you have to enter in after a reboot. As a note, even parted magic fails to wipe Lenovo drives.

Anyway, thank you @george1421 you’ve helped me to learn a great deal and enabled our success in this.

@dietrich07 Please don’t misunderstand what I say. What you ask is not the main focus of the FOG Project, but I also give you an idea how to get these missing CD based programs into the live environment. You need to just add them to the boot.wim file. Then when the liveos boots your programs will be there too.

@anieto93 There was a fixed that was pushed out just recently in FOG 1.5.9.120 (or later that should also address this). Starting with FOG 1.5.9.110 in the dev branch that fixed an issue that existing in FOG 1.5.9GA towhere MS changed the disk structure in Win10 20H2 that caused the disk to not expand correctly. It was that small recover partition that was keeping the 😄 drive from expanding. Removing the recovery partition fixed the issue with 1.5.9GA. There was a workaround for the change added to FOG 1.5.9.110. And now a new issue was fixed with resizing with 1.5.9.120 but I don’t know the details with that.

I’m glad you have it sorted out before the fix was published.

New tests:

I deploy myImageV1 on my test workstation with FOG 1.5.9 + init.xz from 2020 (see my previous post) Boot my test workstation on a Ubuntu LiveUSB to change logical partition (sda2) into primary one with fixparts + resize partition with gparted + fsck + grub-install Modify what I want on the system (do system updates, modify the content of a configuration file) Capture from my test workstation to myImageV2 (with FOG 1.5.9 + init.xz from 2020) Deploy my new myImageV2 to my test workstation (with FOG 1.5.9 + init.xz from 2020) The partition is properly expanded

.
AMO, the logical partition (sda2) confuses / puzzles partclone (or an another piece of software).

My new myImageV2structure:

$ ls -lh /images/myImageV2 total 53G -rwxrwxrwx 1 root root 2 Apr 7 12:58 d1.fixed_size_partitions -rwxrwxrwx 1 root root 0 Apr 7 12:59 d1.has_grub -rwxrwxrwx 1 root root 1.0M Apr 7 12:59 d1.mbr -rwxrwxrwx 1 root root 208 Apr 7 12:59 d1.minimum.partitions -rwxrwxrwx 1 root root 16 Apr 7 12:58 d1.original.fstypes -rwxrwxrwx 1 root root 0 Apr 7 12:58 d1.original.swapuuids -rwxrwxrwx 1 root root 1.7K Apr 7 12:59 d1p1.img -rwxrwxrwx 1 root root 53G Apr 7 13:31 d1p2.img -rwxrwxrwx 1 root root 208 Apr 7 12:58 d1.partitions $ cat /images/myImageV2/d1.fixed_size_partitions 1 $ cat /images/myImageV2/d1.minimum.partitions label: dos label-id: 0x78c7d5cb device: /dev/sda unit: sectors sector-size: 512 /dev/sda1 : start= 2048, size= 1048576, type=b, bootable /dev/sda2 : start= 1050624, size= 278817898, type=83 $ cat /images/myImageV2/d1.original.fstypes /dev/sda2 extfs $ cat /images/myImageV2/d1.partitions label: dos label-id: 0x78c7d5cb device: /dev/sda unit: sectors sector-size: 512 /dev/sda1 : start= 2048, size= 1048576, type=b, bootable /dev/sda2 : start= 1050624, size= 499067392, type=83

After the deployment of my new myImageV2 (all is fine):

root@testwks:~# fdisk -lu /dev/sda Disk /dev/sda: 238,49 GiB, 256060514304 bytes, 500118192 sectors Disk model: SK hynix SC311 S Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: dos Disk identifier: 0x78c7d5cb Device Boot Start End Sectors Size Id Type /dev/sda1 * 2048 1050623 1048576 512M b W95 FAT32 /dev/sda2 1050624 500118015 499067392 238G 83 Linux root@testwks:~$ parted /dev/sda print Model: ATA SK hynix SC311 S (scsi) Disk /dev/sda: 256GB Sector size (logical/physical): 512B/4096B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 538MB 537MB primary fat32 boot 2 538MB 256GB 256GB primary ext4 root@testwks:~# df -h / Filesystem Size Used Avail Use% Mounted on /dev/sda2 234G 123G 100G 56%

@marco_c said in FOG/PXE/W10 unattended install and boot:

this might save me many many hours

It will take hours to setup on the front end, but if you have 100 nodes to create it will surely help you on the back end making all of the nodes exactly alike.

The actual deployment times we are seeing with FOG is under a 4 minute push of the captured image 25GB image, and about 12 minutes of windows OOBE normal unattended setup. So in about 15 minutes we can go from bare metal to ready for user.

Understand that it took us a week to perfect our first golden image back in 2015. But we’ve automated that process now with MDT to build the golden image and then FOG to deploy it.

There are many great tutorials on the internet that explains the Windows unattended deployment process (this is outside of what imaging tool you use).

@george1421 You sir are a fucking LEGEND!!! I’m all set for now. Time to get playing with images and deployments. Thank you so so so sooooo much 😄

@zaboxmaster You might want to tweak your deployment strategy if you are using the fog client. If you are not using the fog client then you can use the system builder method of load and go by pxe booting into the iPXE menu and pick the deploy image menu. Once the image is deployed using this method the reference to the computer is removed from FOG. There is no need to register and deploy using this method.

The down side of “load and go” is that you can’t use the fog client to make changes to the target computer like system renaming or snapin deployment, that requires the target computer to be registered in FOG.

Hello,
Sorry for the delay, I just noticed the change made.
I can’t wait to try this tomorrow.
I will come back to you.

@sborgne Bonjour, Merci beaucoup . Je teste cela demain.

Regards.

George’s post is valid. Just wanted to add that regular ole storage nodes within the same storage group will load share. You’d set the max hosts on each storage node to accomplish this.