Linode.com Forum

[thoth39]

Hello people.

I've just finished upgrading a test Linode from Fedora Core 2 to Fedora Core 3 without problems, so here goes the instructions.

This was attempted with a fresh Fedora Core 2 image, but step 5 is meant to help those with already deployed systems.

Please read everything before attempting these procedures. There's a known problem.

1) List every kernel package in your machine, looking for 2.4 kernel packages installed.

The FC2 image available for Linodes contain many "ghost" kernel packages; the presence of a 2.4 kernel package in the system will block the installation of the udev package later.

Code: ]# rpm -q --whatprovides kernel

Remove all 2.4 kernel packages.

This first step is not mentioned in other upgrade guides as the presence of a 2.4 kernel in an FC2 system is much unusual.

Also, listing packages with "rpm -q" won't show all these packages installed, and it took me a long time to learn this fact.

2) Obtain the fedora-release-3-8.noarch.rpm package from a Fedora Core 3 base repository.

This package will tell yum what "releasever" we want.

Code: # rpm -Uvh --force fedora-release-3-8.noarch.rpm

This package has irrelevant conflicts, in this context, so we safely --force it in.

3) Obtain the yum-2.0.0-0.fc3.noarch.rpm package from a Fedora Core 3 base repository.

The new yum 2.0 is necessary for the upgrade process; besides, it's the default yum in FC3.

Code: ]# rpm -Uvh yum-2.0.0-0.fc3.noarch.rpm

4) Update the following packages: rpm, python and yum.

Code: ]# yum upgrade rpm python yum

5) List every package not available in the currently configured repositories.

This means every non-Core and non-Extras package won't be immediately available, unless you re-add your custom (now FC3) repositories.

Packages that can't be found in proper repositories may upset the upgrade process.

Code: ]# yum list extras

6) Upgrade!

Code: ]# yum upgrade

Before upgrading you may try listing available packages and stuff, to try the new yum out. It's much faster.

Appendix

Those that switched early to the Fedora Core 2 image (or upgraded with yum) may have met the "BerkeleyDB doesn't like lack of NPTL" bug. Unfortunately, the db4 (version 4.2) package in FC3 still presents this bug.

The usual solution is just to "upgrade" it to a custom built db4 package configured not to use NPTL, but I simply haven't done that yet.

So the above system, with the above bug present, won't let stuff like Subversion work.

If someone has success preparing a RPM for db4 that avoids said bug, PLEASE don't do the same thing as the guy I got the FC2 RPM from, and DO provide the SRPM so we can know what exactly did you do, and perhaps even improve it.

Good luck!

[boyhero]

I followed these steps to upgrade from Fedora Core 2 to Fedora Core 3. Everything seemed to go okay, until I rebooted and tried to login via ssh. It hangs after I enter a correct password. I still haven't been able to find a fix.

Does anyone else have a similar problem?

Thanks

[Jay]

boyhero wrote: I followed these steps to upgrade from Fedora Core 2 to Fedora Core 3. Everything seemed to go okay, until I rebooted and tried to login via ssh. It hangs after I enter a correct password. I still haven't been able to find a fix.

Does anyone else have a similar problem?

Thanks

Are you using a 2.6 kernel?

If so, mv /lib/tls /lib/tls-disabled

[boyhero]

Actually, I believe I am using "Latest 2.4 Series (2.4.290-linode39-1um) kernal. Should I switch it to 2.6 for Fedora Core 3? Sorry if this is a dumb question, I'm a total newbie.

[boyhero]

switched to 2.6 and now I can login! yay!

[raman]

thoth39 wrote: If someone has success preparing a RPM for db4 that avoids said bug, PLEASE don't do the same thing as the guy I got the FC2 RPM from, and DO provide the SRPM so we can know what exactly did you do, and perhaps even improve it.

Here is the bug that contains the whole sordid story:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=91933

I used the RPMs from here (referenced from that bugzilla entry):

