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