Imaging using partclone instead of partimage
-
Tom,
How did you add it to init.gz file, would you mind to tell me how to do it?
Thanks,
Hongyun -
Look up on my webpage.
[url]https://mastacontrola.com[/url]
It’ll give some info, but if it’s easier just update your fog to the current revision.
The quick and dirty method.
Download the patch Gilou provides to your fog server in the /tftpboot/fog/images directory.
Then open a terminal to your fog server.
[code]cd /tftpboot/fog/images; mkdir tmp; gunzip init.gz; mount -o loop init tmp[/code]
This is all one line. It cd’s to the images directory, creates a tmp directory. Extracts the init file and mounts it to the tmp directory you created.
Then run
[code]patch -p1 tmp/bin/fog < ./partclone.diff.txt; umount tmp; gzip -9 init; rm -rf tmp[/code]This patches the fog script, unmounts the tmp directory, gzips the file back to init.gz and removes the tmp directory.
Hope this helps.
-
Hi Tom,
Thank you so much for your reply. I will give it a try, hope it will fix my problem.
Hongyun
-
@[URL=‘http://fogproject.org/forum/members/gilou.3221/’][B]Gilou[/B][/URL] @Tom Great news getting partclone included into fog. The Both of you keep up the good work. THANK U
-
Hi Tom,
I tried it with a clean install of FOG 0.33, but it couldn’t upload properly, only 32256 byte got uploaded to the server. When I tried to upload with debug mode, I got the following error messages:
mv: Can’t rename ‘/images/7071bc7b70bd/d1p1.img.000’: No such file or directory
Do you know what may be the problem?
Thanks,
Hongyun -
The only thought that sticks out to me is the idea that it’s looking for the file d1p1.img.000 and I believe the system only makes the files d1p1.img
Just a thought, though I don’t think that’s fully the fix yet.
I’ll take a look into the bowels of the fog script for when it moves the file.
-
Found the issue.
So I’m correct.
The script makes the files d1p1.img
Then when it tries to move the files it runs:
mv ${imgpart}.000 ${imgpart}
I Imagine this is backwards as the .000 file doesn’t exist at all during this.
If you’re unafraid to play a little in the bowels, you can fix this.
Perform the steps in this as before.
Use your editor for editing the file
Look for the lines that say mv ${imgpart}.000 ${imgpart} and switch it so it reads: mv ${imgpart} ${imgpart}.000
That should help you out.
-
What about this line: mv ${imgpart}.000 ${imgpart} 2>/dev/null
change it as well? -
[quote=“Hongyun, post: 20096, member: 1117”]What about this line: mv ${imgpart}.000 ${imgpart} 2>/dev/null
change it as well?[/quote]Yes, to my knowledge, there’s two lines that say the same thing. You’ll need to modify both.
-
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]
