Eric d'Alibut <eric@bernstein.providence.ri.us> wrote:
When I came into possession of a Micron dual PPro with a Symbios scsi adapter and new scsi drive, I grabbed the "compact" flavor of 2.2r6 and easily installed Debian over a cable 'net connection. The compact kernel boots nicely with LILO on /dev/sda; the only tweaking needed was adding an append in lilo.conf: append="sym53c8xx=mpar:n" Problem: I cannot build a kernel that will boot from the hard drive! I am using the 2.2.19 source, and every custom kernel I have built fails the same way; the boot dies - grinds to a halt - with no error messages as soon as the "Ok, now booting the kernel" message appears. These kernels _can_ boot from floppy if you make a boot floppy when make-kpkg prompts you as to whether or not you want one. Hence the Subject: line "How does compact do it?" i.e. how does the compact kernel manage to boot off the hard drive when all of my custom ones, even those that consist for the most part of compact's .config itself, fail. I'm getting ready to go the initrd route, but that shouldn't be necessary, should it? -- Eric d'Alibut
The kernel on the "compact" disk has several of the more common drivers "compiled in" rather than compiled as modules. Your SCSI driver is one of those. This is propably at the root of your problem. When you are compiling the new kernel you are selecting to compile the sym53c8xx "driver" as a module. Check out the "config" for the kernel used in the compact boot floppies (at the same site where you got the floppy images) and you will see what I mean.
When LILO starts a boot selection, it doesn't know much or have much capability. It can access the kernel, place it into memory and start running it and that is about it. The process is similar to the increasing capabilities of and infant --> child --> teenager --> adult, but in a very rapid manner. The code to access boot-critical devices (like your hard drive) MUST be in the kernel code and NOT as a module stored on the File System. The one exception to this "rule" is if you are using initrd.
You have your basic "chicken vs egg" connundrum if it is compiled as a module. The code to access the HD is stored within the file system, which cannot be mounted and read until the HD is accessed, which cannot be done without the module code. The way around this is to make it part of the kernel code, or use an initrd image file to "pre-load" boot-critical device driver code.
Cheers, -Don Spoon- --To UNSUBSCRIBE, email to debian-user-request@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org