[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Savannah-hackers-public] Next Savannah VM system upgrade - internal

From: Bob Proulx
Subject: Re: [Savannah-hackers-public] Next Savannah VM system upgrade - internal
Date: Wed, 3 Apr 2013 13:43:02 -0600
User-agent: Mutt/1.5.21 (2010-09-15)

Bob Proulx wrote:
> Problem 2:
>   internal:~# dpkg-reconfigure grub-pc
>   /usr/sbin/grub-probe: warn: disk does not exist, so falling back to 
> partition device /dev/xvda2.
> ...
> I imagine this problem is due to it being a Xen domU.  The previous VM
> mgt doesn't have grub installed.  I chatted with Ward and he says that
> the dom0 will bootstrap the xen domU based upon the presence of the
> menu.lst file.  Therefore I think internal needs the same treatment as
> mgt.  Meaning that I think grub needs to be purged off leaving only
> the menu.lst file for the dom0 to boot.

This has been done.  The grub* packages were purged.  Because grub-pc
(aka grub 2) wasn't functional at all.  I saved a copy of the menu.lst
file off first just in case.  But I wasn't paranoid enough and had a

I didn't like the idea of having menu.lst be only updated manually.
The problem is with grub2.  I therefore tried grub-legacy (aka grub 1).
Which seems like it will work and keep menu.lst updated.  I think it
will be just fine.  Eventually.

But... and there is always a "but" the file isn't generated
correctly by grub-mkdevicemap.  And that filtered through to the new
menu.lst file that I created with the grub-legacy version of
update-grub.  Among the other differences I didn't catch the
difference before rebooting.  The root was /dev/xvda2 instead of hd0.
The machine went down but did not come back up due to the error in

Internal was down for from about 12:25 -0600 until about twenty
minutes later.  Ward was our guardian angel and rescued the system.
Thanks Ward!

I still think menu.lst needs to be updated automatically as upgrades
are applied.  I am going to continue to work that problem.  But for
the moment I am going to let internal sit and call it good for now.
Since internal seems to be critical for vcs access.  I will focus on
this problem on a different VM and then transport the eventual
solution back to internal later.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]