Smokes your problems, coughs fresh air.
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 boot
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.
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)
I don’t believe in system passwords if they’re not backup by some type of disk encryption. It’s simply too easy to circumvent by changing a few boot parameters or by inserting a good boot disk. For performance reasons, I’ve decided against using full-disk encryption for my laptop and even against encryption for my home folder. This makes typing in a password to login a mere annoyance. Admittedly, my laptop features a fingerprint reader, but at the time I couldn’t get it to work and it still requires me to type in my username, which I find just as superfluous. Also, fingerprints aren’t that secure either.
For ages now, I’ve just wanted to be automatically logged in and greeted by an X session when I boot, especially since my xdm died after some upgrade about a year ago or so ago. For how much time I spend with this machine, I’m amazed how long it takes me before deciding that logging in in the console and typing startx might be not such a good idea.
(It probably has everything to do with “conditionality”. I tell myself, for example, that before ditching xdm (which is one of the few X login managers which doesn’t support auto login), I first need to get it to work again to make a screenshot of my “cute” configuration. Can’t kill my darlings; never could.)
So fuck all that. I’m too lazy to resurrect my darling, no matter how cute, so I took a look at this and added to following to /etc/conf.d/local.start:
# Start X as user if tty7 is free ! fuser /dev/tty7 >& /dev/null; su - bigsmoke -l -c 'exec startx -- vt7 >& ~/.xsession-errors' &
Done. Maybe I’ll also decide to make all my console sessions auto-login, if I can be arsed, that is.
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 Noren — Up ↑
Recent Comments