My desired use of udpcast involves PXE booting machines. I am able to successfully PXE boot, and I am also able to successfully image the machines. However, I would like to further automate the process, which involves implementing a post-setup script.
The easy way for me to achieve this (I have the script written) is to simply use the Cast-o-Matic tool (which I do like). However, I have noticed a discrepancy in the output of the initrd file from the Cast-o-Matic versus the "ready prepared" initrd image available for download.
When using the ready made initrd, I am able to successfully mount the hard drive. Mounting the hard drive is required so that my post setup script can then make the necessary changes to key files. However, when using the Cast-o-Matic generated initrd, I am unable to mount the hard drive. I am given a mount command failed error. My desired behavior is that I would also be able to mount the hard drive with this initrd.
What I would like to know is if the discrepancy can be fixed (only assuming that there is one--maybe mismatched versions?--I don't know), or if there is a way for me to make the "ready prepared" initrd work for my needs? To do this, I would need to inject two files. I realize that most initrd files are simply compressed with cpio and then gzipped. I see that this seems to be the case with the Cast-o-Matic initrds. However, I do not seem to be able to successfully decompress/extract the ready made one using the same technique.
I apologize for my long windedness. The target operating system is Gentoo Linux. If any more information is required, please let me know and I will be more than pleased to provide it ASAP.
Thanks,
Greg
------------------------------ Greg Hasseler SUNYIT Computer Science Department
... Linux und seine Programme sind damit so etwas wie ein real existierender Sozialismus der besseren Art ... -- Christian Seel in der Berliner Morgenpost v. 9.3.1997
After further investigation, it appears that the "ready made" initrd image is compressed with lzma and cpio. In order to extract it, one must rename it to initrd.lzma or else lzma will complain.
$lzma d initrd.lzma initrd
will un"lzma" it, leaving you with a cpio compressed archive. You can further decompress it into the file hierarchy with
$cpio -i < initrd
To rebuild the image (I have rebuilt it, but not yet tested--that will happen tomorrow), one should be able to do the following: $find ./ | cpio -H newc -o > initrd $lzma e initrd initrd.lzma $mv initrd.lzma initrd
and they will <should> have a factory like initrd image.
If someone does not have lzma, it is freely available. I found that the README (http://www.zelow.no/floppyfw/download/Development/Patches/lzmastuff/README) was most helpful, as the traditional ./configure; make; make install did not quite cut it.
I will update tomorrow as to whether or not this procedure was successful.
------------------------------ Greg Hasseler SUNYIT Computer Science Department
I'm telling you that the kernel is stable not because it's a kernel, but because I refuse to listen to arguments like this. -- Linus Torvalds
I did not test rebuilding the image with lzma, although I am sure it too would also work.
I did, however, rebuild the image with cpio and gzip. To do so, one should first navigate into their image root. Then simply run the following string of commands: $find . -print | cpio -H newc -o | gzip -9 -c > /tmp/initrd
A working initrd will now be located in /tmp.
I am pleased to report that this means I now have a fully working multicast based imaging system working which I can use to image machines remotely.
Thanks go to Michael D. Setzer II who gave me some help off list.
------------------------------ Greg Hasseler SUNYIT Computer Science Department
Ooh, mommy, mommy, what I have now doesn't work in this extremely unlikely circumstance, so I'll just throw it away and write something completely new. -- Linus Torvalds
-
Greg Hasseler