Up2date, Fedora Core1, and a newbie...

[John Collier]

I have finally managed to get and extra box to load the new Fedora Core on. This may not seem like much to most of you, but this is also my first load of Linux and the first step in getting my house away from M$ Windoze. So far, things have gone pretty good.

The box is a mere Pentium 200 with a whole whopping 96 MG of RAM. Needless to say, nothing really happens fast on this box. The load it's self took about 1.75 Hrs in text mode!

While I have made it through most of the challenges without much more hair loss, I have now found myself up against the interesting experience of the up2date program. It seemed rather simple from the beginning, but now it has me somewhat stumped and I have to think that I may have done some thing wrong.

Up to this point I have launched the up2date program, picked the applications that I want it to update for me, and even got it to download all of the packages to do the updates. All of this was done through the GUI interface since I am still learning how to use the BASH shell and am not comfortable with doing it all through the CLI. So far, so good.

What concerns me right now is that it has been sitting on the 'Installing Packages' screen for several hours now and looks as if it isn't going to be doing much of anything if I just leave it alone. Since this was all done through the GUI and I don't know anything about where these files are and if they will still be there after a reboot or not, I have hesitated to do anything at all. I have to do something because I can't just leave it on this task forever.

To all of the people out there with more experience than I have, what would you do if you were in my place? What is the best 'next step'?

Thanks,
John

[Stuart Browne]

Well, it shouldn't take too long, there's only a few hundred packages updated.

I'd be going to a shell, and checking the process list for 'rpm' commands (I can't recall if the GUI just exec's them or uses the rpmlib's). If you can't see any, just use a 'rpm -qa' and see if RPM is locked.

If it's not, and it's still not going anywhere (it is possible that it's just dumb), kill off the GUI, and run it from the command prompt:

up2date -u

It will utilize packages that have already been downloaded, so there isn't any time wasting.

In future though, you might find it easier to use 'yum'. It's interface is very simple (yum update), and does the same things. But these are CLI stuff, not GUI.

Congratulations on getting this far John, and good luck to you!

[Stuart Browne]

Oh, as for getting comfortable with the bash shell, you can make it behave pretty 'ksh'-ish if you want. Don't forget that 'set -o vi' is possible, just like ksh.

[John Collier]

Stuart,

Please don't misunderstand. It's not that I'm against using the CLI, I just don't know all of the little ins and outs of it at this time. I would be more than happy to use it if I can just get the syntax correct.

I tried your suggestion of 'up2date -u' and the result I get is a window that says:

"Your GPG keyring does not contain the Red Hat, Inc. public key.
Without it, you will be unable to verify that packages Update Agent downloads
are securely signed by Red Hat.

Your Update Agent options specify that you want to use GPG.

Install key?"

I click on the 'Yes' button and it proceeds to chew on the HDD and then the CLI gives me the message:

"GPG keyring does not include the Red Hat, Inc. public package-signing key"

Thinking that I have already installed the key using the previous pop-up window, I try the command again and I go back through the same circle of events all over again.

What does this mean to me in the long run? Is this key mentioned that important? Why won't it install it when I tell it that I want to do so?

Thanks,
John


P.S. Thanks for the congrats. I knew this day would come sometime. I just hope that I can make the forward progress that I want as quickly as I want. I'm getting pretty tired of all of M$'s big-brother-like behaviour...

[Stuart Browne · Accepted solution]

RedHat sign all of it's packages with a GPG key.

I thought that fedora distributed the most up-to-date keys in the distribution, but it's possible that it does not.

There are listed solutions to the problem, which have to do with up2date not importing the correct keys. Do these two commands:

rpm --import /usr/share/rhn/RPM-GPG-KEY
rpm --import /usr/share/rhn/RPM-GPG-KEY-fedora

This should fix the issues with both the command line, and the gui up2date clients.

[Bruce Copeland]

John:

A couple of other observations:

1) The 96 M of RAM may have a lot to do with the problems you're encountering. I just installed Fedora Core 1 on a friend's box that only had 128 M at the time of installation/up2date. I set the box up with 600 M of SWAP because there was plenty of hard disk space, and I knew the memory was going to get upgraded to 256 or 384 M soon. Even so, the Installing Packages phase took 1.5 hours. I've previously installed Fedora on another slower machine with more RAM, and Installing Packages only took about 15 min. The first time you update core 1, there are usually a lot of packages to install. It makes sense that RAM would make a BIG difference. If you continue to have problems, you might need to install only subsets of your packages at a time.

2) The Red Hat Fedora Core update site is notoriously flaky because there isn't enough bandwidth to meet demand. I've seen the site hang at several different places in the up2date process. Most of us configure up2date (or yum) to use one of the mirrors.

Bruce

[John Collier]

Stuart,

You are once again my hero (you may not know it but I have been lurking in these forums for a long time and soaking up as much as I could in the process). Your suggestions have resolved my issues in short order.

I intend to become much more familiar with the CLI in the weeks/months to come. I know that the GUI is NOT the way to accomplish most things. Just like anything else, it will just take time.

If I come in here asking what seem like really strange, simple questions please be patient with me. I don't always get the results I would like to through the web searches.

Just for my own understanding, just exactly what did those two lines for the 'rpm' command do? It looks like they may have imported keys directly from an outside source, but that doesn't seem as if it should be possible since there is no actual web address shown (IP or otherwise). I'm not sitting at the box right now, so I can't check to see if they are local folders or not. If they are local, then why was it required to basically force them into the system when they were already on the drive?


Bruce,

I am well aware of the limitations that I will have with such a little box on this load. I have read the FMs on this and know that they recommend nothing less than 128 MG for text alone and 256 for the graphics. I really don't expect this to remain a production box. This is really just my sandbox so that I can get things like Samba and Wine up and running and become more comfortable with the environment all together.

When this all gets ironed out, there won't be any box in the house that will be under the recommended specs. As a matter of fact, the server for the house will be running the 64 bit version on an Opteron based system with no less than 1 GIG of RAM (I'm looking forward to seeing that!).


Thanks for the input from both of you. It's nice to see that even a self proclaimed newbie isn't shunned in this group.


Regards,
John

[Stuart Browne]

Lets just call it a bug in the RedHat/Fedora translation.

Basically, the initial key was correctly applied automatically, but the '-fedora' key was not.

Technically speaking, you probably didn't have to do *both*, but hey! why not! They're just ASCII-armored keys on the local disk, available to be imported/applied to a GPG key-ring.

My thought is that they should have been pre-applied to the distributed keyring, but *shrug* I'm just a user :P