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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
