On Fri, Aug 03, 2007 at 12:19:36AM +0300, Andrei Popescu wrote: > On Thu, Aug 02, 2007 at 10:35:01AM -0700, Andrew Sackville-West wrote: > > So what is the significance of initrd size? (other than the obvious > > filling up /boot issue). Is it really a problem to have "most" modules > > in there? I can think of some situations where it might be nice to > > have most of them -- mobo fails catastrophically and you want to be > > able to just boot, for example. > > This is about it. Debian wants to provide an initrd that works even ehn > changing hardware. Same reason for installing all -xorg-video-foo > packages. >
However, don't all those modules in the initrd end up staying in the kernel anyway, or do they get unloaded during boot? If they stay, and 'most' modules get added, how is that different than having a huge monolithic kernel? It may not matter on a box with huge memory, but I have mostly small-memory boxes. As for xorg-video-foo, that's why I don't install the xorg metapackage. I choose from its dependencies what I need. /rant There's a growing kitchen-sink approach in Debian (perhaps all of Linux, I don't know). There's the kernel/initrd size, there's the variable device name problems, to name two. It suggests to me that there's a missing piece of infrastructure. Perhaps the installer system should create a hardware inventory file that initrdtools (or whatever the nom de jure) can access to generate a tailord initrd, that apt can consult for what drivers to download, etc. The installer rescue mode could offer a tool to regenerate the inventory file for times when one changes hardware. /end rant Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
