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
***********************/
|