alt.os.linux - kernel 2.5.47-- unable to mount root on 3:01?

Author

kernel 2.5.47-- unable to mount root on 3:01?

Bill Unruh

2002-11-26, 9:24 pm

I get the above error message on my system (Intel 845 mothrboard,
compiled 2.5.47-ac6. ) on bootup and the system freezes completely
(onlyunplugging helps.)

Is this a known problem or have I a) done something wrong b) found a
kernel bug.
It is an ide drive and the root partition is on /dev/hda3.

Any idea what could be done wrong (eg my having forgotten to install
some crucial kernel "module"?)

Paul Lutus

2002-11-27, 1:24 am

On Wed, 27 Nov 2002 02:33:34 +0000, Bill Unruh wrote:

> I get the above error message on my system (Intel 845 mothrboard,
> compiled 2.5.47-ac6. ) on bootup and the system freezes completely
> (onlyunplugging helps.)
>
> Is this a known problem or have I a) done something wrong b) found a
> kernel bug.
> It is an ide drive and the root partition is on /dev/hda3.
>
> Any idea what could be done wrong (eg my having forgotten to install
> some crucial kernel "module"?)

Well, gee, why don't you put in the boot floppy you had the foresight to
create and analyze the problem?

While we are at it, here are some trivial items you inadvertently left
out of your post:

1. What distribution.
2. What compilation procedure, exactly, step by step.
3. What system.
4. How much RAM.
5. Whether this is a system that has run Linux before.

--
Paul Lutus
www.arachnoid.com

Juergen Pfann

2002-11-27, 3:24 am

Bill Unruh wrote:
>
> I get the above error message on my system (Intel 845 mothrboard,
> compiled 2.5.47-ac6. ) on bootup and the system freezes completely
> (onlyunplugging helps.)
>
> Is this a known problem or have I a) done something wrong b) found a
> kernel bug.
> It is an ide drive and the root partition is on /dev/hda3.
>

But your kernel searches the root fs on /dev/hda1 - that is the
device with major # 3 and minor # 1 (03:01). This is in hex BTW,
but in this case no difference to the decimal system, of course.

Now: Who is to blame? Your bootloader, because it tells the kernel to
search the root fs at the wrong postion - or you, because you told
the wrong position to it (the bootloader) in its config file? ;-)).

Or, did you compile the kernel on a system having /dev/hda1 as root fs?
- By default, the _current_ root fs is hard coded into the kernel
image at compile time, but this can be changed a) permanently
by the "rdev" utility, b) once per booting by the boot loader,
e.g. LILO's "root = ..." line (for each image / menu item), or
manually at your boot loader's prompt.

You didn't simply forget to re-run LILO (if using LILO at all)?

> Any idea what could be done wrong (eg my having forgotten to install
> some crucial kernel "module"?)

See above. Did this already solve your problem? - If not, we do
need more information: for ex. type of boot loader, fs type of
root fs partition, is the fs and HW driver compiled statically
into your kernel, or do you use the initrd concept?
Perhaps you tell us the _relevant_ kernel config options.
Maybe also which distro is this (might not be that important, though)?

Juergen

Bill Unruh

2002-11-27, 3:25 pm

Juergen Pfann <juergen.pfann@t-online.de> writes:

]Bill Unruh wrote:
]>
]> I get the above error message on my system (Intel 845 mothrboard,
]> compiled 2.5.47-ac6. ) on bootup and the system freezes completely
]> (onlyunplugging helps.)
]>
]> Is this a known problem or have I a) done something wrong b) found a
]> kernel bug.
]> It is an ide drive and the root partition is on /dev/hda3.
]>

]But your kernel searches the root fs on /dev/hda1 - that is the
]device with major # 3 and minor # 1 (03:01). This is in hex BTW,
]but in this case no difference to the decimal system, of course.

]Now: Who is to blame? Your bootloader, because it tells the kernel to
]search the root fs at the wrong postion - or you, because you told
]the wrong position to it (the bootloader) in its config file? ;-)).

]Or, did you compile the kernel on a system having /dev/hda1 as root fs?
]- By default, the _current_ root fs is hard coded into the kernel
]image at compile time, but this can be changed a) permanently
]by the "rdev" utility, b) once per booting by the boot loader,
]e.g. LILO's "root = ..." line (for each image / menu item), or
]manually at your boot loader's prompt.

]You didn't simply forget to re-run LILO (if using LILO at all)?

]> Any idea what could be done wrong (eg my having forgotten to install
]> some crucial kernel "module"?)

]See above. Did this already solve your problem? - If not, we do
]need more information: for ex. type of boot loader, fs type of
]root fs partition, is the fs and HW driver compiled statically
]into your kernel, or do you use the initrd concept?
]Perhaps you tell us the _relevant_ kernel config options.
]Maybe also which distro is this (might not be that important, though)?

