Positive experience updating Dom0 from f14/2.6.32/4.0.2 to f15/2.6.40/4.1

[Bill McGonigle]

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

-- 
Bill McGonigle, Owner
BFC Computing, LLC
http://bfccomputing.com/
Telephone: +1.855.SW.LIBRE
Email, IM, VOIP: bill(a)bfccomputing.com
VCard: http://bfccomputing.com/vcard/bill.vcf
Social networks: bill_mcgonigle/bill.mcgonigle

[Pasi Kärkkäinen]

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

Grubby fix isn't enough for Fedora 16: Fedora 16 uses Grub2

[Marko Ristola]

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

Grubby fix isn't enough for Fedora 16: Fedora 16 uses Grub2

[Pasi Kärkkäinen]

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

Grubby fix isn't enough for Fedora 16: Fedora 16 uses Grub2

[Jerry Amundson]

On Tue, Aug 16, 2011 at 1:26 PM, Pasi Kärkkäinen <pasik(a)iki.fi&gt; 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

Grubby fix isn't enough for Fedora 16: Fedora 16 uses Grub2

[Marko Ristola]

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

[Bill McGonigle]

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

-- 
Bill McGonigle, Owner
BFC Computing, LLC
http://bfccomputing.com/
Telephone: +1.855.SW.LIBRE
Email, IM, VOIP: bill(a)bfccomputing.com
VCard: http://bfccomputing.com/vcard/bill.vcf
Social networks: bill_mcgonigle/bill.mcgonigle