Re: prepare 2.6.13
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.
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.
> > 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.
Regards,
Erik
Reply to: