The future of partclone and therefore FOG as it is

[george1421]

@Sebastian-Roth Not with a resolution as of now. But here is an update with good to know stuff.

I did a git pull on the fos github and updated my local repository with the master. Then without thinking overwrote all of the edits I did to the scripts in my rootfs_overlay directory. Not what I wanted to do but I rebuilt the inits without any of my edits and only with the 0.3.12 partclone build. Unfortunatly it still does the same with Win7 unable to boot.

BUT along the way I discovered something.

Per our earlier discussion I change the buildroot setting of

BR2_TARGET_ROOTFS_EXT2_SIZE="100M"

to

BR2_TARGET_ROOTFS_EXT2_SIZE="256M"

When I pxe booted into FOS I received the following error:

RAMDISK: incomplete write (-28 != 4096)
XZ-compressed data is corrupt
Kernel panic - not syncing: VS: unable to mount root fs on unknown

I went into FOG Configuration-FOG Settings->TFTP Server->KERNEL RAMDISK SIZE and viewed the size. The size default is 127000. I had the setting at 255000 because I was testing something earlier. This 255MB is of course smaller than the ROOTFS size I set in build root of 256MB. So the decompression failed and the kernel panicked because it couldn’t mount the virtual hard drive. Setting KERNEL RAMDISK SIZE to 300000 resolved the issue. I did not test any smaller to see where it started to fail due to time restrictions.

[Junkhacker]

@george1421 said in The future of partclone and therefore FOG as it is:

Not what I wanted to do but I rebuilt the inits without any of my edits and only with the 0.3.12 partclone build.

you must edit the funcs.sh file to remove the --ignore_crc flags or 0.3.12 will not work properly

[Sebastian Roth]

@george1421 said in The future of partclone and therefore FOG as it is:

RAMDISK: incomplete write (-28 != 4096)
XZ-compressed data is corrupt

Yes, ran into that yesterday already. See here. We moved back to 101 MB (just a little larger so that hopefully we don’t run into a space issue again) for 1.5.6 binaries. But we’ll move to 256 MB for 1.5.7 in the near future I suppose.

[george1421]

@Sebastian-Roth Additional testing with 257MB == fail. I figured 100MB and fog’s default was 127MB, so I went 256MB with a 275MB ram drive and success.

@Junkhacker Thank you for catching that. I fixed the func.sh script and reran deployment with still a failure (to the same laptop). So after lunch I’ll take a different computer and deploy to it just to rule out this laptop hardware as a fault domain.

[Junkhacker]

@george1421 when it fails to work for you, do you see any unexpected behavior in the imaging process?

[george1421]

@Junkhacker In the imaging process it self no, when the drivers go to copy over it says no room left on device or something like that. But that is only a file copy. I’m suspecting the disk format is damaged by then because of the partclone thing. I’m far from done testing on this. If new hardware give the same results then I’ll go back and create the inits using 0.2.89 (or whatever was original) to ensure I don’t have something else breaking the imaging deployment.

[Junkhacker]

@george1421 and this image deploys properly with the standard inits with 0.2.89? this just seems so bizarre to me

[george1421]

Same results with a Dell OptiPlex 9010 (unable to boot, disk read error) So I’ll rebuild the inits with the older version of partclone to try to get back to a good place.

[george1421]

Well this is a bit disappointing, but rebuilding the inits with only changing partclone back to 0.2.89 resulted in a successful deployment of my Win7 reference image. So it looks at least initially that the newer 0.3.x version is having a problem deploying images created with the older version of partclone.

[Junkhacker]

@george1421 could you provide me with your latest copy of the init with 0.3.12
I’d like to test it some more and see if i can get the same failures you did. the inits provide by @Sebastian-Roth here https://forums.fogproject.org/post/119056 didn’t give me the problems you’ve seen after edits to the funcs.sh

[george1421]

