Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Destructive removal of custom programs|
|Product:||[Retired] Red Hat Linux||Reporter:||dgodbey|
|Component:||installer||Assignee:||Matt Wilson <msw>|
|Status:||CLOSED ERRATA||QA Contact:|
|Fixed In Version:||1.0-4.fc8||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2007-12-06 15:49:13 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description dgodbey 2000-05-12 13:32:43 EDT
When upgrading from RH6.1 to RH6.2, all custom packages and their config files were erased from /usr/local. Specifically, Apache (and all config files), Acrobat4.0, and several other major packages that were installed in /usr/local were removed totally. If my Oracle 8i wasn't on a mount point, it would have been removed as well. I also had an installation of Active Perl in /bin that was also removed. I was under the impression that upgrading a system didn't remove or impact anything except the specific files included in the package. And, if other package versions were installed in 'non-standard' locations, they would be left alone. Fortunately, I have install RPM's of most of the stuff that was removed as well as download versions of the other packages. However, the specially written code in /usr/local/bin that the developer's did not have a backup for is gone. You have made a great product that works like a dream, but this kind of problem will impact the newbie and cause unfavorable press. We have enough to handle without having to deal with this kind of problem, too.
Comment 1 Matt Wilson 2001-01-26 20:57:49 EST
were these packages managed by RPM? Or just located in /usr/local?
Comment 2 dgodbey 2001-01-29 12:28:53 EST
The programs were developed by local programmers and were stored in /usr/local/bin with support libraries in /usr/local/lib. None of the files deleted were managed by RPM. It seemed that all file data in /usr/local/* was deleted even though the process used was an upgrade and not an install. Also, the file systems were not changed or reformated at the time of the upgrade.
Comment 3 Matt Wilson 2001-01-29 12:43:07 EST
I've never heard of a problem like this one. The upgrade process doesn't touch /usr/local at all. Could you attach your /tmp/upgrade.log?
Comment 4 dgodbey 2001-02-27 22:31:47 EST
No. I no longer have access to that system. It was strange, though. I had Active Perl loaded in /bin that was removed, along with other packages that weren't in the RedHat mix. I guess, though, since 7.0 was released, that the problem is now masked and unduplicate-able. It could have been a fluke, but without the logs it's impossible to prove or find out what actually happened. I still have the release CD's in hand and I guess I could play around with it. I have rel 5.2, 6.0, 6.1, 6.2 and 7.0 onhand so I'll see if I can duplicate the hit. I'll let you know in a week or two.
Comment 5 Michael Fulbright 2001-02-28 10:24:46 EST
Comment 6 Michael Fulbright 2001-04-11 11:35:09 EDT
Please reopen this report if you have anything new to add.
Comment 7 dgodbey 2001-04-11 12:59:25 EDT
I have been unable to duplicate the failure on my current mix of systems (Compac EN, A550, HP Vectra VE, HP Kayak XA, and others both single CPU and SMP). I have attempted to duplicate the full range of upgrades including massive steps in versions (5.2 directly 6.2) and haven't experienced the same problem. For the most part, the content of /usr/local/* remained untouched. The only problems I encountered were expected (system resource types of things like memory, BIOS, etc.). I had a couple of driver problems with an old DEC PC, but that was easily taken care of with a BIOS update. The process I followed was basically this: Started with a "new" install of 5.2 and followed that with "normal" release step updates up to 6.2. I installed a fresh copy of Active Perl at each release level and ran a few application tests and configurations with XFree86 and X. I let each level run for a minimum of 10 days to insure logging and kernel processes were fully functional before moving to the next release level of RH. Fortunately, since I now work for BMC Software as a Staff QA Rep, I have extensive access to platforms and systems. Talk about a playground! WHEE! The end result is, with all the tools and systems at hand, I was totally unable to get an installation failure of the type I originally reported. To say I had a ball doing this would be a massive understatement. I even had IBM 5L involved as a side issue test and managed to get IBM involved in some things I found there. I was on a major roll! :) Thanks for the excuse to go play!
Comment 8 Fedora Update System 2007-12-06 15:49:11 EST
libxcb-1.0-4.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
Comment 9 jdavidb 2008-07-30 16:54:40 EDT
libxcb-1.1-1.fc8.i386.rpm breaks what libxcb-1.0-4.fc8 fixed. I don't believe this was the right bug for that package, though, although for some reason the original release notes for libxcb-1.0-4.fc8 reported this bug number. That would appear to be a mistake.