I'm trying to upgrade from Fedora Core 3 to Core 5. Unfortunately, my installation of Firefox seems to have a bug in it, in that I can't download a file without crashing it. This means that I also can't download Opera, or anything else. I've attempted getting the *.iso files via Bittorrent on my Windows machine, then dragging them over on the network, but I can't get the sha1sum to match on them. The most shocking thing is that I don't even have lynx installed, so I have no way to download files at all from the web.

I don't know what to do at this point, except try FTP.

[Update a few minutes later]

Weirder and weirder. Every time I do a sha1sum on the disk1 iso, I get a different result. What is that all about?

[Update about 10:30 AM EDT]

OK, I seem to have wget. But what is the explanation for my sha1sum problem? If sha1sum isn't giving reliable results, how can I know if I got a clean download?

[Update about 11:16]

Well, I'm wgetting the first two discs, and I'll see if they work. Sha1sum is now giving consistent results (have no idea what was going on earlier), but consistently wrong, so I know the one I got yesterday is fubar (I burned a disk with it, and it failed testing). I'll see what happens with these new versions I get via wget.

[Update about quarter till twelve noon]

OK, the wget downloads for discs 1 and 2 seemed to work, and I'm getting consistent sha1sums now (don't match on yesterday's, do match on today's). I guess I'll chance burning the disks with these. What concerns me is that I originally downloaded them a couple months ago, when Core 5 came out, and they checked out fine at that time (I just hadn't gotten around to burning the disks). I am afraid that I'm having hard disk problems that corrupted them in the interim.

[Update at 2:30]

Uh oh.

When I checked the downloads they were all fine, and consistently showed the right sha1sum. I burned the disks, and rebooted. Once again, they all had errors on them. When I rebooted, and rechecked the sha1sums in today's downloads, they're coming up inconsistent--no same result twice.

I guess I'd better take the machine down and check all the drive connections. I'm also backing it up to another drive that I keep in the machine, but is usually unmounted. I may have to switch over to that one, and do a clean install.

Try 'wget' or 'lynx' to get the files....

You might try backing up your data (bookmarks, etc.) and un-installing, then re-installing Firefox. I had an old Netscape browser that did that to me, and a reinstall corrected the problem. Some hiccup in the first install loaded properly the second time.
OTOH, if you're on DSL then FTP download will probably take much less time.

I don't have lynx...

How does wget work?

Here is the man page for wget:

NAME
Wget - The non-interac@tive network downloader.

SYNOPSIS
wget [option]... [URL]...

GNU Wget is a free utility for non-interac@tive download of files from the Web. It supports HTTP, HTTPS, and FTP protocols, as well as retrieval
through HTTP proxies.

Wget is non-interac@tive, meaning that it can work in the background, while the user is not logged on. This allows you to start a retrieval and
disconnect from the system, letting Wget finish the work. By contrast, most of the Web browsers require constant user’s presence, which can be a
great hindrance when transferring a lot of data.

Wget can follow links in HTML and XHTML pages and create local versions of remote web sites, fully recreating the directory structure of the origi-
nal site. This is sometimes referred to as ‘‘recursive downloading.’’ While doing that, Wget respects the Robot Exclusion Standard (/robots.txt).
Wget can be instructed to convert the links in downloaded HTML files to the local files for offline viewing.

Wget has been designed for robustness over slow or unstable network connections; if a download fails due to a network problem, it will keep retry-
ing until the whole file has been retrieved. If the server supports regetting, it will instruct the server to continue the download from where it
left off.

OK, if you get bad results from sha1sum, then you do not know if you have a clean/good iso image. You can do the self check wqhen you boot the install DVD or the first CDROM. If the self check is good, ignore the bad sha1sum results.

You could consider doing an http or ftp network install but if you have low bandwidth, that might not work.

Once you have a good install, try using "yum" to do updating.

From the command line do:
yum remove firefox

and then do
yum install firefox

You will get the latest update of firefox rather than the one from the original distribution.

Wrong results on sha1sum is worrisome; variable results on it is really strange. That strongly implies you aren't getting the same bytes every time you read that file. My guess is that you have either physical hardware problems, or driver problems on your current install, and you'll be lucky to get anything stable.

If you run sha1sums on random files, do you get the same results every time (for a given file, I mean)?

My guess is that you have either physical hardware problems, or driver problems on your current install, and you'll be lucky to get anything stable.

That's interesting (and concerning) because every time I reboot the machine, even though it had a clean shutdown, it almost always thinks it was an unclean one, and I almost always have to run fsck manually, with many errors to be fixed, to get it to come up. It's got a relatively new (one year old) drive in it.

Back up all your files to brand new media immediately. The last time I saw checksums that changed from read to read, my whole hard drive was in the process of dying.

If you're getting changing checksums then your data is already being corrupted, but the sooner you get the data moved the less damage will have been done.

The most likely reason that you were getting different results from sha1sum is that the files were changing - since you mentioned a crash, most likely the browser gui crashed but there was still a process in the background writing data to the files. What a mess!

Why do you have Fedora problems every time I turn away for a day? Just had a knee surgery and voila, Rand's in trouble.

I see the blogosphere was on the ball, though I prefer curl to wget. But before we get to that, memtest86. I am VERY serious about that. That's what would make your SHA1 results float. In fact, we had to put it into README for both Fedora and RHEL at some point.

Collegue Roy suggested that a winchester may be at fault. The odds are against it, but yes, it can happen. Usually when it happens, the system complains loudly though.

Once you're done with finding a computer which actually works (and this one does NOT work, let's be very clear about it), you may be in for an unpleasant surprise... I am not quite sure if updates from FC3 to FC5 were actually tested. Personally, I always went sequentially. In theory, the same algorithm applies when Anaconda calculates the changed package set. But it may just strain its belly button doing it.

What I would do in your place would be to upgrade with yum. It's as simple as one-two:
one: point /etc/yum.conf to FC4, update distro
two: FC4 moves to /etc/yum.repos.d, edit its contents to point to FC5, update distro.

The difference from Anaconda-driven updates is, the risk to end with an unbootable system is minimal.

So you think it's a memory problem, rather than a drive problem?

Hey guys,
I ran into the same problem...
My Memtest86 was without any result. Meaning my Hardware is OK...
Testing the HDD-Filesystems (using knoppix 5.0) fsck didn't give me any error: The filesystems are clean.

The only thing I did was to update my fc4 (with yum). And after the next boot I had this problems. I suggest rollback these updates...