So… I saw that Fedora 16 was out in Beta. I decided to try out the supposed Xen dom0 capability, using my old 1U. It had Fedora 15 installed, but nothing on it, so I just decided to blow it all away.
To start, I went and downloaded the Live CD. First problem: I grabbed the x64 version. NOT the i686 version which my 1U needs. Took out the ‘rhgb’ option in the boot line, wondering why it wasn’t starting up, only to be greeted with “This machine requires an i386 kernel, while this kernel is x86_64.”
And that was Derp 1 of the day.
Ok… so do a preupgrade or similar. Reboot into Fedora 15, ssh in. I completely forget about preupgrade, and jump straight to upgrading with yum. A few package upgrade errors where “libnih” can’t find dependencies, easily fixed by doing a “yum provides libnih” followed by “yum erase libnih” and repeat for the packages with errors.
So I’m merrily following the “official upgrade using yum guide“, and I run into another error. This time it’s more serious. Having just followed the instructions to wipe out grub, the bootloader, to my horror I find I can’t install grub2, the new bootloader.
And this is derp 2 of the day: I don’t narrow down the cause. I see “Cannot retrieve metalink for repository: fedora”, and immediately think “Oh, crud, because of the yum upgrade, it can’t determine the release version! And I can’t reboot because the frakkin’ bootloader’s not there!”
Except, it wasn’t a problem with the repo files. The system’s DNS resolving went down. I have no clue why, but I’m just thankful that my SSH session remained open. Add the IPs for mirrors.fedoraproject.org and ftp.jaist.ac.jp to /etc/hosts, and grub2 downloads & installs.
So far so good.
/sbin/grub2-mkconfig -o /boot/grub2/grub.cfg was taking a suspiciously long time, though, it’s giving messages similar to the ones in this bug. But it seems to be smart enough to test what kernels can support Xen, though it’s not too smart about Xen itself – It has 3 menu entries for Xen, using ‘xen.gz’, ‘xen-4.gz’ and ‘xen-4.1.gz’, all of which are symlinked to ‘xen-4.1.1.gz’. Which itself has an entry. So now I’ve got multiple entries for Xen all pointing to the same Xen install.
As for the grub2-install, using /dev/mapper/pdc_dbijaaabh as the boot drive failed. Using /sbin/grub2-install /dev/disk/by-id/ata-ST3160812A_5LS9P57M also didn’t work.
But, it boots! Still using legacy grub (didn’t wipe out the bootsector, thank god), but, IT BOOTS! 😀
(Also, I’m getting memory errors in dmesg and /var/log/messages. Yay. But that’s a hardware problem, and this system only has to live for another 8 months anyway.)