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
> ways that I've tried, probably another exists as well. None involve the mess
> 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
> 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
> every file in the directory passed, including mode params, symlink
> whether it's a device or not (and if is, how to re-create it), etc.. This
> 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
> as the old MS-DOS ramdisks some utilities diskettes would load up and dump
> > 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
> figure it out. I even fixed the embedded ramdisk to handle linking in
> files with conflicting ABIs (encountered when we built netboot images for SGI
> because at the time, we built O2's kernels with -mabi=o64 which uses some
> tricks to stuff 64bit code into a 32bit file; ld hated that). Of course, I
> 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.
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.
System Lead Technical Engineer
T 678-990-1550 x238