[lug] problem compiling Ubuntu kernel

[Lee Woodworth]

On 01/23/10 10:46, bgiles wrote:
> bgiles wrote:
>> David L. Anselmi wrote:
>>> The same way you compile a kernel on it.  Boot something else and 
>>> chroot into your drive.
>>>
>>> I don't know how close the running kernel has to be to the one you 
>>> want an initramfs for, they might have to be the same architecture.
>>>
>>> It's a pity the upgrade didn't leave your old kernel and initramfs 
>>> around.
>>>
>>> Dave
>>>   
>> I've figured out the biggest problem - the grub loader is insisting 
>> that the root partition is /dev/hda3 (which it was under older 
>> kernels), but the new kernel insists it's /dev/sda3.  Every update has 
>> been pointing the new kernel to the wrong place.  It can't be pulling 
>> the information from /etc/fstab or the rescue disc since both say it's 
>> /dev/sda3.
As far as I know grub doesn't directly use the /dev/hdxx or /dev/sdxxx
names. The devices and files are specified using (hdn[,m]) forms where
n is a disk number and m is an optional partition number. The root=
parameter of the kernel line is interpreted by the kernel, not grub.
IIRC, Grub has a device.map file it creates that can affect how the
(hdn,m) names are interpreted when using grub at the command prompt.
Don't think it matters during boot as Grub uses block addressing to
locate the initial boot stages. You can delete the map file and then
recreate it using grub. If the boot partition is the first partition
on the first disk and has the grub files in /grub:
    $ grub
    #grub> root (hd0,0)
    #grub> setup (hd0)
    #grub> quit

>>
>> A related issue is the 'rescue' partition was the old swap location, 
>> /dev/hda2, instead of the new swap location, /dev/sda2.
If your kernel changed from using old ide drivers to the newer libata
drivers the device names will change. Old ide named things as /dev/hdxn,
libata names them as /dev/sdxn. Usually the system startup scans for
swap partitions by signature to use them. Have you used the mkswap
and swapon commands to setup the swap area?

>>
>> The third problem is that the startup process isn't finding the lvm 
>> device so I can manually tweak the menu.lst file to the system will 
>> reboot (until the next time I update the kernel) but something is 
>> still not quite right.  I can mount the partitions manually once I go 
>> into maintenance mode so it's not a case of a missing kernel module.
What is the 'LVM device'? Do you mean the device mapper (dm_mod)? I
don't remember if you said your root fs was an LVM volume or not. If so,
then the initramfs needs to load the module or it needs to be built-in.
Note that loading the module does not automatically activate the volumes.
I still have to have a 'vgchange -ay' command in my initramfs to make the
LVM volumes visible.

>>
>> Bear
> The problem with LVM is getting kinda weird.  The 'device mapper' is 
> visible in /proc/misc and 'lvscan' sees the volumes, but there's no 
> /dev/vg00 directory.  Running dmsetup mknodes didn't have an effect.

I don't use ubuntu so this might not apply. But I remember there was a
change in one of the recent kernel versions where the /dev/vg/xxx devices
stopped getting created by dm_mod. The devices that do get created are
/dev/mapper/vgname-lvname.

My initramfs has this setup for LVM and the mount for the root file system
(an LVM volume):
    /sbin/modprobe dm-mod
    /sbin/vgscan --ignorelockingfailure --mknodes
    /sbin/vgchange --ignorelockingfailure -ay
    /bin/mount -t xfs -o ro /dev/mapper/vg20090810-sys /newroot
    ....
    exec /sbin/switch_root -c /dev/console /newroot /sbin/init

The /boot/grub/grub.conf file (menu.lst is a symlink to grub.conf for me)
also specifies the same root device:
    title  Gentoo 2.6.32-r1
    root (hd0,0)
    kernel /bzImage-2.6.32-gentoo-r1 root=/dev/mapper/vg20090810-sys
    initrd /initramfs-2.6.32-gentoo-r1.cpio.gz

So a question is whether your initramfs is doing something equivalent or not. I do
think the initarmfs/initrd needs to be tuned to the kernel (e.g. matching versions
numbers). Different kernels have different sets of required modules and naming
behavior. I often have to tweak my initramfs generator when changing kernel versions.

For the non-root-fs file systems, mounting by label or UUID can make the boot
more resilient. The exact VG name doesn't matter as long as file systems are labeled:
   LABEL=sys  /               xfs         noatime             0 1
   LABEL=boot /boot           xfs         noatime             0 2
   LABEL=home /home           xfs         noatime             0 0
   LABEL=opt  /opt            xfs         noatime             0