Re: prepare 2.6.13
On Tue, Aug 30, 2005 at 11:38:31PM +0200, Erik van Konijnenburg wrote:
> On Tue, Aug 30, 2005 at 03:26:29PM +0200, Sven Luther wrote:
> > On Tue, Aug 30, 2005 at 10:40:12AM +0200, Marco Amadori wrote:
>
> > > > Now, initramfs is nothing more than a file organisation which is a bit
> > > > different for the initial ramdisk, or is there more to it, and the above
> > > > code path, for which i have seen no major change recently, will still work
> > > > ?
>
> >From memory:
>
> You can feed the kernel a file system in eg cramfs format from grub or another boot
> loader, and it will be treated like initrd. If the boot loader feeds a cpio file
> to the kernel, AND it contains a file named /init, it will be treated as initramfs.
> You can also append a cpio file to the kernel, and it will be treated as initramfs.
Nice thanks. So, this stuff is feed to the kernel in much the same way the
older initrds are, it is just the later handling that is different, right ?
> The kernel treats initrd and initramfs differently: for initrd, the kernel does
> a complicated two-stage shuffle with mount, chdir, chroot and ramdisks,
> while initramfs just gets unpacked into rootfs and the kernel hand over control to
> /init. Oh, and for initrd the kernel will try to mount devfs.
>
> To summarise, to the boot loader the difference between initramfs and initrd is
> not important, but for initrd-tools or yaird the difference is more than just
> packaging with cpio or mkcramfs; you'll also need to consider what goes on
> the image.
Ok, it is just a different packaging format. and some special treatment if the
initrd is detected as initramfs.
What about the "appending an cpio file to the kernel" kind of thingy.
> > > The question is : we want to support nice things like EVMS at boot time? A
> > > tool for generating bootable initrd for evms is needed, it is targeted for
> > > etch evms support I hope.
> > >
> > > It seems that none our 3 tools supports it right now.
>
> I'll see what can be done about yaird support of EVMS.
>
> > But right now is the time to investigate those issues, and fix the tools if
> > possible, and not 6-12 month down the road, when we will be in late-freeze
> > situation or something.
>
> Agreed.
>
> > Let's maybe list all the things we want for sucha tool. My personal requisite
> > are :
> >
> > - allow as well for the creation of generic images, as well as minimal ones.
> > - allow for hand selected inclusion list as well as exclusion of modules.
> > - allow to include script as well as mklibs-manipulated binaries and
> > libraries.
>
> Hmm, I was not previously aware of mklibs. Just tested it on an unpacked yaird
> image and found zero size reduction on a sid/i386 box, presumably because none
> of the included libraries have a _pic.a file. For now I have higher hopes
> for klibc or uclibc to reduce size, but if you can show how mklibs will pay
> off, I'm listening.
Well, it is extensively used in the debian-installer, so known to work and be
worthwhile on each arch. Sure you need the _pic.a stuff installer probably,
but it is a worthy goal of using it to make the initramfs as small as
possible.
Friendly,
Sven Luther
Reply to: