Re: Hotplug scripts not working... xen/ia64 domU?stopped working

[Horms <horms@verge.net.au>]

Petersson, Mats <mats.petersson@amd.com> wrote:
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com 
>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of 
>> Magenheimer, Dan (HP Labs Fort Collins)
>> Sent: 30 November 2005 14:18
>> To: Ewan Mellor
>> Cc: Xen Mailing List
>> Subject: RE: [Xen-devel] Hotplug scripts not working... 
>> xen/ia64 domU stopped working
>> 
>> > On Tue, Nov 29, 2005 at 08:43:30PM -0800, Magenheimer, Dan (HP Labs 
>> > Fort Collins) wrote:
>> > 
>> > > Somewhere between cset 8006 and cset 8112, the virtual 
>> block device 
>> > > stopped working for Xen/ia64.  With cset 8112, I get:
>> > > 
>> > > Error: Device 769 (vbd) could not be connected. Hotplug 
>> scripts not 
>> > > working.
>> > > 
>> > > Any suggestions where to start looking or will I need to 
>> do a binary 
>> > > search?
>> > 
>> > Please use xen-bugtool (new in the latest changesets) to 
>> collect your 
>> > logs so that I can take a look.
>> 
>> Hmmmm... it appears xen-bugtool is born at 8073.  I can go 
>> back to that but have already reproduced the problem at 8054.
>> 
>> HOWEVER... I am now having problems at 8006 which worked 
>> yesterday.  I suspect that there are some Xen tools/files 
>> that are not getting replaced.  (And xen-bugtool doesn't work 
>> there as one would expect... it is still in place because of 
>> the previous install of 8112 but gives a python error.)
>> 
>> Is there a way to do a "make clean" on all Xen files outside 
>> of the xen-unstable.hg directory to ensure no "old" (or in my case
>> newer) files/scripts from /etc, /bin/ etc are being 
>> accidentally used?  I know others have experienced this kind 
>> of problem and have "fixed" it by reinstalling their distro 
>> from scratch.
> [snip]
> 
> I'd like to see a "uninstall.sh". I did for a short while consider
> writing one myself. I know that most people aren't going to uninstall
> Xen - it's such a lovely product that no one in their right mind would
> uninstall it, right? - but particularly for us developers, it would be
> nice to have something that removes ALL remains of the Xen installation.
> I had severe problems because I tried to install 64-bit Xen on top of a
> 32-bit installation and all sorts of bits and pieces got very confused.
> 
> I think it could actually be constructed based on the install directory
> with some scripting - I'm not that good at writing shell-scripts, or I
> would volunteer to do it myself. [I hacked something up where I just
> took the names of directories listed under the install directory and
> removed all contents of those directories, but that's only going to work
> as long as the files are kept in the same place each time. Yet, it's
> quicker to do that than to run a complete re-install...]

Given that the current install.sh more or less copies what is in
install/ into /, I think that making uninstall.sh work based on what is
in install/ would be quite workable.  Though it might be good to make a
list of what install.sh installs, bassed on what is in install/ at the
time it runs, rather than using what is in install/ at the time that it
runs, as the two may differ.

On a related note, I have a proposed patch to make install.sh cope with
being run as non-root, and cope with customised umasks. When I say cope,
it actually runs just fine, but leaving, for instance, /lib owned
by user.user, mode 700, as happens when I run the existing version
of my self with my usual umask, 0077, is not entirely fun afterwards.

-- 
Horms