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

@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

Are you using a 2.6 kernel?

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

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.

switched to 2.6 and now I can login! yay!

@thoth39:

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/sh … i?id=91933">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

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?

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.

@thoth39:

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

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

TIOCLINUX message is unrelated.

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

Do:````

grep -r named /var/log

````
That will do a recursive grep for messages mentioning 'named'.

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

@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.

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

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

@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.
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: "setthreadarea 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?

@Glee:

Anybody have some suggestions on how to fix this?

I know this sounds trollish… but, how about installing a distro that doesn't do stupid things like statically compile vital system bins with anything but regular i386 flags.

The upgrade to Fedora Core 4 was a success in a Xen node.

My report is in the "Xen Public Beta" forum.

No db4 hacks necessary. :)

I'm attempting to upgrade my linode from FC2 to the current version, I found instructions at

~~[http://www.brandonhutchinson.com/UpgradingRedHatLinuxwithyum.html" target="blank">](http://www.brandonhutchinson.com/Upgrad … h_yum.html">http://www.brandonhutchinson.com/UpgradingRedHatLinuxwith_yum.html](

and everything goes good, but when I do " yum -y upgrade" I get this:

> –-> Package tar.i386 2:1.15.1-17.FC5 set to be updated

---> Package sed.i386 0:4.1.5-5.fc5 set to be updated

---> Package rhnlib.noarch 0:2.0-1.p24.3.1 set to be updated

---> Package system-config-network-tui.noarch 0:1.3.30-2.1 set to be updated

---> Package aspell-en.i386 50:6.0-2 set to be updated

---> Package glibc.i686 0:2.4-11 set to be updated

---> Package gettext.i386 0:0.14.5-3 set to be updated

---> Package openssh-clients.i386 0:4.3p2-4.11.fc5 set to be updated

---> Package libwvstreams.i386 0:4.2.1-2 set to be updated

---> Package portmap.i386 0:4.0-65.2.2 set to be updated

---> Package jwhois.i386 0:3.2.3-8.fc5 set to be updated

---> Package crontabs.noarch 0:1.10-8.fc5 set to be updated

---> Package pcre.i386 0:6.3-1.2.1 set to be updated

---> Package pax.i386 0:3.4-1.2.1 set to be updated

---> Package rsync.i386 0:2.6.9-2.fc5 set to be updated

---> Package filesystem.i386 0:2.3.7-1.2.1 set to be updated

---> Package logrotate.i386 0:3.7.3-2.2.1 set to be updated

---> Package bzip2.i386 0:1.0.3-2.2.1 set to be updated

---> Package rpm.i386 0:4.4.2-15.2 set to be updated

---> Package chkconfig.i386 0:1.3.29-1 set to be updated

---> Package rdate.i386 0:1.4-4.2.1 set to be updated

--> Running transaction check

--> Processing Dependency: libuuid.so.1 for package: parted

--> Processing Dependency: libuuid.so.1 for package: util-linux

--> Processing Dependency: pkgconfig for package: nfs-utils

--> Processing Dependency: libaudit.so.0 for package: shadow-utils

--> Processing Dependency: gtk2>= 2.4.0 for package: libgcj

--> Processing Dependency: libsepol.so.1 for package: parted

--> Processing Conflict: glibc conflicts kernel< 2.6.9

Traceback (most recent call last):

File "/usr/bin/yum", line 8, in ?

yummain.main(sys.argv[1:])

File "/usr/share/yum-cli/yummain.py", line 104, in main

(result, resultmsgs) = base.buildTransaction()

File "/usr/lib/python2.3/site-packages/yum/init.py", line 174, in buildTransaction

(rescode, restring) = self.resolveDeps()

File "/usr/lib/python2.3/site-packages/yum/depsolve.py", line 190, in resolveDeps

(checkdep, missing, conflict, errormsgs) = self._processConflict(dep)

File "/usr/lib/python2.3/site-packages/yum/depsolve.py", line 492, in _processConflict

uplist = self.up.getUpdatesList(name=confname)

UnboundLocalError: local variable 'confname' referenced before assignment

Any ideas?

Thanks for the Help!

Reboot with a 2.6 kernel? [Change the kernel in your Configuration Profile in the new-fangled Linode Dashboard, and reboot.]

Cliff