Re: Looking Ahead - Upgrade

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Sam Varshavchik wrote:
Rick Stevens writes:

Sam Varshavchik wrote:
Rick Stevens writes:

The only problems you'll ever have will not be as a direct result of the upgrade, per se, but rather the new stuff occasionally not plainly working. I recall one upgrade, I think it was Red Hat 5, that loaded a kernel that had a bug that caused a complete freeze, and that was triggered only on certain hardware, and I won the lottery. That caused a little bit of excitement. Of course, a fresh install won't make much of a difference here.

The rules are pretty simple:

* Do not install stuff manually, cowboy-style. Always use rpm to install software packages, instead of crossing your fingers before running 'make install'.

Not always possible.

Oh? Since when did both emacs and rpmbuild stop working, preventing the creation of an appropriate spec file, and producing the rpm packages?

                       I recently had to put OpenSSL 0.9.8g on a CentOS
5.1 machine to pass a certain certification.  The latest OpenSSL for
CentOS 5.1 is 0.9.8b (farking ancient).  I did it by building it from
a F9-Preview source RPM, building it (with some tweaks as F9 has some
ciphers that CentOS 5.1 doesn't have),

So you were able to install the software via rpm. So your point is…

It was NOT a binary RPM.  It was a heavily tweaked source RPM and would
probably blow up an upgrade.  I won't say that definitively, but it's
bloody likely.


                                       installing the binaries and
poking various symlinks and such to make existing apps happy.

Was there some bugs in emacs that prevented you from putting those symlinks into the spec file?

I don't know. I don't do emacs and I had to get it done at like 2:00 a.m. to meet a deadline. I buggered the spec with vi and did some
rebuilds.  It was dark, they were big....

                                                               So, Rule
1 can't ALWAYS be adhered to, no matter how "stock" you want your system
to be.

Well, in 13+ years I've managed to adhere to the rule without much of a problem. And that included patching out the kernel bug I referenced in my previous message.

* Know your software. If you're running MySQL or Postgres, dump your database before the upgrade. Major dot-releases of Postgres will often refuse to boot up with the previous release's database. You'll need to nuke your entire DB, start Postgres and have it initialize a fresh DB, then load your dump. Other major software packages may have their own idiosyncrasies.

The fact you've had good luck in upgrades is (to be honest) a bit
anecdotal.  There have been many, MANY people with completely stock
systems that have crashed and burned BIG time.  Even Red Hat doesn't
recommend an upgrade more than 2 revs up (e.g. F7-->F9).

Well, I gues I've been lucky then, upgrading from one release to another, for 13+ years, with multiple machines containing wide varities of hardware.

Yes, you have.  And this wasn't meant to start a flame war.  All I'm
saying is that yes, it sometimes works (perhaps more often than not),
but sometimes it ends up as a smoking hole in the ground.  Be careful.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer                       rps2@xxxxxxxx -
- Hosting Consulting, Inc.                                           -
-                                                                    -
-    "Hello. My PID is Inigo Montoya.  You `kill -9'-ed my parent    -
-                     process.  Prepare to vi."                      -
----------------------------------------------------------------------

--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux