ntfsresize fails to resize partition with a Windows 11 install

[ashrude]

Hi,
I've been experiencing this issue while imaging windows 11 machines. The issue I believe I've been experiencing is here:
tuxera/ntfs-3g#142

I get these errors while trying to image with fog:

Failed to make room for attribute: No space left on device
Could not add attribute extent: No space left on device
ERROR(28): Could not update runlist for attribute 0x80 in inode 151603: No space left on device

As discussed in the ntfs-3g issue, adding 500mb or so avoids the issue. Would it be possible to do this in Fog?

Thanks!

[mastacontrola]

I am building an experimental FOS release that should account for always at least 500MB shrunk size:
https://github.com/FOGProject/fos/actions/runs/22585626865

it will take a while to build (1.5 - 3 hours or so)

please test and se eif that helps you out.

Thank you!

[mastacontrola]

Any word on this by chance, if available?

[ashrude]

Hi, sorry for the delay. I should be able to test this soon. How can I build FOS on my server? I see build.sh but do I need to pass it any configuration to match my server?

Also, once I have the build how do I deploy it to the server? This guide covers updating the kernel, is this all that's needed? Or is there a root filesystem that I need to deploy as well.

Thanks

[darksidemilk]

You should be able to see the experimental release in the Fog GUI under the kernel update section, you'll want both the kernel and the initrd update to the march 6th release (which is no longer experimental) or try the one added march 23rd.

If you wanted to do it the manual way, that guide does also cover moving the files to the /var/www/html/fog/service/ipxe which is where they need to be. You can either overwrite your current kernel and init so the default names work or you can name the bzImage and init.xz slightly different and set the custom names in your host settings to test a kernel and or init on a specific device.

[ashrude]

Hi, I've tried it with all three initrd/kernels with the same result.

This is also the the fdisk.list file from a clonezilla image of the same machine in case that's helpful:

Disk /dev/sda: 64 GiB, 68719476736 bytes, 134217728 sectors
Disk model: QEMU HARDDISK   
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: C09C130D-4911-42BC-ABAD-4B1F690BDF92
First usable LBA: 34
Last usable LBA: 134217694
Alternative LBA: 134217727
Partition entries starting LBA: 2
Allocated partition entries: 128
Partition entries ending LBA: 33

Device         Start       End   Sectors Type-UUID                            UUID                                 Name                         Attrs
/dev/sda1       2048    411647    409600 C12A7328-F81F-11D2-BA4B-00A0C93EC93B F1CAAA33-72D6-44AA-BF06-EA6E2FA32594 Basic data partition         GUID:63
/dev/sda2     411648    444415     32768 E3C9E316-0B5C-4DB8-817D-F92DF00215AE CE8592E7-C860-40BC-A56A-72A4F49C5053 Microsoft reserved partition GUID:63
/dev/sda3     444416 132708351 132263936 EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 59AAA48D-DC30-4763-97E3-DA207E83794A Basic data partition         
/dev/sda4  132708352 134213631   1505280 DE94BBA4-06D1-4D40-A16A-BFD50179D6AC 7AB2AD56-3622-4222-A5B3-43732EC1DD3C                              RequiredPartition GUID:63


Disk /dev/loop0: 386.39 MiB, 405164032 bytes, 791336 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

[mastacontrola]

Thanks for the screenshots, they show exactly what the 500 MB floor missed. Your volume has 10832 MB in use and the target was 11318 MB, but ntfsresize reports 5323 MB of relocations needed, and the file that records those relocations runs out of runlist room before the data runs out of clusters. That is ntfs-3g #142; no fixed floor covers it because the amount depends on how fragmented the volume is.

FOS #172 changes shrinkPartition() so that when the dry run fails with "No space left on device" it doubles the slack and tries again, stopping at the first size that passes. Each retry costs one more consistency pass. If nothing below the volume's current size fits, the partition is left at its current size (recorded as fixed) instead of failing the capture. Any other error still stops on the first try as before.

An experimental x64 init carrying that is building here:
https://github.com/FOGProject/fos/actions/runs/33638788153

Once it finishes, pick it up from the kernel/init update page in the web UI (or drop init.xz into /var/www/html/fog/service/ipxe as before; the kernel does not need to change). On your volume I'd expect to see a couple of "ran out of room relocating data at …k, retrying at …k" lines and then the capture proceeding. If it still fails, a photo of that section of the screen is all I need.