@Sebastian-Roth As far as I understand, any tool that uses BLKRRPART could be prevented access because of udev event handling.

It’s usually very fast and therefore unlikely to cause issues, but since it is executed parallel to everything else it can potentially get in the way from time to time.

As far as I know, other programs that interact with the storage device act in the same way and also use BLKRRPART (such as fdisk and hdparm)

For now, I’d say, leave it as is and monitor for reported problems. This problem is rare enough on its own already (personally haven’t come across it at all) that it doesn’t really warrant changing everything with the possibility of the affecting something else. (doesn’t look like it should, but never know)

edit: Important to note that Kernel version could affect how BLKRRPART functions and what not plus the udev events would be handled by the kernel as well afaik, so perhaps it’s as simple as the kernel versions?

@duanekaeb One other thing I had to do once upon a time was run

dism /online /cleanup-image /startcomponentcleanup

in command prompt before sysprep and capture

@george1421 I don’t believe FOS github has the fix included yet at this point, though shouldn’t be too long.

Still trying to figure out if/when/where the problem exactly started.

As far as I could find it’s supposedly been around for ages (sfdisk - udev conflict), but isn’t necessarily triggered usually.

@azra Interesting, not sure why it still tries to capture in raw.

Though I do recommend moving the 300MB partition to be the first one (as that will give trouble with resizing), we should probably hold off on that until the first partition is seen as NTFS by partclone.

@george1421 Well, we did find a resize bug in the inits, particularily on fast disks.

Might be time to revive this idea soon and test it out again.

@JGwinner FOG 1.5.7 is out now with Debian 10 installation support if you want to give it a try.

There’s something strange going on here, you C: drive is 900GB yet partclone only reports 500GB?

It also says /dev/sda1, though on windows 7 we’d expect /dev/sda1 to be a partition called “System Reserved”

Can you post a screenshot of disk management here?

@KennethJ Perhaps the API? https://news.fogproject.org/simplified-api-documentation/

Issue is likely similar to if not the same as

https://forums.fogproject.org/topic/13440/fog-1-5-6-auto-resize-is-unpredictable

@Eric-Johnson Very interesting, here’s what sfdisk man page has to say about it.

sfdisk uses BLKRRPART (reread partition table) ioctl to make sure
       that the device is not used by system or another tools (see also
       --no-reread).  It's possible that this feature or another sfdisk
       activity races with udevd.  The recommended way how to avoid possible
       collisions is to use exclusive flock for the whole-disk device to
       serialize device access.  The exclusive lock will cause udevd to skip
       the event handling on the device.  For example:

              flock /dev/sdc sfdisk /dev/sdc

       Note, this semantic is not currently supported by udevd for MD and DM
       devices.

So perhaps adding flock $disk before sfdisk $disk < $file will resolve it

Making the line read as flock $disk sfdisk $disk < $file