[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
problem.
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 device.map 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
menu.lst.
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.
Bob