I've just upgraded an older machine (a P3 running slackware 11.0) from
2.6.26.5 to 2.6.30; the build was uneventful. However, on reboot (using
lilo) I get:
VSF: Cannot open root device "hda2" or unknown-block(0,0)
Please append a correct root= boot option; here are the available
partions: <====== nothing shows here...
Kernel-Panic - not syncing.
I had rebooted with and without root=hda2. The old kernel is still
usable.
Lilo.conf looks like:
boot = /dev/hda
lba32
message = /boot/boot_message.txt
prompt
timeout = 300
vga = normal
# Linux bootable partition config begins
image = /bzImage-2.6.30
root = /dev/hda2
label = Linux-2.6.30
read-only
# Linux bootable partition config ends
# Linux bootable partition config begins
image = /bzImage-2.6.26.5
root = /dev/hda2
label = Linux-2.6.26.5
read-only
# Linux bootable partition config ends
# Linux bootable partition config begins
image = /memtest86
root = /dev/hda2
label = memtest86
read-only
# Linux bootable partition config ends
Any ideas? Please CC me directly.
Thanks in advance
David
David Ronis wrote:
> I've just upgraded an older machine (a P3 running slackware 11.0) from
> 2.6.26.5 to 2.6.30; the build was uneventful. However, on reboot (using
> lilo) I get:
>
> VSF: Cannot open root device "hda2" or unknown-block(0,0)
> Please append a correct root= boot option; here are the available
> partions: <====== nothing shows here...
> Kernel-Panic - not syncing.
>
> I had rebooted with and without root=hda2. The old kernel is still
> usable.
>
> Lilo.conf looks like:
Add large-memory option to lilo.conf
/mjt
On Fri, Jun 19, 2009 at 12:32 PM, Michael Tokarev<[email protected]> wrote:
> David Ronis wrote:
>>
>> I've just upgraded an older machine (a P3 running slackware 11.0) from
>> 2.6.26.5 to 2.6.30; the build was uneventful. ?However, on reboot (using
>> lilo) I get:
>>
>> VSF: ?Cannot open root device "hda2" or unknown-block(0,0)
>> Please append a correct root= boot option; here are the available
>> partions: ? ? <====== nothing shows here...
>> Kernel-Panic - not syncing.
>>
>> I had rebooted with and without root=hda2. ? The old kernel is still
>> usable.
>>
>> Lilo.conf looks like:
>
> Add large-memory option to lilo.conf
>
> /mjt
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>
check /dev/hda* to see
if it renamed itself to /dev/sda*
(noticed this a few months ago with
2.6.17(I think) to 2.6.24)
--
Justin P. Mattock
Thanks for the reply. I added large-memory to lilo.conf, reran lilo,
and rebooted. I get the same problem, except now the unknown-block was
3,2. when I boot without specifying root=hda2, with root=hda2 I get the
same behavior.
David
On Fri, 2009-06-19 at 23:32 +0400, Michael Tokarev wrote:
> David Ronis wrote:
> > I've just upgraded an older machine (a P3 running slackware 11.0) from
> > 2.6.26.5 to 2.6.30; the build was uneventful. However, on reboot (using
> > lilo) I get:
> >
> > VSF: Cannot open root device "hda2" or unknown-block(0,0)
> > Please append a correct root= boot option; here are the available
> > partions: <====== nothing shows here...
> > Kernel-Panic - not syncing.
> >
> > I had rebooted with and without root=hda2. The old kernel is still
> > usable.
> >
> > Lilo.conf looks like:
>
> Add large-memory option to lilo.conf
>
> /mjt
>
Justin Mattock wrote:
> On Fri, Jun 19, 2009 at 12:32 PM, Michael Tokarev<[email protected]> wrote:
>> David Ronis wrote:
>>> I've just upgraded an older machine (a P3 running slackware 11.0) from
>>> 2.6.26.5 to 2.6.30; the build was uneventful. However, on reboot (using
>>> lilo) I get:
>>>
>>> VSF: Cannot open root device "hda2" or unknown-block(0,0)
>>> Please append a correct root= boot option; here are the available
>>> partions: <====== nothing shows here...
>>> Kernel-Panic - not syncing.
>>>
>>> I had rebooted with and without root=hda2. The old kernel is still
>>> usable.
>>>
>>> Lilo.conf looks like:
>> Add large-memory option to lilo.conf
>
> check /dev/hda* to see
> if it renamed itself to /dev/sda*
It cant "rename itself".
The difference between sd* and hd* is different driver for the
controller - either old good ide code (like piix) - that's hd*,
or libata-based code (ata_piix). Which one is compiled into
your kernel or gets loaded by initrd is controlled by you, not
by kernel or drivers.
/mjt
Thanks for the reply.
I don't know how to do this with the crashed kernel, but in 2.6.26.5
the expected /dev/hda? entries are there, while /dev/sda? aren't.
David
On Fri, 2009-06-19 at 12:55 -0700, Justin Mattock wrote:
> On Fri, Jun 19, 2009 at 12:32 PM, Michael Tokarev<[email protected]> wrote:
> > David Ronis wrote:
> >>
> >> I've just upgraded an older machine (a P3 running slackware 11.0) from
> >> 2.6.26.5 to 2.6.30; the build was uneventful. However, on reboot (using
> >> lilo) I get:
> >>
> >> VSF: Cannot open root device "hda2" or unknown-block(0,0)
> >> Please append a correct root= boot option; here are the available
> >> partions: <====== nothing shows here...
> >> Kernel-Panic - not syncing.
> >>
> >> I had rebooted with and without root=hda2. The old kernel is still
> >> usable.
> >>
> >> Lilo.conf looks like:
> >
> > Add large-memory option to lilo.conf
> >
> > /mjt
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
> check /dev/hda* to see
> if it renamed itself to /dev/sda*
> (noticed this a few months ago with
> 2.6.17(I think) to 2.6.24)
>
David Ronis wrote:
> Thanks for the reply. I added large-memory to lilo.conf, reran lilo,
> and rebooted. I get the same problem, except now the unknown-block was
> 3,2. when I boot without specifying root=hda2, with root=hda2 I get the
> same behavior.
In that case you'll have to provide much more details. Boot log probably
using netconsole. Check config differences.
I suggested large-memory lilo option because your lilo.conf didn't have
it and 2.6.30 is known to outgrow default lilo assumptions. So it wasn't
your case, it has to be in config change or in something failing during
boot.
Examine boot log (you can try adding vga=ask and choosing the largest
resolution offered, and also try loglevel=4 or loglevel=5 this will
reduce printk noise printed on the console) and config changes.
And please don't top-post.
/mjt
On Sat, 2009-06-20 at 00:31 +0400, Michael Tokarev wrote:
> it and 2.6.30 is known to outgrow default lilo assumptions. So it wasn't
> your case, it has to be in config change or in something failing during
> boot.
> And please don't top-post.
>
> /mjt
I diffed the .config files for the 2 kernels. The result is at
http://pastebin.ca/1466767
David
David Ronis wrote:
[]
> I diffed the .config files for the 2 kernels. The result is at
>
> http://pastebin.ca/1466767
And?
BTW, it's difficult to read plain diff. I guess I see what did you
miss, but if you're building your own kernel you'd better find it
yourself.
/mjt
On Fri, Jun 19, 2009 at 1:20 PM, Michael Tokarev<[email protected]> wrote:
> Justin Mattock wrote:
>>
>> On Fri, Jun 19, 2009 at 12:32 PM, Michael Tokarev<[email protected]> wrote:
>>>
>>> David Ronis wrote:
>>>>
>>>> I've just upgraded an older machine (a P3 running slackware 11.0) from
>>>> 2.6.26.5 to 2.6.30; the build was uneventful. ?However, on reboot (using
>>>> lilo) I get:
>>>>
>>>> VSF: ?Cannot open root device "hda2" or unknown-block(0,0)
>>>> Please append a correct root= boot option; here are the available
>>>> partions: ? ? <====== nothing shows here...
>>>> Kernel-Panic - not syncing.
>>>>
>>>> I had rebooted with and without root=hda2. ? The old kernel is still
>>>> usable.
>>>>
>>>> Lilo.conf looks like:
>>>
>>> Add large-memory option to lilo.conf
>>
>> check ?/dev/hda* ?to see
>> if it renamed itself to /dev/sda*
>
> It cant "rename itself".
>
> The difference between sd* and hd* is different driver for the
> controller - either old good ide code (like piix) - that's hd*,
> or libata-based code (ata_piix). ?Which one is compiled into
> your kernel or gets loaded by initrd is controlled by you, not
> by kernel or drivers.
>
> /mjt
>
ahh.. that's what I did then
had old, then changed to new,
but didn't realize.
Thanks for clearing that up.
--
Justin P. Mattock
On 06/19/2009 01:23 PM, David Ronis wrote:
> I've just upgraded an older machine (a P3 running slackware 11.0) from
> 2.6.26.5 to 2.6.30; the build was uneventful. However, on reboot (using
> lilo) I get:
>
> VSF: Cannot open root device "hda2" or unknown-block(0,0)
> Please append a correct root= boot option; here are the available
> partions:<====== nothing shows here...
> Kernel-Panic - not syncing.
>
> I had rebooted with and without root=hda2. The old kernel is still
> usable.
Make sure you configured in the proper IDE driver for your chipset.
Previously I believe the IDE driver would attach to unknown chipsets in
a crappy generic fashion, but I don't think it does anymore.
If that doesn't help, please post your kernel config and lspci output.
Hi Robert,
That was it. Including the appropriate driver in the kernel build
worked like a charm.
Thanks for your help--Short and correct!
David
On Fri, 2009-06-19 at 22:43 -0600, Robert Hancock wrote:
> On 06/19/2009 01:23 PM, David Ronis wrote:
> > I've just upgraded an older machine (a P3 running slackware 11.0) from
> > 2.6.26.5 to 2.6.30; the build was uneventful. However, on reboot (using
> > lilo) I get:
> >
> > VSF: Cannot open root device "hda2" or unknown-block(0,0)
> > Please append a correct root= boot option; here are the available
> > partions:<====== nothing shows here...
> > Kernel-Panic - not syncing.
> >
> > I had rebooted with and without root=hda2. The old kernel is still
> > usable.
>
> Make sure you configured in the proper IDE driver for your chipset.
> Previously I believe the IDE driver would attach to unknown chipsets in
> a crappy generic fashion, but I don't think it does anymore.
>
> If that doesn't help, please post your kernel config and lspci output.
>