Thanks for your attempts to help me. I discovered (I think) what the
problem was-- when I compiled the kernel I did not enable the MSDOS
partition type, and thus the kernel could not read the partition table
on the drive. (Running the kernel with the "quiet" append removed showed
the error message that it could not read the partition table on that
drive). I will try again tonight to see whether I have solved this
problem.

The error code "on 3:01" was really what confused me, since I had no
idea what that meant. ( hda1 would have been far more illuminating).

One real problem in this kind of situation is that that whole bootup
kernel messages scroll by so fast and there is no way of doing (or is
there?) a "more" or "less" on them so that you can actually read them
(and
in this case of course they do not get saved in /var/log/dmesg since the
system cannot find /var/log/dmesg on the disk).

Ayway, lets say that this topic is closed unless I find something else I
have done stupidly.

Thanks

Bill

Juergen Pfann

2002-11-28, 4:24 am

Bill Unruh wrote:
>
> One real problem in this kind of situation is that that whole bootup
> kernel messages scroll by so fast and there is no way of doing (or is
> there?) a "more" or "less" on them so that you can actually read them
> (and
> in this case of course they do not get saved in /var/log/dmesg since the
> system cannot find /var/log/dmesg on the disk).
>

After bootup is complete, and you don't boot into X, say, you
can scroll the messages on your current (text) console screen
by pressing SHIFT + PageUp/PageDown (simultaneously, that is).
Just in case you didn't konw that. But beware: Once you
change into another virtual console (by pressing ALT + Fx), and
back again to (e.g.) VC #1, the message buffer is lost.
And to-date's really _long_ messages won't fit into the limited
screen buffer entirely, anyway.

Apart from that, the kernel message ring buffer does save
the kernel messages - of course, until it's full also.
There is the _tool_ "dmesg" to display that - you would pipe
it to less, of course -, if you don't have a /var/log/dmesg,
or /var/log/boot.msg, whatever it is called.
But check the man pages of dmesg, syslogd, klogd, and possibly
your distro's init scripts, whether they don't _clear_ that
buffer at some stage during booting / initing.

Of course, the latter method(s) assume(s) your kernel reaches
at least the initial runlevel, and you logged in to at least
a minimal shell.

Juergen

Bill Unruh

2002-11-28, 1:24 pm

Juergen Pfann <juergen.pfann@t-online.de> writes:

]Bill Unruh wrote:
]>
]> One real problem in this kind of situation is that that whole bootup
]> kernel messages scroll by so fast and there is no way of doing (or is
]> there?) a "more" or "less" on them so that you can actually read them
]> (and
]> in this case of course they do not get saved in /var/log/dmesg since the
]> system cannot find /var/log/dmesg on the disk).
]>

]After bootup is complete, and you don't boot into X, say, you
]can scroll the messages on your current (text) console screen
]by pressing SHIFT + PageUp/PageDown (simultaneously, that is).
]Just in case you didn't konw that. But beware: Once you
]change into another virtual console (by pressing ALT + Fx), and
]back again to (e.g.) VC #1, the message buffer is lost.
]And to-date's really _long_ messages won't fit into the limited
]screen buffer entirely, anyway.

Thanks, that is useful to know.
HOwever, that is not much help in the case of a kernel crash I guess.

]Apart from that, the kernel message ring buffer does save
]the kernel messages - of course, until it's full also.
]There is the _tool_ "dmesg" to display that - you would pipe
]it to less, of course -, if you don't have a /var/log/dmesg,
]or /var/log/boot.msg, whatever it is called.
]But check the man pages of dmesg, syslogd, klogd, and possibly
]your distro's init scripts, whether they don't _clear_ that
]buffer at some stage during booting / initing.

]Of course, the latter method(s) assume(s) your kernel reaches
]at least the initial runlevel, and you logged in to at least
]a minimal shell.

My original problem got solved by enabling MSDOS partition types, whichI
had mistakenly not activated as I thought it refered only to vfat type
partitions.

Of course then the kernel booted up, displayed a logon screen and died.
(ie no response from thekeyboard at all, including the numlocks light).
Oh, well, back to the 2.4.20 kernel. Teach me to try out an experimental
kernel.

Sponsored Links