Hi,
I've downloaded kernel 2.6.15-rc6 (had the same problem with rc7) and
built it on RHAS 4:
make
make modules
make modules_install
make install
When I did that on an Opteron machine, after rebooting and selecting the
2.6.15-rc6 entry in the grub menu, I get the following:
root (hd0,0)
Filesystem type is ext2fs, partition type 0x83
kernel /vmlinuz-2.6.15-rc6 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
console=ttyS0,115200 console=tty0
[Linux-bzimage, setup=0x1400, size=0x1dfa8c]
initrd /initrd--2.6.15-rc6.img
[Linux-initrd @ 0x37f20000, 0xcff3f bytes]
Uncompressing Linux... Ok, booting the kernel.
Kernel panic - not syncing: VFS: unable to mount root fs on
unknown-block(0,0)
I made sure that ext2 is compiled with the kernel (not as a module).
When I do the same on an emt64 machine, everything works ok. Any idea?
Thanks
--
____________________________________________________________
Erez Zilber | 972-9-971-7689
Software Engineer, Storage Team
Voltaire ? _The Grid Backbone_
__
http://www.voltaire.com <http://www.voltaire.com/>
On Thu, 2005-12-29 at 13:38 +0200, Erez Zilber wrote:
> Hi,
>
> I've downloaded kernel 2.6.15-rc6 (had the same problem with rc7) and
2.6.15-rc needs a newer udev version...
Arjan van de Ven wrote:
>On Thu, 2005-12-29 at 13:38 +0200, Erez Zilber wrote:
>
>
>>Hi,
>>
>>I've downloaded kernel 2.6.15-rc6 (had the same problem with rc7) and
>>
>>
>
>2.6.15-rc needs a newer udev version...
>
>
>
>
Redhat AS4 comes with udev 039. I couldn't find a newer rpm for this distribution, so I cannot replace the current udev rpm. I've downloaded the latest udev sources from http://www.us.kernel.org/pub/linux/utils/kernel/hotplug/ and installed it but I still get the same errors.
Erez
On Thu, 2005-12-29 at 14:38 +0200, Erez Zilber wrote:
> Arjan van de Ven wrote:
>
> >On Thu, 2005-12-29 at 13:38 +0200, Erez Zilber wrote:
> >
> >
> >>Hi,
> >>
> >>I've downloaded kernel 2.6.15-rc6 (had the same problem with rc7) and
> >>
> >>
> >
> >2.6.15-rc needs a newer udev version...
> >
> >
> >
> >
>
> Redhat AS4 comes with udev 039. I couldn't find a newer rpm for this distribution, so I cannot replace the current udev rpm. I've downloaded the latest udev sources from http://www.us.kernel.org/pub/linux/utils/kernel/hotplug/ and installed it but I still get the same errors.
after you get a recent enough udev you probably need to recreate a new
initrd (and pray that you don't need a newer mkinitrd to match the newer
udev...) since udev is also put inside the initrd.
To be fair, enterprise linux distributions aren't actually designed to
run brand spanking new kernels, and the vendors aren't likely to update
userland tools to make newer kernels work either (unlike, say,
distributions like Fedora Core or SuSE or .. or .. or .. )
Arjan van de Ven wrote:
>On Thu, 2005-12-29 at 14:38 +0200, Erez Zilber wrote:
>
>
>>Arjan van de Ven wrote:
>>
>>
>>
>>>On Thu, 2005-12-29 at 13:38 +0200, Erez Zilber wrote:
>>>
>>>
>>>
>>>
>>>>Hi,
>>>>
>>>>I've downloaded kernel 2.6.15-rc6 (had the same problem with rc7) and
>>>>
>>>>
>>>>
>>>>
>>>2.6.15-rc needs a newer udev version...
>>>
>>>
>>>
>>>
>>>
>>>
>>Redhat AS4 comes with udev 039. I couldn't find a newer rpm for this distribution, so I cannot replace the current udev rpm. I've downloaded the latest udev sources from http://www.us.kernel.org/pub/linux/utils/kernel/hotplug/ and installed it but I still get the same errors.
>>
>>
>
>after you get a recent enough udev you probably need to recreate a new
>initrd (and pray that you don't need a newer mkinitrd to match the newer
>udev...) since udev is also put inside the initrd.
>
>To be fair, enterprise linux distributions aren't actually designed to
>run brand spanking new kernels, and the vendors aren't likely to update
>userland tools to make newer kernels work either (unlike, say,
>distributions like Fedora Core or SuSE or .. or .. or .. )
>
>
>
>
So, I understand that, currently (until I get a a recent enough udev),
2.6.15 cannot be used with RHAS-4 on Opteron machines. Anyway, thanks
for your help.
Erez
Erez Zilber <[email protected]> writes:
> >
> So, I understand that, currently (until I get a a recent enough udev),
> 2.6.15 cannot be used with RHAS-4 on Opteron machines. Anyway, thanks
> for your help.
I think that's too strong. udev setups are fragile and seem
to be inventented by the devil to make kernel updates hell, but if you
just compile the needed drivers and file systems for root statically
into the kernel it should work. For network devices and other
drivers not needed for root you can either load them manually
early in a rc.d file or also compile them in.
Typically when udev goes wrong it just doesn't autoload the modules,
but still processes the events when devices appear.
-Andi
On Thu, 29 Dec 2005, Erez Zilber wrote:
> Hi,
>
> I've downloaded kernel 2.6.15-rc6 (had the same problem with rc7) and built it
> on RHAS 4:
>
> When I did that on an Opteron machine, after rebooting and selecting the
> 2.6.15-rc6 entry in the grub menu, I get the following:
>
> Uncompressing Linux... Ok, booting the kernel.
> Kernel panic - not syncing: VFS: unable to mount root fs on unknown-block(0,0)
>
> I made sure that ext2 is compiled with the kernel (not as a module).
>
> When I do the same on an emt64 machine, everything works ok. Any idea?
Check on your /boot/grub.config. The above error message is typically
seen when the root= parameter points to a symbolic disk label instead of a
specific disk such as /dev/hda1. I'm not sure what the procedure for
updating where the label points (possibly a mkinitrd) because I normally
change the grub.conf to point to a specific disk.
On Fri, 2005-12-30 at 07:31 -0500, Thomas Molina wrote:
> On Thu, 29 Dec 2005, Erez Zilber wrote:
>
> > Hi,
> >
> > I've downloaded kernel 2.6.15-rc6 (had the same problem with rc7) and built it
> > on RHAS 4:
> >
> > When I did that on an Opteron machine, after rebooting and selecting the
> > 2.6.15-rc6 entry in the grub menu, I get the following:
> >
> > Uncompressing Linux... Ok, booting the kernel.
> > Kernel panic - not syncing: VFS: unable to mount root fs on unknown-block(0,0)
> >
> > I made sure that ext2 is compiled with the kernel (not as a module).
> >
> > When I do the same on an emt64 machine, everything works ok. Any idea?
>
> Check on your /boot/grub.config. The above error message is typically
> seen when the root= parameter points to a symbolic disk label instead of a
> specific disk such as /dev/hda1. I'm not sure what the procedure for
> updating where the label points (possibly a mkinitrd) because I normally
> change the grub.conf to point to a specific disk.
there is no such procedure, because the disk labels are... ON THE DISK.
And the initrd reads them from all the disks at boot time to find the
one needed. This means that if your disk changes name (for example
because of a scsi bus order change or because of a different order you
load the device drivers... or even if you forget to compile the sata
drivers and suddenly the disk goes from /dev/sda to /dev/hda).... things
just remain working
Arjan van de Ven wrote:
>On Fri, 2005-12-30 at 07:31 -0500, Thomas Molina wrote:
>
>
>>On Thu, 29 Dec 2005, Erez Zilber wrote:
>>
>>
>>
>>>Hi,
>>>
>>>I've downloaded kernel 2.6.15-rc6 (had the same problem with rc7) and built it
>>>on RHAS 4:
>>>
>>>When I did that on an Opteron machine, after rebooting and selecting the
>>>2.6.15-rc6 entry in the grub menu, I get the following:
>>>
>>>Uncompressing Linux... Ok, booting the kernel.
>>>Kernel panic - not syncing: VFS: unable to mount root fs on unknown-block(0,0)
>>>
>>>I made sure that ext2 is compiled with the kernel (not as a module).
>>>
>>>When I do the same on an emt64 machine, everything works ok. Any idea?
>>>
>>>
>>Check on your /boot/grub.config. The above error message is typically
>>seen when the root= parameter points to a symbolic disk label instead of a
>>specific disk such as /dev/hda1. I'm not sure what the procedure for
>>updating where the label points (possibly a mkinitrd) because I normally
>>change the grub.conf to point to a specific disk.
>>
>>
>
>there is no such procedure, because the disk labels are... ON THE DISK.
>And the initrd reads them from all the disks at boot time to find the
>one needed. This means that if your disk changes name (for example
>because of a scsi bus order change or because of a different order you
>load the device drivers... or even if you forget to compile the sata
>drivers and suddenly the disk goes from /dev/sda to /dev/hda).... things
>just remain working
>
>
>
>-
>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/
>
>
Compile the kernel with support for your hardware built in, i'm assuming
you eighter build the controller as a module or didn't built it at all
> >there is no such procedure, because the disk labels are... ON THE DISK.
> >And the initrd reads them from all the disks at boot time to find the
> >one needed. This means that if your disk changes name (for example
> >because of a scsi bus order change or because of a different order you
> >load the device drivers... or even if you forget to compile the sata
> >drivers and suddenly the disk goes from /dev/sda to /dev/hda).... things
> >just remain working
> >
Interesting. I've been compiling my own kernels for quite some time and
have never had a boot device end up anywhere except where I thought it
should. This includes during the 2.5 craziness when parts of ide support
was rewritten at least twice.
> >
> Compile the kernel with support for your hardware built in, i'm assuming you
> eighter build the controller as a module or didn't built it at all
Certainly this is the best advice. Not only support for the hardware, but
also ext3 journalling as well as ext2 support. I think it may be possible
to end up with ext2 builtin but ext3 journalling as modular.