@Junkhacker The latest is in the link below from my google drive. I would have to rebuild the inits again with 0.3.12 (which I plan to do since I confirmed the only change was back to 0.2.89 and it worked). I’ll start the rebuild with 0.3.12 shortly.

[Junkhacker]

@george1421 i found a copy of the init_p3 file i downloaded from you yesterday before you rebuit with 2.89, so i’ll work with that

edit: nevermind, that file is from May 1 not yesterday, is that one good enough for testing?

[Quazz]

Finally got around to testing a bit.

I compiled partclone 0.3.12, removed --ignore-crc and deployed a 0.2.89 UEFI windows 10 image.

Verified I was running the correct partclone version (since it mentions it while writing the data) and monitored for any trouble

Everything completed successfully and the pc booted normally.

edit: I should additionally mention I haven’t touched ramdisk size or anything.

[george1421]

@Quazz Would you mind testing with my init? https://drive.google.com/open?id=1L3CxtRXn4cwLksu-41OcGyZ_yd5qlK1h

There is something I don’t yet understand.

[Junkhacker]

@george1421 just looking at the partclone binary file sizes in the init from you and the one from @Sebastian-Roth the sizes are all different. I’m curious as to the differences in the config files used to compile the different versions. yours are smaller.

[Quazz]

@george1421 Deploying now, will report tomorrow.

[george1421]

@Junkhacker said in The future of partclone and therefore FOG as it is:

the sizes are all different

Are they both from 0.3.12? As to the config file, I did not change anything. I let buildroot pick the configuration (same as with 0.2.89)

In the buildroot package the partclone.mk file the only thing I changed was the version number and the path to get the file from. Otherwise it has the same compile time switches. Now that may be an issue where I need to modify a compile time switch to include legacy support ??

################################################################################
#
# partclone
#
################################################################################

PARTCLONE_VERSION = 0.3.12
PARTCLONE_SOURCE = partclone-$(PARTCLONE_VERSION).tar.gz
PARTCLONE_SITE = http://partclone.nchc.org.tw/download/testing
PARTCLONE_INSTALL_STAGING = YES
PARTCLONE_AUTORECONF = YES
PARTCLONE_DEPENDENCIES += attr e2fsprogs libgcrypt lzo xz zlib xfsprogs ncurses host-pkgconf
PARTCLONE_CONF_OPTS = --enable-static --enable-xfs --enable-btrfs --enable-ntfs --enable-extfs --enable-fat --enable-hfsp --enable-ncursesw

define PARTCLONE_LINK_LIBRARIES_TOOL
        ln -f -s $(BUILD_DIR)/xfsprogs-*/include/xfs $(STAGING_DIR)/usr/include/
        ln -f -s $(BUILD_DIR)/xfsprogs-*/libxfs/.libs/libxfs.* $(STAGING_DIR)/usr/lib/
        ln -f -s $(@D)/fail-mbr/fail-mbr.bin $(@D)/fail-mbr/fail-mbr.bin.orig
endef

PARTCLONE_POST_PATCH_HOOKS += PARTCLONE_LINK_LIBRARIES_TOOL

$(eval $(autotools-package))

[Quazz]

@george1421 Did you remove the partclone patch file?

[george1421]

@Quazz Yes, also I attached the changes I made to the Config.in and partclone.mk early in this thread.

So what I’m after at the moment is to build a truth table. I’m saying that 0.3.12 doesn’t deploy the older image files correctly, Junkhacker is saying with my inits it does work. I need a few more people to test to confirm one way or the other. If my inits work on everyone else’s environment than mine, I need to dig into why. Its not to say one is right or one is wrong, its to understand why. Because if I’m the odd one with issues, there will be at least a handful of others with the same issue. So its good we have problems like this so we can understand before the update hits everyone’s FOG server.

[Quazz]

@george1421 Of course, just trying to figure out if there’s any differences in the inits themselves that might cause a disrepancy.

I’ll let you know if it deploys correctly on my test system tomorrow.

Do you have a funky partition layout perhaps? I’m assuming fairly vanilla, but you never know.