[OpenAFS] problems with de-installing OpenAFS 1.5.x on windows
Fri, 23 Sep 2011 08:46:50 -0400
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
Content-Type: text/plain; charset=UTF-8
On 9/23/2011 3:00 AM, Lars Schimmer wrote:
> I experienced some heavy problems with deinstalling the 64bit package o=
> OpenAFS 1.5.x on our windows 7 workstations.
> While/after deinstalling the 64bit package (MSI) of OpenAFS 3 (out of 6=
> I tried) workstations did no more accept any admin user as
> administrator, the service to start the services did not start and
> furtheron I can onl reinstall complete system to get it working again a=
> I do not obtain any right to administrate the system or start any
> servive =3D> I cannot deinstall/install any software, I cannot remove i=
> from the domain, I can just logon/logoff and copy data to/from harddriv=
> Has anyone experienced and similar?
> (the workstations were setup in last/this year, are in a domain,
> upgrading OpenAFS did worked well on them, I was login as a local
> administrator while deinstalling the OpenAFS 64 MSI package,...).
> Somehow it looks like the registry is destroyed in a very bad manner.
> And this has happen on 3 workstations yet (out of 6 I tried to deinstal=
> OpenAFS 1.5.x for installing 1.7).
> Lars Schimmer
While your situation sounds horrible I have a hard time believing it is
the result of OpenAFS itself being uninstalled. If that were the case I
would run into the problem on a consistent basis as I switch between
release series. OpenAFS does not add itself as a dependency for other
My guess is that one of two things are true:
a. the local administrator account has somehow obtained a dependency on
the \\AFS name space perhaps with an auto-run or other and as a result
will not start because after OpenAFS is removed there is no method of
accessing the dependency.
b. your machines have a rootkit or other damage and the removal of
OpenAFS is triggering bad behavior.
The 1.5 series does not have any kernel component and is not capable of
altering the role of administrative bits.
I would start by examining the registry for dependencies on \\AFS. For
example, are there any system drive mappings to \\AFS that would be
persisted? Any service application paths that refer to \\AFS or a
mapped drive letter? Etc.
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
-----END PGP SIGNATURE-----