How is it not simpler to avoid a step entirely? Initrd is a workaround and by definition adding something not required is more complex than just solving the issue up front, especially in this case where we are talking about simple filesystem support. Why would anyone ever wish to blacklist a filesystem? How would it ever conflict with anything? I might be convinced that an initrd used in the case of some problematic specific hardware might be AS GOOD a solution as hard-wired into the kernel, but with the exception that I noted of encryption, I am aware of no situation in which it is superior or required.

If I don't change my kernel, I don't need to re-run mkinitrd either.

One more thought - reverse the order of the lilo stanzas, put stock first and generic second, so they install to different locations in the boot record. Maybe even try adding a third stanza with a different initrd so that it will also reside in a different location on disk.

I have never had a lilo problem with or without initrd that could not be resolved, so I am very curious about this one!

Could you also provide a but more info on the drive, mfgr, partition scheme, etc. and on the machine itself.

The output of ls -l /boot too.

This started with my trying to boot off an encrypted LVM, like I usually do when I put Slackware on a laptop. In attempting to isolate the problem I found I got the same error by just attempting to boot a generic kernel off a plain MBR partition with an initrd on this hardware. If I'm on plain partitions I generally don't use an initrd.

For that matter, in production machines I generally don't use modules at all except for DRM and audio, and that's only because both of those really "want" to be modules (which I find irritating). On a new Slackware install I'm usually only running the stock kernel long enough to boot, download the latest stable branch, and build it. So if I can fix this, I'll only actually be using the initrd to unlock the LUKS partition in the long term.

And, now that I say that, I do recall there's a built-in initrd option, which I may take a look at, though IIRC that's mostly contemplated for embedded systems and it may not meet my needs. (EDIT: now I remember: if it hasn't changed since 2.X, you can't pivot_root out of it.)

Haven't had a chance to inspect your lilo configuration, however a noteworthy point I need to mention first: you can capture the contents of the kernel panic/kernel oops/kernel dump via a serial cable console (utilizing uucp/putty).

There are usb-serial devices, however they can be problematic. I don't have any experience using those devices in linux, but I do recall them being especially problematic in windows (I had a ton of driver issues).

Understood. Thank you for the clarification.

"Problematic" doesn't even begin to cover it (I do a lot of serial port programming for the lab I work at). ttyUSB gets really hairy, and anyways the USB stack isn't up at this point. Thanks, though!

Bandrami,

You mentioned you can succesfully load the huge kernel. A VFS related error.. have you ever at any point been able to use the generic kernel on this system w/ a initrd?

I'm asking because my guess would be that you are missing the module for the storage controller in your initrd. That is generally the reason you would use an initrd in the first place, as it is common practice to recompile your kernel with the drivers your system requires.

Can you do me a favor, load the huge kernel, and run (as root):

lspci -vvv | grep modules

lspci -vvv | grep driver

and provide the output?

Also, you can load the usb stack by including the following modules in the initrd:
ehci-hcd
uhci-hcd
usb-storage

If you can borrow a serial cable or usb adapter from your work, it would be worth it to see the exact kernel dump you have on screen.

Diego

The OP stated that the same initrd booted just fine using grub2 on the same machine.

Richard I don't know how I missed that, I should've looked at the first post more carefully. Thanks.

My previous statement made sense before the grub2 info.

Since you're installing lilo in the mbr, maybe the mbr is corrupt. Try clearing out the mbr via dd and then installing the initrd by running lilo:

you may want to back mbr first:
overwrite current mbr w/ zeros:
then run lilo

worth a shot in my opinion. I'm trying to think of the major differences that distinguish grub and lilo. Obviously there is a functionality within lilo that isn't jiving with your initrd that needs to be narrowd down.

1 members found this post helpful.

Maybe using the large-memory option will fix things

Jesus, that is what I get for posting right before I go to bed! Thanks Gazl, it should read like this

dd if=/dev/zero of=/dev/sda bs=446 count=1

https://wiki.archlinux.org/index.php/Master_Boot_Record