Imaging using partclone instead of partimage

[Hongyun]

Hi Tom,

Thank you so much for your reply. I will give it a try, hope it will fix my problem.

Hongyun

[steve]

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

[Hongyun]

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

[Tom Elliott]

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.

[Tom Elliott]

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.

[Hongyun]

What about this line: mv ${imgpart}.000 ${imgpart} 2>/dev/null
change it as well?

[Tom Elliott]

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

[Hongyun]

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/

[Hongyun]

One more question, do I need to have partclone installed on FOG server?

[Tom Elliott]

No. Partclone becomes a part of the init.gz file.

[Hongyun]

[INDENT=1]So you mean the [FONT=Consolas]partclone.diff.txt file already included everything I need to use partclone?[/FONT][/INDENT]

[Hongyun]

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

[Tom Elliott]

That’s kind of the point behind partclone vs. partimage. That’s really the main difference between clonezilla and fog.

[Tom Elliott]

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.

[Gilou]

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…

[Tom Elliott]

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.

[Hongyun]

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

[Tom Elliott]

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]

[Hongyun]

Hi Tom,

Can I use this script under version 0.32? Honestly, I like 0.32 better than 0.33b

Thanks,
Hongyun

[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]