On 2009-12-30 at 08:45:14 -0500, David Baron wrote: > Probably is because I do not know what is safe to set to "no". These are > basically stock kernels with whatever would have been in the initrd compiled > in instead. The debs are full of modules, most of which simply take up space.
Why is it important to you to compile everything in? That makes your kernel unnecessarily big and wastes RAM. If the stock kernel does what you need it to do, why bother to create a custom kernel anyway? That chews up a lot of disk space too. My advice, for what it's worth, is this: (1) use a stock kernel if you can, unless you really need something that's not included in the stock kernel. (2) If you do need to create a custom kernel, don't compile anything in that can be modularized. (3) If you still have problems with lilo running out of space between the end of the kernel and the beginning of the EBDA (i.e. not enough room to load the initial RAM disk image), then add the large-memory option in the the /etc/lilo.conf file, if your BIOS supports it, and re-run lilo. (If the BIOS doesn't support the large-memory option, you'll know pretty quickly! Make sure you have a rescue CD at the ready. This option will affect all kernels defined to lilo; so if you can't boot one, you probably can't boot any!) (4) If your BIOS doesn't support the large-memory option, try editing /etc/initramfs-tools/initramfs.conf and change "modules=most" to "modules=dep", then run update-initramfs to update your initial RAM file system. (Issue "rm /boot/*.bak" afterward to save disk space.) If update-initramfs doesn't re-run lilo, then re-run lilo manually. This will reduce the size of your initial RAM file system, which we hope will allow it to fit between the end of the kernel and the beginning of the EBDA. (Do remember to take the large-memory option out of /etc/lilo.conf before running update-initramfs, if you tried it and it didn't work.) (5) If that doesn't work for you, upgrade to a newer boot loader, such as grub, which can get around the BIOS memory restrictions with native I/O. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org