http://tomi.nomi.cz/download/db4-no-nptl/

(Note that the db42 RPMs should be renamed to db4 before running the install)

There is also a spec file patch provided in the attachments, but I was not able to get it to apply cleanly to the source RPM. However, the RPMs from the above site worked fine.

Cheers,
Raman

[thoth39]

I'm about to begin the process of upgrading my Linode's system from a new Fedora Core 2 image, through Fedora Core 3, and finally to Fedora Core 4.

With the 1.2.x version of Subversion a filesystem backend is available. No more db4 woes for me.

Wish me luck. I'll post the complete procedure in the Forum later.

MySQL 4.1 anyone?

[thoth39]

Updating to Fedora Core 4 was a total failure.
I suspect the more extensive use of NPTL everywhere makes this an almost impossible task.

In the process of reinstalling my FC3 system, I produced a new version of the db4 package modified to not use NPTL. I attached my patch to the db4.spec file in the above mentioned bug.

Currently, suvbersion with bdb filesystem works, but openldap with bdb backend don't. I solved the openldap problem by using ldbm as backend.

[martino]

thoth39 wrote: Obtain the fedora-release-3-8.noarch.rpm package from a Fedora Core 3 base repository.

This is a stupid question but I cannot find this file anywhere.

The closest I can find is fedora-release-3-8.i386.rpm but this file will not work.

I would really appreciate some pointers in the right direction.

Many Thanks
Martin

[mpoly]

I updated from FC2 to FC3. Things seem to be mostly fine except that BIND does not start. I get:

Jul 24 17:55:08 io kernel: line_ioctl: tty0: ioctl TIOCLINUX called
Jul 24 17:56:28 io last message repeated 2 times
Jul 24 17:56:29 io named[2643]: starting BIND 9.2.5 -u named -d 99
Jul 24 17:56:29 io named[2643]: using 1 CPU
Jul 24 17:56:29 io named: named startup failed

In general the "kernel: line_ioctl: tty0: ioctl TIOCLINUX called" message pops up a lot in my log. Any ideas?

TIA

m

[tronic]

TIOCLINUX message is unrelated.

BIND will write reason why it didn't start up to a logfile.

Do: Code: # grep -r named /var/log
That will do a recursive grep for messages mentioning 'named'.

[mpoly]

After some more digging, I just found that "mv /lib/tls /lib/tls-disabled" fixes the problem. This solution had been already posted earlier in the thread, but I had no problems with ssh initially, so I didn't give it much gravity.

Thanks,

Michael

[Jay]

mpoly wrote: After some more digging, I just found that "mv /lib/tls /lib/tls-disabled" fixes the problem. This solution had been already posted earlier in the thread, but I had no problems with ssh initially, so I didn't give it much gravity.

Please, from now on, if you ask for help, take the given advice.

[mpoly]

That's good advice (and I'll take it) - but it just wasn't obvious (to a linux novice like me, anyway) that another users' problem with sshd had anything to do with my problem with BIND (esp. when my sshd was working just fine).

Regards,

Michael

[Glee]

thoth39 wrote: Updating to Fedora Core 4 was a total failure.
I suspect the more extensive use of NPTL everywhere makes this an almost impossible task.

I tried to install FC4. I first did a minimal install on my machine at home, then copied that to my linode. After making all the usual changes, I still ran into lots of NPTL problems.

I found a message on the uml-user mailing list where someone claimed to get it working. I followed his advice (copying /lib/obsolete/linuxthreads/i686/* to /lib and ln -s libpthread-0.10.so libpthread.so.0), and most things ran pretty well if I booted with init=/bin/bash.

However, trying to boot into single user mode was a horrible failure. I think the binaries in /sbin are statically linked with NPTL (does that make sense?) so running binaries there locked up the system (notably nash and e2fsck), giving an error message: "set_thread_area failed when setting up thread-local storage". Yes, I moved /lib/tls.

I feel like I'm close to getting this working. Anybody have some suggestions on how to fix this?