topic Re: lilo.conf help in Operating System - Linux

lilo.conf help

James Specht — Fri, 10 Oct 2003 10:28:00 GMT

OK. I have rebuilt my kernel to support frame buffering, which works. My problem is lilo can't find the root mount to start the system. I have three images that I tried and none work. The images vesafb1, 2 and 3 are my attempts. Linux is the default image that works. I did a "mkinitrd -v /boot/linux.vesafb.img `uname -r`" . But all I get are a bunch of library errors before it can't find the root file system.

This is a scsi hd and root is on /dev/sda3
Any other information I can supply just ask. This is getting frustrating to say the least!

--Jim

-----LILO.CONF-----

prompt
timeout=50
default=linux
boot=/dev/sda
map=/boot/map
install=/boot/boot.b
message=/boot/message
linear
vga=791

image=/boot/linux.vesafb1
label=Linux-vesafb
read-only
append="root=LABEL=/"

image=/boot/linux.vesafb2
label=Linux-vesafb
initrd=/boot/initrd-linux.vesafb.img
read-only
append="root=LABEL=/"

image=/boot/linux.vesafb3
label=Linux-vesafb
read-only
root=/dev/dsa3

image=/boot/vmlinuz-2.4.18-14
label=linux
initrd=/boot/initrd-2.4.18-14.img
read-only
append="root=LABEL=/"

Re: lilo.conf help

Steven E. Protter — Fri, 10 Oct 2003 10:37:32 GMT

What about going with grub? Doesn't help.

I'd like to know which distribution you are using so I can consult the appropriate manual.

SEP

Re: lilo.conf help

James Specht — Fri, 10 Oct 2003 11:38:27 GMT

I am using RedHat 8.0 on this system and acouple of others are RH 7.3. We don't use grub here due to some problems in the past that no one wants to retest against, so lilo is my only choice.

Re: lilo.conf help

Martin P.J. Zinser — Fri, 10 Oct 2003 12:04:51 GMT

Did you cut-n-paste the lilo.conf? In case you did you might want to change root=/dev/dsa3
to root=/dev/sda3

Re: lilo.conf help

James Specht — Fri, 10 Oct 2003 12:13:15 GMT

That was a typo in the message. Thanks for pointing it out. I have been searching on the mkinitrd information. It looks like I might need to recreate the initrd to support scsi correctly....I think.

--Jim

Re: lilo.conf help

Martin P.J. Zinser — Fri, 10 Oct 2003 17:45:08 GMT

Hi,,

I did poke around in my /boot (with a custom kernel). Besides of a new vmlinuz it does contain a map file to match the Kernel. How is that in your case?

Greetings, Martin

Re: lilo.conf help

Mark Grant — Sat, 11 Oct 2003 07:52:43 GMT

I can't remember if lilo support a "root=" line but you could at least try an

append="root=/dev/hdaX"

you could even try "root=/dev/hdaX" too but the first option will at least prove if we are on the right track.

Re: lilo.conf help

Stuart Browne — Sun, 12 Oct 2003 19:31:20 GMT

If you have created a new kernel, then yes, you most definately will have to create a new init ramdisk.

The kernel version/revision is all that's really required to make the new initrd, you just boot up (old kernel), and issue the command:

(Assumption: vesafb1 is the new kernel)

mkinitrd /boot/initrd-vesafb1

The kernel version/revision is basically the /lib/modules/ structure the modules associated with the kernel live.

Re: lilo.conf help

James Specht — Mon, 13 Oct 2003 07:37:25 GMT

I appreciate all the help, but so far no luck. Right now if I use an image I get tons of errors for every library module called. My plan now is to start with a clean install of RedHat 8.0 on a test system and see what happens when I rebuild the kernel without any changes to it. Then rebuild the kernel with the fram buffer support.

Thanks again for the help.

--Jim

Re: lilo.conf help

Jerome Henry — Mon, 13 Oct 2003 07:43:17 GMT

Jim,

If you can choose turn to rh9, more stable...

J

Re: lilo.conf help

James Specht — Mon, 13 Oct 2003 07:45:23 GMT

Thanks. I'll look into RH9, but I have vendor issues of course.

--Jim

Re: lilo.conf help

Jerome Henry — Mon, 13 Oct 2003 07:54:47 GMT

Of course, but you can download it for free from redhat.com
(plz 0 here).

J

Re: lilo.conf help

Stuart Browne — Mon, 13 Oct 2003 18:17:13 GMT

When building your own kernels from the RH provided source tree's, I'd suggest modifying the EXTRAVERSION flag (in the root Makefile), just to ensure you have your own, separate version.

It means less issue with overlapping /lib/modules/ tree structures.