Posts Tagged fedora 16
So, I’ve wiped my test system with the intention of doing a tutorial on installing F16 + Xen. As part of this, I looked into installing a F16 domU with virt-install. When I tried it previously, I ran into this bug, and I ended up having to vnc into the dom0 and use virt-viewer to do the install.
Recently, there was some activity on the bug, centering around using “
rd_NO_PLYMOUTH” to bypass the plymouth boot screen (the progress bar that scrolls across the screen, apparently – though why it’s in the installer I have no clue).
In any case, it seems to work – my revised install command of
virt-install -p -r 1024 -n rawhide -f /dev/domU/rawhide -l http://ftp.jaist.ac.jp/pub/Linux/Fedora/releases/16/Fedora/x86_64/os/ -x "ks=\"http://hydrogen/~kyl191/ks/ks.php?hostname=rawhide\" rd_NO_PLYMOUTH serial" seems to do the trick – it gets into the console, at the very least.
That said, I get a nasty error using the partitioning scheme in my Kickstart file – grub2 wants a BIOS boot partition, a 1MB partition for storing files, and installation fails.
So, either I add the extra partition to the kickstart partitioning stanza, or I pass the installer an extra
nogpt option when installing.
Guess which I chose. The BIOS boot partition makes no sense for Xen, because we’re booting with pygrub – we only care about grub.cfg, not what GRUB files are present or even if the bootloader is installed (which leads me to a question – can we get away with not specifying a bootloader to be installed in anaconda? I imagine not, since that probably means grub2 won’t be installed, but it might be something to look into.)
Though, it does seem to have completely fallen over – pygrub’s not returning any data on a (F14) Xen 4.0.2 system. xm create rawhide.cfg just returns an unhelpful “Error: Boot loader didn’t return any data!”, but trying pygrub directly gives a bit more detail – “RuntimeError: couldn’t find bootloader config file in the image provided.”
Trying with my F16 testbed now…
Also, apparently, radeontool, yum-pluginfastestmirror & ntpdate aren’t present in the F16 repos, so I have to remove them from my Kickstart file.
I’m trying out F16 as a dom0 from the beginning. No upgrades from F15 this time. So far, it’s generally ok.
The install (from the netinstall ISO) was straightforward. Only issue was that F16 strongly recommends that a BIOS boot partition be present. (Read: Requires it unless you pass a
nogpt option to the kernel boot line when installing.) Unlike in the F16 domU, I need grub2 to be working so I can boot, so I added the partition.
However, it’s subject to some strict size limits – between 1-2MB. 1MB is recommended, though I put 2MB and it seems to boot fine. If you try anything larger though, you get this error: (Why it says allowable size between 0MB-2MB is a mystery though. 1MB is the minimum size for all partitions.)
So, other than that install issue, there was nothing of note. Now, in the working system, I did a
yum install xen, and yum pulled down xen & the dependencies and installed them. As part of the install, it also regenerated grub.cfg. So don’t press Ctrl+C even though it looks like yum’s frozen. It isn’t.
One annoyance: The generated file is filled with Xen entries. You can either ignore them, and select Xen 4.1.2, or patch GRUB2 as specified here to get rid of the spurious entries. (No idea when the patched version will go into the repos.)
Next is networking. On my desktop, I have a strange Ethernet driver – it shows up as p34p1. No clue why, and it’s given me no end of trouble, particularly where NetworkManager attempts to seize control despite being specified as “NM_CONTROLLED=NO”.
But that’s neither here nor there. On the testbed, getting networking is trivial, just a matter of creating the bridge definition, and modifying the existing network adapter definition.
In /etc/sysconfig/network-scripts/, the existing file is named ifcfg-<network_adaptor>. (The one other than ifcfg-lo.) In my case, it was
ifcfg-em1. If you have special requirements, I’d recommend Google (which threw up this as the first result, and it seems pretty good), but if you’re using DHCP (if you don’t know what you’re using, chances are you are using DHCP), you just need to add the following to the new file
ifcfg-br0 with your favourite text editor:
DEVICE=br0 TYPE=Bridge BOOTPROTO=dhcp ONBOOT=yes DELAY=0 NM_CONTROLLED=NO
BRIDGE=br0 to your respective network adaptor definition file (i.e.
ifcfg-em1). (With Vim or echo >> file, it doesn’t matter.)
Reboot, and the system seems to be up and running Xen. (Verify with a
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.)