The future of partclone and therefore FOG as it is


  • Developer

    Sorry if this sounds a bit daunting. Not meant to. I just stumbled upon a changelog message that I would like to discuss with all the FOG users out there:

    From https://clonezilla.org/downloads/stable/changelog.php (Clonezilla and Partclone are kind of partner projects and as I simply couldn’t find release notes on Partclone itself I need to reference this one!):

    Clonezilla live 2.5.3-3

    Partclone was updated to 0.3.8. //NOTE// New image format is used in this release. It is different from the one saved by Partclone 0.2.x.

    Within FOG we currently use version 0.2.89 which seems to be the latest 0.2.x release. That’s fine from my point of view even though it’s a bit dated. Updating our whole FOS base system to the latest Buildroot version I ran into a compiling error with Partclone as it still uses ustat function which is deprecated in up-to-date glibc version (2.28). So we seem to get to a point where we need to patch Partclone 0.2.89 to be able to further use it within FOG or we need to come up with a way on how to move to version 0.3.x…

    One would think that newer versions of Partclone are able to read the old image format but there are hints on the web that it can cause trouble: https://sourceforge.net/p/clonezilla/discussion/Clonezilla_live/thread/34023334/

    Keep in mind that Partclone versions 0.3.x still are proposed as unstable on the official website. On the other hand it’s in use with current Clonezilla releases since almost two years!

    If you can’t follow all the tech details above, don’t worry about it too much. The basic message is Partclone seems to move on using a different image format not compatible with what we used to have! What that essentially means is that if we also move forward and add Partclone 0.3.x to FOG that would break all existing images I reckon (not tested yet).

    @Quazz Would you find the time to compile FOS builds with Partclone 0.3.x for testing?


  • Developer

    @george1421 No problem. I was just hoping to make progress on this. I found this https://github.com/stevenshiau/clonezilla/issues/31 and wondered if it was related since it was from when clonezilla updated their partclone version.


  • Moderator

    @Junkhacker Sorry I haven’t had time between traveling and project deadlines most everything else has got put on back burner. Both you and Quazz say they are working fine. I’m not sure why my images are not. I know at least one I tested with was created with 1.5.4 the rest may be 1.4.4, but I’d have to look at the image creation date to be sure. Everything looks like it deploys correctly with partclone, just when I try to mount the c: partition and copy the drivers over it says no space left on the device.


  • Developer

    @george1421 have you had a chance to do any further testing? did you build 32bit versions and have you tried using them?


  • Developer

    @george1421 for reference: I tested with your inits using both bios and uefi configurations using a physical computer and a vmware VM. I had no problems with booting the systems after imaging. all images were compressed with zstd (not that that should make a difference, but putting it out there) and the images ranged from windows 7 to windows 10. imaging done while in uefi mode seemed significantly slower. i don’t know if that’s normal, since i don’t normally use that.


  • Moderator

    @Quazz Thank you for checking, I guess I need to better understand what is going wrong with my deployments. They work perfectly with the 0.2.89 partclone even when I build the inits.


  • Moderator

    @george1421 Deployed successfully with your init on my end, W10 Pro UEFI.


  • Developer

    @george1421 i just tested a deploy with the init i downloaded from your google drive link today. it deployed and booted (though i did get the UUID error, so you need to update your files to the latest build, not that it’s related to the partclone issues)

    I’m at kind of a loss as to what’s wrong at this point


  • Moderator

    @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.


  • Moderator

    @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.


  • Moderator

    @george1421 Did you remove the partclone patch file?


  • Moderator

    @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))
    
    

  • Moderator

    @george1421 Deploying now, will report tomorrow.


  • Developer

    @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.


  • Moderator

    @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.


  • Moderator

    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.


  • Developer

    @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?


  • Moderator

    @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.


  • Developer

    @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


  • Moderator

    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.


Log in to reply
 

333
Online

5.8k
Users

13.0k
Topics

123.1k
Posts