Just some notes, in case others are planning similar upgrades.
I was running 2.6.32 from M. Young's repo. My goal was to get up to 2.6.40 on Fedora 15 (mainline dom0!) with minimal downtime.
I found that f15's version of Xen (4.1) wouldn't run, even after re-compiling on f14. So, that couldn't be staged ahead of time. As a retreat plan, I made sure to have rpm's for Xen 4.0.2 handy, but they wound up being unnecessary.
I knew there'd be some xend breakage during the upgrade, so I opened ssh sessions to each VM.
I then started the yum upgrade, first with yum and rpm, then only the fedora and updates repos, then other repos. Some package upgrade problems needed to be solved (I have too much in dom0), but nothing worse than usual.
Once all the upgrades were in place, I hand-edited grub.conf since the new kernel installed a non-Xen entry.
At this point, I should have checked to see that my initramfs was made properly (it wasn't, locally packaged zfs modules broke the scriptlet). I had to come back in with rescue mode to re-run dracut.
Once all the updates were installed, I shut down each of the VM's using native 'shutdown -h now' inside the vm. xm shutdown was broken at this point.
Now, the only ugly part is that systemd wasn't yet running, but 'reboot' is replaced. So, to reboot the system, I had to do 'sync;sync;sync [reset button]'. I had filesystems mounted -o data=journal, so I was at least feeling good about consistency. Some people wouldn't tolerate this option, but it worked out OK for me.
With a working initramfs, the system came up just fine, the VM's started as they should, and everything seemed OK from the Xen perspective. All the domU's function, no domU updates required (Fedora 12/13/14, CentOS 5).
If I had noticed the initramfs problem properly, I would have gotten away with only about a 4 minute outage. Quite glad to be re-united, after many years in the Fedora/Xen exile community! Much kudos to Michael Young, Pasi, and all the others who have helped up through the dark times.
-Bill
On Mon, Aug 15, 2011 at 06:54:32PM -0400, Bill McGonigle wrote:
Just some notes, in case others are planning similar upgrades.
I was running 2.6.32 from M. Young's repo. My goal was to get up to 2.6.40 on Fedora 15 (mainline dom0!) with minimal downtime.
I found that f15's version of Xen (4.1) wouldn't run, even after re-compiling on f14. So, that couldn't be staged ahead of time. As a retreat plan, I made sure to have rpm's for Xen 4.0.2 handy, but they wound up being unnecessary.
Hmm.. I'm running xen-4.1.1-2.fc15 on f14.. recompiled, of course, and it works for me..
I knew there'd be some xend breakage during the upgrade, so I opened ssh sessions to each VM.
I then started the yum upgrade, first with yum and rpm, then only the fedora and updates repos, then other repos. Some package upgrade problems needed to be solved (I have too much in dom0), but nothing worse than usual.
Once all the upgrades were in place, I hand-edited grub.conf since the new kernel installed a non-Xen entry.
We need to get the grubby patch in to handle the dom0 entries..
At this point, I should have checked to see that my initramfs was made properly (it wasn't, locally packaged zfs modules broke the scriptlet). I had to come back in with rescue mode to re-run dracut.
Once all the updates were installed, I shut down each of the VM's using native 'shutdown -h now' inside the vm. xm shutdown was broken at this point.
Usually when upgrading Xen I first shut down the VMs, then upgrade dom0, reboot, and restart VMs.
Now, the only ugly part is that systemd wasn't yet running, but 'reboot' is replaced. So, to reboot the system, I had to do 'sync;sync;sync [reset button]'. I had filesystems mounted -o data=journal, so I was at least feeling good about consistency. Some people wouldn't tolerate this option, but it worked out OK for me.
Heh :)
With a working initramfs, the system came up just fine, the VM's started as they should, and everything seemed OK from the Xen perspective. All the domU's function, no domU updates required (Fedora 12/13/14, CentOS 5).
Good.
If I had noticed the initramfs problem properly, I would have gotten away with only about a 4 minute outage. Quite glad to be re-united, after many years in the Fedora/Xen exile community! Much kudos to Michael Young, Pasi, and all the others who have helped up through the dark times.
Thanks! There's still more patches to be merged in for 3.x, so remember to read the kernel changelogs or http://wiki.xen.org/xenwiki/XenParavirtOps and upgrade later :)
All the "big" changes are already in mainline Linux, and it seems to work pretty OK, so it's good to continue from here.
-- Pasi
Hi
I've experimented with a fresh Fedora 16,
I've installed Fedora 16 from nightly CD. Fedora 16 uses Grub2, so grubby fix isn't enough for dom0. Grub2 has Xen Dom0 config script as /etc/grub.d/20_linux_xen on Fedora 16. The script searches initrd-* files from /boot. It should search initramfs-* files too. Thus Dom0 will not be able to boot. I've written a bug report about that, maybe it is against Rawhide now, with a patch to apply.
Another problem on Fedora 16 seems to be that while yum installs a new upgraded kernel, Xen Dom0 rows will not get generated. I don't know why. If /etc/grub.d/20_linux_xen works okay, grub2 config can be easilly fixed afterwards by hand with grub2-mkconfig.
I've learned to switch from Grub1 to Grub2 with BIOS boot (not EFI). One way is to move partitions down so that there is 1MB or more disk space outside of partitions, just at disk start.
Switching to grub2 isn't easy. Better plan and prepare or start from an empty hard disk before switching to grub2: Fresh Fedora 16 install into an empty hard disk (without partitions) does it all for you (creates a "BIOS boot partition", which is an alternative to "1MB outside partition space").
Marko
On Tue, Aug 16, 2011 at 09:03:19PM +0300, Marko Ristola wrote:
Hi
Hello,
I've experimented with a fresh Fedora 16,
Thanks for testing! I need to install F16 myself aswell..
I've installed Fedora 16 from nightly CD. Fedora 16 uses Grub2, so grubby fix isn't enough for dom0. Grub2 has Xen Dom0 config script as /etc/grub.d/20_linux_xen on Fedora 16. The script searches initrd-* files from /boot. It should search initramfs-* files too. Thus Dom0 will not be able to boot. I've written a bug report about that, maybe it is against Rawhide now, with a patch to apply.
bz url?
Another problem on Fedora 16 seems to be that while yum installs a new upgraded kernel, Xen Dom0 rows will not get generated. I don't know why. If /etc/grub.d/20_linux_xen works okay, grub2 config can be easilly fixed afterwards by hand with grub2-mkconfig.
I've learned to switch from Grub1 to Grub2 with BIOS boot (not EFI). One way is to move partitions down so that there is 1MB or more disk space outside of partitions, just at disk start.
Switching to grub2 isn't easy. Better plan and prepare or start from an empty hard disk before switching to grub2: Fresh Fedora 16 install into an empty hard disk (without partitions) does it all for you (creates a "BIOS boot partition", which is an alternative to "1MB outside partition space").
-- Pasi
On Tue, Aug 16, 2011 at 1:26 PM, Pasi Kärkkäinen pasik@iki.fi wrote:
On Tue, Aug 16, 2011 at 09:03:19PM +0300, Marko Ristola wrote:
Hi
Hello,
I've experimented with a fresh Fedora 16,
Thanks for testing! I need to install F16 myself aswell..
Me too! Though I may until the Alpha is out next week...
I've installed Fedora 16 from nightly CD. Fedora 16 uses Grub2, so grubby fix isn't enough for dom0. Grub2 has Xen Dom0 config script as /etc/grub.d/20_linux_xen on Fedora 16. The script searches initrd-* files from /boot. It should search initramfs-* files too. Thus Dom0 will not be able to boot. I've written a bug report about that, maybe it is against Rawhide now, with a patch to apply.
bz url?
https://bugzilla.redhat.com/show_bug.cgi?id=728775
jerry
On 08/16/2011 09:26 PM, Pasi Kärkkäinen wrote:
Thanks for testing! I need to install F16 myself aswell..
I used VESA mode with the Fedora 16 Live CD. Modesetting with Radeon didn't work. Live CD install first crashed, but didn't crash at 2nd try. After reboot, I switched into another VT, because initial "welcome, add users" didn't show up. I turned off gpg checks from /etc/yum.repos.d: GPG keys for Fedora 16 were missing under /etc/pki/...: bad soft links.
I turned off Rawhide repository. I upgraded Fedora 16 from the command line. Then reboot.
After that Fedora 16 "welcome, add users" started up graphically: works as it should. I could go back to modesetting from VESA by moving /etc/X11/xorg.conf away and changing /etc/default/grub's Kernel parameters: remove nomodeset. grub2-mkconfig -o /boot/grub2/grub.cfg will rebuild grub2 configurations.
Then basic Fedora 16 works.
Marko
On 08/16/2011 04:09 AM, Pasi Kärkkäinen wrote:
Hmm.. I'm running xen-4.1.1-2.fc15 on f14.. recompiled, of course, and it works for me..
odd, that's what I tried (just rebuilt from the .spec). I got:
"Exception starting xend ((13, 'Permission denied'))"
starting xend, which I read is the common error message on version mismatches. I reinstalled the 4.0.2 version and xend started OK.
Usually when upgrading Xen I first shut down the VMs, then upgrade dom0, reboot, and restart VMs.
I agree that's safer. In this case it was about a 4 hour yum upgrade, so it wasn't really an option for me.
Thanks! There's still more patches to be merged in for 3.x, so remember to read the kernel changelogs or http://wiki.xen.org/xenwiki/XenParavirtOps and upgrade later :)
Yeah, I've been looking with interest at the memory ballooning improvements going in, and wondering if the f15 branch will see a 3.1 (err, 2.6.41) kernel before it's all said and done. Will we need a Xen update for that as well, or is the current version feature-complete in that area?
-Bill
xen@lists.stg.fedoraproject.org