Custom init.gz
-
There’s quite a few modifications from the 2011.08 package that FOG 0.33b is built on.
First things first, if you’re going to try updating it, make sure you have a debian system (vm or not) to build partclone on.
To build partclone I use:
Download the partclone you want. I’m using partclone_0.2.58.orig.tar.gz
Extract the file:
[code]tar -xzf partclone_0.2.58.orig.tar.gz[/code]Prep the system.
[code]echo “deb http://free.nchc.org.tw/drbl-core drbl dev stable testing unstable” >> /etc/apt/sources.list
echo “deb-src http://free.nchc.org.tw/drbl-core drbl dev stable testing unstable” >> /etc/apt/sources.list
apt-get update
apt-get build-dep partclone
cd partclone-0.2.58/[/code]Begin the Makefile creation: If you arch is already i386/i686 this will work.
[code]./configure --enable-static --enable-xfs --enable-btrfs --enable-ntfs --enable-extfs --enable-fat --enable-hfsp --enable-static --enable-ncursesw[/code]I don’t know what kinds of problems you’ll run into, so I’m going to just assume for now that you’re on i386 debian.
Build the binaries:
[code]make[/code]Once complete, change to the src directory of partclone.
[code]cd src[/code]Now copy the partclone files to your buildroot fog folder: (I think it something like below)
[code]for i inls|grep ^partclone\\\.|grep -v \\\.c$|grep -v \\\.h$|grep -v \\\.o$; do cp $i ~/buildroot-2013.08.1/package/fog/partclone/; done[/code]Your partclone binaries should be ready for use on the init.gz system now.
-
Eventually I’ll update the trunk/src/buildroot to contain the needed elements for the buildroot portions of the package, to include the Config.in file to make things work properly.
For now, it’s just a hoopla of a lot of work.
-
Thanks tom going to give this a go :rolleyes:
-
So,
In trying to get partclone working, I’ve noticed a couple of things.
First,
I forgot all about my old sector based partition creation to actually recreate /dev/sda2 during upload process. The only problem I forsee with using sector based partition creation is 4k disks. I can probably figure out a method to get the sector autonomously in the future so this wouldn’t necessarily be a problem anymore, but for now I’m back to using that.
After the partition is resized, it needs (I think) to be fixed.
Something like:
[code]ntfsfix -b -d ${part}[/code]Of course you need the partition recreated and existing for this to work, but that should be trivial.
-
Figured out a couple of things.
The display of partclone wasn’t working because it was counting all output types as errors even when it wasn’t an error (in fog script it redirects errors to status.fog.)
Removing the redirects seems to allow display to work.
The next problem to overcome, after upload is complete, is download of resizeable images. I think this issue, as described earlier, was due to the sector/kB associations. First, ntfsprogs DOES NOT like 100% as a layout. -1s seems to work for the end point, but I prefer to use actual size of the disk. The method to this approach, assuming Windows 7 always uses the same information for the 1st partition, is to, rather than using kB as the startpoint, is to use B for the start point. Sectors will work as well, 206847 is the end sector of the first partition. However, the current method used kB. So the start kB of the second partition was/is always 105906kB, which for all purposes is the same end kB of the first partition. I was able to create the second partition properly by using the diskSize variable, slightly modified (added grep -v “Flags”) as the end point with kB and the start point as 105906176B.
Hope this helps out. Partclone seems to be working on the upload side, now just waiting to play with download. Hopefully I’ll be able to post something soon.
-
Well,
I’ve now tested upload of ext partclone, my Debian box, and that seems to have taken well. Now to deploy the same methodology for ntfs test. I’ve actually got a real system to test this on, so I’m going to test on both. The real system will require generalized sysprep as it’s, obviously, different than my VM, but all and all, I will keep all posted.
-
It seems the upload process worked, but the deploy did not work properly. I think this is because the win7.mbr in use has something wrong with it and can’t get to the proper winload, or I’m a total idiot. However, I’m going to do the same test once again, but with a sysprepped system rather than just a generic test. As an aside to this all, it appears the multipart images nonsysprepped is working once again now that I’m using partclone. Maybe I’m overthinking it, but essentially we’re back to using a cloning utility that works in much the same way we’re all used to.
-
All,
I think I’ve tweaked enough with the init.gz. Still in initial testing, but I think I’ve got it down enough that it was safe for me to update the src/buildroot files on the trunk of svn. We’re now at r1004 because of this. Now once I’m complete with testing the init.gz I’ll update svn with my latest and greatest one. It’s built around 3.12.1 headers so I may have to make a go at updating the kernel that we can download.
Compression,
I’m going to move mine away from gzip as it’s, to me , a rather large init.gz file if only gzipped. I’m compressing it with
[code]lzma -z -9 -e < rootfs.ext2 > init.gz[/code]
Thank you Fernando for giving me the insight for this compression medium.as it makes it from ~10-12 MB down to ~5-6 MB. This means less time waiting for it to load.
I don’t mind the kernel being larger as that is to be expected due to it containing all the drivers for the systems to be imaged, but I think a smaller loading rootfs is a necessary thing.
-
I’ve added a few tools to this. sed, rsync, librsync, resize2fs, gawk, and a few others that I can’t remember off the top of my head.
The lzma compression is still used, and the init.gz size is now around 7.5 MB. I hope that’s okay with everyone.
This has been really fun, if not frustrating at times, to play with. I haven’t figured out a way to send the output of Partclone to the screen and only send errors to /tmp/status.fog. I also haven’t, quite yet, figured out how to enable the progress bar on the Web GUI, but that can be for later, or never if it comes down to it. Having the screen tell is is good enough for me, though it wouldn’t hurt to know the progress information from time to time.
I have saved quite a lot of loading time on the kernel though. I’ve figured out a method (though the configuration file isn’t updated with this new method quite yet) to get the kernel size down to just shy of 6MB. This means our total load out size is only around 14 MB versus the old 0.33 sizes of around 12-13MB for the kernel and another 12 MB for the init.gz. 14 vs. 24, you be the judge.
-
Any chance we could get a link to your compiled init.gz?
-
[url]https://mastacontrola.com/fogboot/images/init.xz[/url]
Forewarning though, it’s 64 bit, so you’ll likely need a 64 bit kernel.
-
And for those looking to avoid compiling it, and need a 32 bits init.gz , I made one: [url]https://gilouweb.com/bordel/init_fog_i686.xz[/url] based on buildroot of r1284.
-
THANK YOU GILOU!!!
