Petersson, Mats <mats.petersson@xxxxxxx> wrote:
>> -----Original Message-----
>> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home