On Sat Feb 05 2000 at 13:51, Ralf Christian Strandell wrote:
> When I try to upgrade my RedHat 6.0 to RH 6.1
> (using graphical upgrade mode) the install program
> freezes when checking for packages to upgrade.
>
> Doing ctrl-alt-F1 reveals:
>
> packages=rpm.findUpgaradeSet( ... )
> rpm.error: error during upgrade check
Never, NEVER use the upgrade option on redhat installs. Yes, it is
supposed to work, but I can tell you from hard core experience (from
dozens of installations) that it just won't work. And even it does,
the end result is an absolute mess.
Believe me, I know. And lots of people in the redhat mailing lists
have said the same.
> Other symptoms:
>
> When running the current RH 6.0 system:
>
> GnoRPM crashes and reports segmentation fault
> when I try to see what packages are installed
> in the _following_ categories:
>
> Application/Internet
> Office/Wordprocessors
> System environment/Libraries
> Utilities/Text
What you are experiencing is exactly the reason why I say NEVER use
the upgrade option. Honestly, I wish redhat would warn people that
they can always expect problems after an upgrade. It has happened
with every new distribution at least since going from RH 4.2 to 5.0.
Going from RH 6.0 to 6.1 is no different.
> What might cause such behaviour and how do I fix this?
> Has the rpm database been trashed somehow?
> Is there a rpm database fix tool?
You have old libraries hanging around, that sort of stuff. I wouldn't
be suprised if you are also running with your old kernel as
/etc/lilo.conf has probably not be updated properly (even if the new
kernel is installed into /boot).
The best thing you can do is to trash your system and start again -
this time with a FRESH install.
> I have RedHat 6.0 with GnoRPM 0.8, enlightenment 0.15.5,
> kde1.1.1pre2...
>
> Ralf Strandell
> [EMAIL PROTECTED]
>
> ps. doing a complete reinstall is NOT an option
With all due respect, bulls**t.
And I'm afraid that it is your only option.
There's a definite strategy with upgrading with a fresh install from a
previous installation. And the strategy starts when planning the
original install in the first place.
Have your /home directory in it's own partition. You DO have this
anyway, yes? Every linux setup (with some exceptions) should have
this. If not, then you have to reorganise your system to have at
least ONE non-system partition to use for storing data.
Yes, that's what to use the /home partition for - storage and backup.
It is the place where all your user's precious data is being stored,
and it needs to be preserved when upgrading. So it is a logical place
to keep any data that needs to be preserved.
Copy ("cp -ar") all of /etc/ in /home/etc to back it up.
Move all of /usr/src/ to /home/src/ and then make /usr/src/ a symbolic
link to /home/src/ (optional - only if you have been building software
there like rpms... you might want to miss the /usr/src/linux*
directories too, especially if you don't need to preserve the kernel
source tree if you happen to have it there).
Do the same for /usr/local if you have done anything there. Although
you might want to be choosey. (Apart from the package that creates it
in the first place, no rpm package should ever put anything into the
/usr/local/ tree -- anything that is install non-rpm like a "make
install" should target /usr/local as the build/install prefix, rather
than /usr/ - so we save /usr/local to preserve anything put in there).
Make a /home/var/ directory and use something like midnight commander
(/usr/bin/mc) to copy anything from /var/ that you might want to keep.
Copy /root/ to /home/root
Save anything else that you have manually installed or tweaked that
live in other places in your system. Apart from what I've mentioned
above, these should be very few and far between - apart from these
places, just about everything should be there due in the first place
from an rpm package and should be replaceable in an instant.
Sometimes it is also a good idea to log some statistics into
/home/var/ somewhere... like saving the output of the following:
fdisk -l /dev/[sh]d[abcd]
free
df
chkconfig --list
cat /proc/interrupts /proc/ioports /proc/dma
rpm -qa
mkkickstart (the output is useful as a reference)
... and so on
Now you can completely trash and rebuild the actual filesystems that
the operating system lives on... / /usr /boot /var or whatever.
So now go ahead and do your INSTALL (not upgrade). Reformat ALL your
partitions -- except for the one with your /home/
After the installation you now have a clean operating system (and a
clean rpm database etc). Now start using an editor and mc again to
edit, tweak, install or replace all your config files (eg, putting
your /home partition back again after replacing the old /home/ftp/ etc
directories with the new ones.
I've used this strategy now for two years to completely rebuild redhat
linux boxes, and it works. I can, for example, trash my own
workstation and rebuild rather painlessly it within a few hours back
to its former glory. Same for all the network server boxes.
(Hint: it's a very good idea when you have your new system up and
running and first log into your user account to delete all your window
manager/gnome/etc config files to force a clean reconfiguration. I
had some weirdness happen when firing up gnome/enlightment with a
fresh rh6.1 with my old rh6.0 config files hanging around).
I use a very similar strategy to do "lightweight" system backups - I
save all the important configuration files (most are in /etc/), /home/
/root/ and selected other parts of the system. Once prepared (eg,
with a shell script), all that needs to be backed up is the /home/
partition. The main operating system can be rebuilt from scratch at
any time, and then reconfigured as previously with what has been
backed up.
Cheers
Tony
-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-
Tony Nugent <[EMAIL PROTECTED]> Systems Administrator
GrowZone OnLine (a project of) GrowZone Development Network
POBox 475 Toowoomba Oueensland Australia 4350 Ph: 07 4637 8322
-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-
