Re: Large initrd [Was: Re: booting problem (udev related?)]
On Thu, Aug 02, 2007 at 08:34:00PM -0400, Douglas Allan Tutty wrote: > 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. I may be wrong, but I think that only the needed modules are actually loaded. > As for xorg-video-foo, that's why I don't install the xorg metapackage. > I choose from its dependencies what I need. Same here > /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 True, but you have to consider the competition. If you plug a new device into a Windows machine the driver gets installed automatically or you get prompted for the drivers if Windows doesn't have them. You have to admit that this is pretty convenient functionality which has been there at least since Windows 2000 (how this is cluttering the registry and the fact that it isn't always working is a totally different topic). The big advantage on linux (and especially Debian) is that power users still have the possibility to customize the setup (like using a different mkinitrd, different options, purge unneeded packages, ...) that a Windows user doesn't have. Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: Large initrd [Was: Re: booting problem (udev related?)]
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]
Re: Large initrd [Was: Re: booting problem (udev related?)]
On Thu, Aug 02, 2007 at 06:40:52PM +0200, Florian Kulzer wrote: > On Thu, Aug 02, 2007 at 18:23:04 +0300, Andrei Popescu wrote: > > [...] > > > Yes, I know what you mean. I was using yaird to make my initrd, but it > > gave some errors on the latest upgrade (and Steve Langasek, Debian > > kernel maintainer suggested it is no longer maintained). > > Do you mean this problem? > > yaird error: unrecognised line in /proc/bus/input/devices: U: Uniq= (fatal) > > That can be fixed relatively easily, see bug #431534, followup 1. > (/usr/lib/yaird/perl/InputTab.pm is patched to simply ignore these new > lines in /proc/bus/input/devices.) Sure I could do this (actually I found another workaround, see #435560), but that's not the point. And I'm (by far) not knowledgeable enough to take over. Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: Large initrd [Was: Re: booting problem (udev related?)]
On Thu, Aug 02, 2007 at 10:35:01AM -0700, Andrew Sackville-West wrote: > same here. interesting. I'll have to play with that. You could > probably tighten it up even more by using the 'list' option and > putting a minimum-necessary list in /etc/initramfs-tools/modules. At > least that's how I read it. That's too much hacking for my taste. > 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. > Finally, I have on this (sid) system both initrd-tools and > initramfs-tools installed. The latter is brought in by the kernel > dependencies, and the former is manually installed. Who knows why or > when I did that, but is one preferred over the other? AFAIU initrd-tools are deprecated and should not be used: http://wiki.debian.org/InitrdReplacementOptions There is also a nice comparison of initramfs-tools vs. yaird, though I'm not sure how recent this is. Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: Large initrd [Was: Re: booting problem (udev related?)]
On Thu, Aug 02, 2007 at 06:23:04PM +0300, Andrei Popescu wrote: > On Wed, Aug 01, 2007 at 11:10:25PM -0600, Bob Proulx wrote: > > Miles Bader wrote: > > > Hmm, I didn't realize it analyzed the system when building the ramfs > > > contents. Maybe I could just reinstall the kernel while the new kernel > > > is running (or is there an official "hint" mechanism I could use)? > > > > Yes. Please try that. > > > > > [I thought it just included _every_ possible module on the ramfs -- > > > judging from the enormous size of the installed kernel package, it seems > > > like it!] > > > > :-) > > Yes, I know what you mean. I was using yaird to make my initrd, but it > gave some errors on the latest upgrade (and Steve Langasek, Debian > kernel maintainer suggested it is no longer maintained). So now I'm > exploring the initramfs-tools package. The first initrd was about *5 > (five)* times bigger! wow! I never noticed that. And in fact I probably wouldn't have as this system doesn't have any initrd's left from yaird. My server which was an etch/testing box for a while has a couple older initrd's that are 1.4 megs or so versus the newer ones at 5-6megs. yikes. I changed the config for including modules from > 'most' to 'dep' and I got a much smaller (but still a bit bigger then > yaird) initrd. Haven't tried to boot with it yet, though ;) same here. interesting. I'll have to play with that. You could probably tighten it up even more by using the 'list' option and putting a minimum-necessary list in /etc/initramfs-tools/modules. At least that's how I read it. 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. Finally, I have on this (sid) system both initrd-tools and initramfs-tools installed. The latter is brought in by the kernel dependencies, and the former is manually installed. Who knows why or when I did that, but is one preferred over the other? A signature.asc Description: Digital signature
Re: Large initrd [Was: Re: booting problem (udev related?)]
On Thu, Aug 02, 2007 at 18:23:04 +0300, Andrei Popescu wrote: [...] > Yes, I know what you mean. I was using yaird to make my initrd, but it > gave some errors on the latest upgrade (and Steve Langasek, Debian > kernel maintainer suggested it is no longer maintained). Do you mean this problem? yaird error: unrecognised line in /proc/bus/input/devices: U: Uniq= (fatal) That can be fixed relatively easily, see bug #431534, followup 1. (/usr/lib/yaird/perl/InputTab.pm is patched to simply ignore these new lines in /proc/bus/input/devices.) -- Regards,| http://users.icfo.es/Florian.Kulzer Florian | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Large initrd [Was: Re: booting problem (udev related?)]
On Wed, Aug 01, 2007 at 11:10:25PM -0600, Bob Proulx wrote: > Miles Bader wrote: > > Hmm, I didn't realize it analyzed the system when building the ramfs > > contents. Maybe I could just reinstall the kernel while the new kernel > > is running (or is there an official "hint" mechanism I could use)? > > Yes. Please try that. > > > [I thought it just included _every_ possible module on the ramfs -- > > judging from the enormous size of the installed kernel package, it seems > > like it!] > > :-) Yes, I know what you mean. I was using yaird to make my initrd, but it gave some errors on the latest upgrade (and Steve Langasek, Debian kernel maintainer suggested it is no longer maintained). So now I'm exploring the initramfs-tools package. The first initrd was about *5 (five)* times bigger! I changed the config for including modules from 'most' to 'dep' and I got a much smaller (but still a bit bigger then yaird) initrd. Haven't tried to boot with it yet, though ;) Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
