Brendan: On Mon, Apr 4, 2011 at 4:18 PM, Brendan Simon <[email protected]> wrote: > > I've seen other distros also use the kernel with uclibc initramfs, then > switch/mount rootfs using glibc. It obviously works but it makes me feel > uneasy. I'd feel more comfortable if the same libraries were in initramfs > and main rootfs. Indeed it may be that the external fs does not even have > libc and other necessary boot files. They could stay as part of the > initramfs and the external fs could have everything else. Yes ??
The problem I see with this is that compared with uClibc, glibc is HUGE. I just can't see using glibc as part of an initramfs. The risks of using uClibc in one place but glibc in the other are completely manageable; the initramfs has much more limited functionality, and doesn't need to chance much, so testing to a high degree of confidence it before deployment is realistic. Even on the lowest-end embedded systems, having an initramfs unexpectedly (to some) makes a lot of sense. It lets me get away with a brain-dead bootloader, and defer the mkfs.jffs2, ubifs, etc. etc. etc. to the initramfs. Then I pivot to the final root filesystem. And if for some reason the root filesystem isn't there, I get the functionality of the initramfs to help me recover. In particular, a suitable initramfs lets me wget raw NAND images for the target platform, and also have a small web server for diagnosing hardware and other problems. I can't do that with a bootloader unless the bootloader has TCP/IP. And any bootloader that has TCP/IP is too sophisticated for me to feel comfortable using it. :) I'm talking about a target system that has 64MB of NAND, total. That's all the storage there is. I'll gladly eat 4MB of that for a kernel and initramfs that gives me in return a nearly un-brickable system. Any larger than that, however, and I really start to feel the pinch. And before you all tell me to just get a larger system, I'll just say that if you can do real work in 64MB of flash, a whooooooole lot of interesting possibilities open up--- and I can prove it to you. Emdebian is making that possible for me. But that's a topic for another email. :) b.g. -- Bill Gatliff [email protected] -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
