Smokes your problems, coughs fresh air.


A new Archlinux upgrade, a new unbootable system

It’s that time again…

First my grub broke. So I had to type my config manually:

root (hd0,0)
kernel /vmlinux26 root=/dev/mapper/lvmopraid-root
initrd /kernel26.img

Then my logical volumes can’t be found. Type this in the recovery shell:

lvm lvchange -a e lvmopraid

I commented on an archlinux bug about this.

And then nothing started anymore on boot, because everything is migrating to systemd (as opposed to systemv), without telling me… Still working on fixing that.

Fixing a Xen DomU’s grub config

When you use xen-create-image to bootstrap an ubuntu, it sets up a grub config file menu.lst. However, this boot config is not kept up-to-date with newer ubuntu’s because they use grub2 (which uses grub.cfg and not menu.lst). And Xen’s pygrub first looks at menu.lst, so if you have a stale file, it will always boot an old kernel.

I ‘Fixed’ it like this (a real fix I have yet to devise, but this works. Actually, I think it is a bug):

The grub hooks in Debian and Ubuntu don’t take the fact into account that the machine might be running as paravirtualized VM. Therefore, it can’t find /dev/xvda to install grub on, which it shouldn’t try. Bug reports exist about this, but it is not deemed important, it seems. The result is that the menu.lst that was created by xen-create-image is never updated and updates to the kernel are never booted.

Pygrub considers menu.lst over grub.cfg (which would give problems with upgrading to grub2). But you can also use it to your advantage. You can edit /etc/kernel-img.conf to look like this (do_symlinks = yes and no hooks):

do_symlinks = yes
relative_links = yes
do_bootloader = no
do_bootfloppy = no
do_initrd = yes
link_in_boot = no
postinst_hook =
postrm_hook   =

And then make /boot/grub/menu.lst with this:

default         0
timeout         2
title           Marauder
root            (hd0,0)
kernel          /vmlinuz root=/dev/xvda2 ro
initrd          /initrd.img

Then uninstall grub. This way, you always boot the new kernel. (actually, I found that you can’t always uninstall grub. I now have machines with grub-pc and grub-common installed, but have an empty /boot/grub with only a menu.lst there. This will keep aptitude from complaining about grub-pc not being able to configure, because it’s unable to detect the bios device for /dev/xvda2 (or whatever)

Installing grub on RAID1

When you have your kernel image and grub boot stages on a Linux software RAID1 partition, installing grub needs a bit of trickery.

It determines on what hardware device those files are located by looking at /etc/mtab. It will find /dev/md/0 for / or /boot (or whatever) where the files are located. That device has no BIOS device, because it is managed by the Linux kernel. Therefore, when you try to install grub, it says: “/dev/md/0 does not have any corresponding BIOS drive.“. But because the underlying partitions in a RAID1 have the same data as the virtual device, we can trick grub.

All we have to do is edit /etc/mtab and replace the /dev/md/0 with /dev/sda1 (or whatever). You can then run grub-install hd0. Of course, make a backup of mtab first so you can revert it after having installed grub.

I find it kind of weird that grub doesn’t determine that the device in question is a RAID1 and that it can simply use the underlying device; the internet is filled with people having the same problem. If anybody knows a more elegant solution than this, I’m all ears.

Based on the comments, this is what you need to install it from the grub prompt:

# grub
grub> root (hd0,0)
grub> setup(hd0)
grub> root (hd1,0)
grub> setup (hd1)

© 2024 BigSmoke

Theme by Anders NorenUp ↑