I am not entirely sold on this initramfs. I have a question: >From what I have read so far, it seems that this is meant as a stepping stone to booting/mounting the real system. Has anyone used this where the initramfs is the filesystem and the endpoint in the boot process? On Thu, 2006-01-19 at 23:11 -0500, Kumba wrote: > Marc Karasek wrote: > > Is the process still the same. In that you create a ramdisk image that > > can be mounted, just using initramfs instead? > > It's actually simpler than that, insofar as creating the archive. There are two > ways that I've tried, probably another exists as well. None involve the mess of > creating a mountable image. > > 1) In the scripts/ dir in the kernel tree, there's a script, > gen_initramfs_list.sh. chmod +x it, and pass to it (as its only argument) an > absolute path pointing to a ready-to-go root file system that will be loaded by > the machine that boots the subsequently produced kernel. The output of > gen_initramfs_list should be directed to a text file -- it's a text listing of > every file in the directory passed, including mode params, symlink destination, > whether it's a device or not (and if is, how to re-create it), etc.. This text > file can then be passed to the initramfs option in menuconfig, and the kernel > pulls in the files and rolls them into its initramfs cpio archive it builds. > > 2) cpio up a ready-to-go root file system and pass that to the same initramfs > option in menuconfig. > > > Provided the root filesystem is setup properly, just don't pass root= on the > command line, and the kernel takes over loading and running the main startup > script (it's either /init or /linuxrc that it looks for, one of the two). > > > > We will be moving to 2.6.x for our next chip and currently have scripts > > to create a ramdisk with busybox embedded. If these cannot be used > > anymore, I may want to take over the patches for ramdisk from you and > > maintain them. Otherwise our sdk would have to change and the tools, > > etc. and that is not a desireable option...... > > This isn't that big of a change actually. As described above, it's decidedly > simpler, as you don't have to rely on any file system (it's basically the same > as the old MS-DOS ramdisks some utilities diskettes would load up and dump tools > into) > > > > IMO: Fixing something that was not broken is not a very good idea. :-) > > I thought the same initially, but in truth, initramfs is far simpler, once you > figure it out. I even fixed the embedded ramdisk to handle linking in objects > files with conflicting ABIs (encountered when we built netboot images for SGI O2 > because at the time, we built O2's kernels with -mabi=o64 which uses some mean > tricks to stuff 64bit code into a 32bit file; ld hated that). Of course, I did > this fix about an hour after Ralf removed the ramdisk code from 2.6.10 CVS. > Talk about a sense of timing. > > Especially once we found out initramfs loaded flawlessly on Origin, it was > essentially deemed to become the replacement. > > > > --Kumba > -- Any content within this email is provided “AS IS” for informational purposes only. No contract will be formed between the parties by virtue of this email. /*********************** Marc Karasek System Lead Technical Engineer iVivity Inc. T 678-990-1550 x238 F 678-990-1551 ***********************/
