Imaging using partclone instead of partimage
-
Now I get the same error without 000
mv: Can’t rename ‘/images/7071bc7b70bd/d1p1.img.000’: No such file or directory
But I found the mac address folder under /images/dev/
-
One more question, do I need to have partclone installed on FOG server?
-
No. Partclone becomes a part of the init.gz file.
-
[INDENT=1]So you mean the [FONT=Consolas]partclone.diff.txt file already included everything I need to use partclone?[/FONT][/INDENT]
-
Hi Tom,
Have you ever used clonezilla? someone recommends that for me, but if I could make FOG work with ext4, I really don’t want to switch to something else.
Hongyun -
That’s kind of the point behind partclone vs. partimage. That’s really the main difference between clonezilla and fog.
-
I’m sorry that this is taking so long. I’ve got the code base, I think, setup and ready to run, but I keep getting a funny error. I can’t build partclone natively within buildroot, but I’ve successfully built the binaries on my 64 bit system. I just created a 32 bit VM to see if I could create the binaries on that and have them run properly, though I don’t know how well that will actually work.
It’s a work in progress, that’s for sure.
-
There is a bug if you use my patch, I missed a spot where partimage is still used. I need to work a bit more on that, and we need either a way to tell “use partclone or partimage” (say, an image type), or a way to effectively migrate from the partimage+gz format to partclone + gz. But that requires a better roadmap thinking than just changing a few lines… And the fog sh script is also not consistent, a lot of things should be refactored in it to allow for an easier development on it…
As for “how I did it”, well, I’m a bit familiar with partclone (I use it for MacMinis), and the documentation is rather extensive. The catch might be with pigz / gzip, as pigz doesn’t return properly when reading stdin, but gzip is available in the buildroot environment, so there it goes…
I have huge issues building buildroot, 32 bits or 64 bits, vanilla or the one descried on SVN, or as a matter of fact, even the one listed on your website (Tom)… And I won’t have immediate time to work on that, but I’ll look into it… My goal is to work on a 64 bits buildroot + kernel, to be able to exploit the 16 GB RAM monsters properly…
-
I’m almost prepared for releasing a working model of my init.gz (non 64bit) that is now operating with creating the image. I’m just doing some testing to see if I can get the progress information to display. However, it works across the board, extfs or ntfs, and theoretically multicast.
-
Thank you, Gilou and Tom! I wish I knew more about programming, and really hope I can do something to help, but it looks like my only hope will be waiting for you guys to come up with a working solution.
Hongyun
-
Attached, find my patch for the fog script to use partclone instead of partimage.
Hopefully it helps.
Copy it to your fog server, preferably in /tftpboot/fog/images
Then:
Run these commands to edit your init.gz file. (MAKE SURE YOU’RE ON AS ROOT YOU NEED TO MOUNT THE IMAGE)
[code]cd /tftpboot/fog/images
mkdir tmp
gunzip init.gz
mount -o loop init tmp
patch -p1 tmp/bin/fog < fog.diff.txt
umount tmp
rm -rf tmp
gzip -9 init[/code][url=“/_imported_xf_attachments/0/445_fog.diff.txt?:”]fog.diff.txt[/url]
-
Hi Tom,
Can I use this script under version 0.32? Honestly, I like 0.32 better than 0.33b
Thanks,
Hongyun -
Here is the result when I applied the patch to 0.32, and attached is the fog.rej file.
patch -p1 tmp/bin/fog < ./fog.diff.txt
patching file tmp/bin/fog
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 364.
Hunk #3 FAILED at 376.
Hunk #4 FAILED at 387.
Hunk #5 FAILED at 400.
Hunk #6 FAILED at 421.
Hunk #7 FAILED at 493.
Hunk #8 FAILED at 581.
Hunk #9 FAILED at 933.
Hunk #10 FAILED at 1036.
Hunk #11 FAILED at 1108.
11 out of 11 hunks FAILED – saving rejects to file tmp/bin/fog.rej[url=“/_imported_xf_attachments/0/446_fog.rej.txt?:”]fog.rej.txt[/url]
-
I’ll take a look at the fog 0.32 fog script and make the changes to it. The diff I gave you before is for 0.33
-
When I applied it to 0.33b here is the result:
[B][root@foggy ~]# patch -p1 tmp/bin/fog < fog.diff.txt [/B]
patching file tmp/bin/fog
Hunk #1 FAILED at 1.
1 out of 11 hunks FAILED – saving rejects to file tmp/bin/fog.rej
[B][root@foggy ~]# cat tmp/bin/fog.rej[/B]
— /dev/null
+++ opt/buildroot-2013.08.1/package/fog/scripts/bin/fog2013-11-25 11:55:23.820674638 -0500
@@ -1,11 +1,11 @@
#!/bin/sh-PIGZ_COMP=“-3”;
+PIGZ_COMP=“-9”;
RUN_CHKDSK=“”;
HOSTNAME_EARLY=“0”;-OS_ID_WIN7 = “5”;
-OS_ID_WIN8 = “6”;
+OS_ID_WIN7=“5”;
+OS_ID_WIN8=“6”;. /usr/share/fog/lib/funcs.sh
-
[quote=“Tom Elliott, post: 20194, member: 7271”]I’ll take a look at the fog 0.32 fog script and make the changes to it. The diff I gave you before is for 0.33[/quote]
If you could make it work on 0.32, it would be so wonderful! Thank you very much!
-
If you’re using the 0.32 init.gz file, it doesn’t come precompiled with the partclone files.
Have you built your own init.gz file with partclone? If so, then I can do the script, if not, there’s not a lot that I can do to help.
I could build you a custom init.gz but I don’t know how much you would enjoy that as I don’t have the capacity (at the moment) to test this. I’d basically be building in the dark.
-
Thanks for trying to help me. I can try the 0.33b version again. But do you know why when I patch 0.33b there is one error, is it critical? Please see my above post.
-
Also, I will try to give more insight on how to be able to resize ext[34] partition… There are no reason not to do the same we do for NTFS partition using resize2fs, assuming it’s inside the init.gz, haven’t even checked for it yet
-
Gilou,
It does not currently contain resize2fs. I’m building another version of init.gz right now with resize2fs enabled. Hopefully this will help you, and all of us out.
Thank you,
