[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: upgrading the kernel in debian etch from 2.6.18 to 2.6.29



Joey L wrote :
> Tom - thanks for the reply -
> Do you think that is the issue  ???
> I am running mirrored drives for /boot.  I can not boot off of lvm.
> I have the rest of my drives on software raid5 and i have created lvm
> volume groups and put my / filesystem allong with everything else on them.
[...]pasted here from lower by me because it relates to the same problem
> I am also getting messeges that raid or array "failed to assemble all
> arrays"  ?? This array is working fine under the old kernel - the 2.6.18
> ...  Is there somehting special in the command that i have to run for an
> array configuraiton with lvm ????

So you need raid1, raid456 and md_mod loaded at boot time. I use Grub2
which can load those modules even before the initrd is loaded, so if
you're using grub "legacy" you're going to boot from one of the disks in
the array, have the initrd loaded, and with it must come along raid1,
raid456 and md_mod modules to assemble the arrays.
I think installing mdadm should trigger the inclusion of the modules in
the initrd, but if in doubt add raids and md_mod to
/etc/initramfs-tools/modules

echo -e "raid1\nmd_mod\nraid456" >> /etc/initramfs-tools/modules

and rebuild your initrd

update-initramfs -u -k kernelversion


where the "kernelversion" string is the target kernel version
(2.6.29-mykernel), or $(uname -r) for the running kernel, or "all" for
any possible kernel in the known universe ;-)
It's also a good idea to have the partition type of the arrays members
set to "fd" (raid-autodetect) if it's already done.

I don't use lvm, but I think the important thing is to get your arrays
up, the lvm initialization is done through /etc/init.d/lvm I believe.

> 
> Do you think the issue is that between the 2.6.18 kernel and the 2.6.29
> kernel - there was a change in the drive naming convention ???? where
> the hd* are now sd* ???
> 
> 
> I am concerned if i try to change it, the system will not boot.
> 
> When compiling the kernel...does this stuff not happen automatically ???

A change occurred in kernel 2.6.19 and up which triggers the naming
convention to shift from hd* to sd* for most configurations. Since
several configuration files relies on this naming convention it's a good
idea to check (fstab, mtab, menu.lst and device.map). A good way around
this in fstab, mtab and menu.lst is using labels or UUID.
It doesn't (at least always) happen automatically in my painful experience !
If you change that (hd* to sd*) and try to boot on the old kernel,
you're heading to a nice black screen... Use UUID's or labels to avoid
the need to shift configuration files in between boot attempts.

> thanks
> 

Hope it helps.

Tom


Reply to: