Custom init.gz
-
It’s still in it’s prelimary, but I think I’ve finally created a modernized init.gz file that works. The only thing I’ve not tinkered with so far is lessening the packages available in it so we don’t have a 17MB init.gz file, though I suppose ultimately that doesn’t matter. Bash is included as well just as a safe measure from my reading a different post with dd and gzip relying upon bash existing.
Once I’ve tested the uploads, if it’s successful, I’ll tar the exact file up with DL’s and host it on my personal site as I don’t think this forum will store a file that large. If it can be here, I’ll put it here as well.
Thanks,
-
Alright, I spoke a little too soon. That doesn’t mean I haven’t made success. I won’t post the file here, just the link as when compressed with all dl files needed it’s about 300MB which I’m certain is too large for this forum.
I’ll get the upload working on both partitions, as soon as I figure out why it’s not exactly.
-
So here’s the buildroot that I use:
[url]https://mastacontrola.com/fogboot/buildroot-2013.08-rc2_FOG.tar.bz2[/url]
If you’re to wget the file, as always, use:
wget --no-check-certificate [url]http://mastacontrola.com/fogboot/buildroot-2013.08-rc2_FOG.tar.bz2[/url]It’s rather large, I know, but it’s preconfigured with everything we need including the buildroot .config and it builds on Centos 6.4 with no issues. I haven’t built it on other OS’s. You will need the normal development information for building this thing, but a couple things that I needed to add were glibc-static and perl-ExtUtils-ParseXS and all dependencies needed there.
The file is about 300MB in size, and it will take a while to download as I’m only sporting 5MB upload speeds, sorry guys, but it’s better than nothing right?
Maybe others can look at what I’m doing wrong to find out the partitioning issues?
You do the normal building with:
make ARCH=i386
If you want to edit the packages to install, that’s up to you, but you will need to download it. When you setup for this you do the normal:
make ARCH=i386 menuconfigHopefully people find this useful.
Also, my buildroot actually builds partclone and partimage natively so I’ve modified the fog package and rather than using customize within the package directory, I just placed the FOG components in the package directory.
Thanks guys,
-
Sorry,
There were a few components missing from this. I didn’t build my own busybox configuration or use the one that FOG graciously provides for us. I’m trying to limit size a little, so hopefully after this run, fdisk and all the bobs and bits from the filesystem for partclone is all available. The file will still be named the same once uploaded.
Thanks all,
-
So I’ve, seemingly, made progress on getting the upload to work. It seems that my builds just ran thru way too quickly for pigz to keep up with writing to the NFS. The only issue is that my VM is extremely slow on the upload and download process. It only pushes speeds as high as 758 MiB/min and as slow as 100 MiB/min, but this sounds likely to just be a driver issue in my kernel.
I found that by adding a sleep command to the partimage save of the 2 partition section seems to work. I’m tinkering now with stepping up the intervals for the sleep timer to find out which one works best, at least for my setup. I don’t know if it’s simply because I am making an image off of a VM or if this would be a common issue seen by all. Though I don’t know that many people are using this particular setup.
My init.gz size is 9.7MB versus the 12-13 MB of the original one. I don’t know what I changed, but it’s probably the busybox config more than anything.
I’m taking down the tarball for now as it will probably be a couple of days until I get the sleep timer just right. Hopefully this is okay for everybody.
-
Found out that, the problem I’m seeing with the image upload process (as much as I can tell) is halting (resizable) because it’s referencing as kB. This in and of itself isn’t necessarily wrong, but when I try to manual create the disk partitions using parted, it tells me that 105905 (one byte behind part2start) is not valid for the partition. If I leave the end alone, it completes, but it isn’t the right size. It’s much smaller (part 1 that is) when it’s created using this particular method of parted. However, it successfully recreates the partition if I call the sectors: specifically, the sectors referenced are 206847 (partition one end) and 206848 is the start sector on the drive.
This method I can get rid of the need for the sleep commands, and all runs as expected. This is really weird to me, but it’s working as far as I can tell.
-
To add to the above,
My upload process with using Sectors works beautifully. However, the deploy process (which I have trouble with in both the original and my custom builds) does not work with single partition resizeable. However, it’s also not working with MPS, but that might be because I created the images using my custom build as that’s what I’ve been testing most frequently. I’ll find out later on. Still making progress and it’s a slow right. If you all can’t tell, I’ve not worked too much on the web interface in quite some time due to this. I will, however, try to get work done on it once I got this all figured out. In the mean time, I’ll work on tweaking the OS portion so it can be as small as possible, while still giving all of the needed elements a chance for us. I’m contemplating removing the partclone parts for now as it doesn’t build all the needed modules any what. It only creates:
partclone.restore
partclone.ntfsfixboot
partclone.info
partclone.chkimg
partclone.dd
fail-mbr.binI don’t know how to get it to build the [fstypes] of partclone executables, but I’ll work that out, hopefully in the future as well. Though we’re not using it right now anyway, so it’s not a huge thing.
-
Just a status update,
I am still having the problems with deploying, essentially, any image, but this is the same for the original init.gz file as well as mine.
It only images, during a download process, about 20%-35% then the system restarts. Sometimes the % complete is less, but generally speaking it just quits for some reason. I’m not seeing any errors pop up but that doesn’t mean that there isn’t any either.
Other than that, my init.gz is sitting around 6 MB, versus the 12-13MB of the original. So I think I’m doing well in piecing it back together. I think it’s missing a calculator function at this point though. I feeling like Dory from Finding Nemo, just keep trying, just keep trying …
It’s been a fun ride so far, if only a little frustrating, but at least I got one kink figured out. Yeah uploading single disk resizable!
-
I’m posting my buildroot file to have others play, test, figure out, as well.
Hopefully it’s all good.
[URL=‘https://mastacontrola.com/buildroot2013.08_FOG.tar.bz2’]https://mastacontrola.com/buildroot-2013.08_FOG.tar.bz2[/URL]
-
Nice work keep it up!
-
Thanks for the support.
-
Great work Tom
-
You’re welcome,
Hopefully it’s working good for you.
-
Alright, as I’m working on GUI lately, I’ve left buildroot alone for a little bit. I was finally able to build the partclone binaries on my system, but I can’t figure out how to get them built native to the buildroot process. For now, though I’ll just recreate the fogpartinfo within the fog.mk.
Though I’m sure we’ll have a need for these, eventually I’ll sit to figure this out. Remember I’m building on CentOS 6.4, and finding all the dependencies is not always that easy, I’m sorry. -
I think it’s starting to make sense, why, the init.gz file will not perform the upload task on Single Disk, Resizable. When the image is created, it does not take a snapshot of the MBR in use. This, by itself, is not the issue, but when you go to deploy the image, one of the first steps needed is to remove the partitioning schemes. This also removes the MBR, then it tries to create the new partitions, but the MBR that gets used doesn’t exist, so the system can’t see the second partition at all.
Just me two cents to help me in fixing this issue.
-
Hi
There are indeed some needed work both on the kernel and the init.gz script. However, we have to care not to break anything… As of now, I think we should have an option for 64 bits install… And perhaps add more libs & tools in it, though the latest version from SVN has already some really helpful tool. One thing that was removed, and broke compatibility was the probable removal of the “loadkeys” utility, that renders the FOG_KERNEL_KEYMAP useless.
I’m also a little bit confused about how the init.gz is generated from SVN… The doc to build a custom one is around here: [url]http://www.fogproject.org/wiki/index.php/Modifying_the_Init_Image[/url]
but I’m not sure I’ve found how to properly generate it in SVN from src/buildroot or what not… -
Gilou,
The src/buildroot files you’re seeing are only provided as an opensource tool to build your own initrd.gz (init.gz) file. When a user performs an install, the init.gz file is copied from the <folder_where_stored>/src/tftp directory which if you look in the tftp, you see the sub folders fog, kernel, images.
-
I know that, but my point is actually, how is it supposed to be used ? I didn’t look too far, but if we want to improve this, the toolchain should be documented
-
I’m attempting something dangerous I think.
I’m attempting to build a 64 bit init.gz, which of course will require a 64 bit kernel to go along with it. I’ll try to keep it posted here.
-
Well,
Good news/bad news time.
As I don’t know fully what I’m doing in creating this, I got the init.gz to actually run and operate with 64 bit capabilities. The kernel and init.gz were fully compatible. I didn’t notice anything major, except… all the libraries could not be found
