 |
|
 |
Reader's Favorites
Media Casualties Mount Administration Split On Europe Invasion Administration In Crisis Over Burgeoning Quagmire Congress Concerned About Diversion From War On Japan Pot, Kettle On Line Two... Allies Seize Paris The Natural Gore Book Sales Tank, Supporters Claim Unfair Tactics Satan Files Lack Of Defamation Suit Why This Blog Bores People With Space Stuff A New Beginning My Hit Parade
Instapundit (Glenn Reynolds) Tim Blair James Lileks Bleats Virginia Postrel Kausfiles Winds Of Change (Joe Katzman) Little Green Footballs (Charles Johnson) Samizdata Eject Eject Eject (Bill Whittle) Space Alan Boyle (MSNBC) Space Politics (Jeff Foust) Space Transport News (Clark Lindsey) NASA Watch NASA Space Flight Hobby Space A Voyage To Arcturus (Jay Manifold) Dispatches From The Final Frontier (Michael Belfiore) Personal Spaceflight (Jeff Foust) Mars Blog The Flame Trench (Florida Today) Space Cynic Rocket Forge (Michael Mealing) COTS Watch (Michael Mealing) Curmudgeon's Corner (Mark Whittington) Selenian Boondocks Tales of the Heliosphere Out Of The Cradle Space For Commerce (Brian Dunbar) True Anomaly Kevin Parkin The Speculist (Phil Bowermaster) Spacecraft (Chris Hall) Space Pragmatism (Dan Schrimpsher) Eternal Golden Braid (Fred Kiesche) Carried Away (Dan Schmelzer) Laughing Wolf (C. Blake Powers) Chair Force Engineer (Air Force Procurement) Spacearium Saturn Follies JesusPhreaks (Scott Bell) Science
Nanobot (Howard Lovy) Lagniappe (Derek Lowe) Geek Press (Paul Hsieh) Gene Expression Carl Zimmer Redwood Dragon (Dave Trowbridge) Charles Murtaugh Turned Up To Eleven (Paul Orwin) Cowlix (Wes Cowley) Quark Soup (Dave Appell) Economics/Finance
Assymetrical Information (Jane Galt and Mindles H. Dreck) Marginal Revolution (Tyler Cowen et al) Man Without Qualities (Robert Musil) Knowledge Problem (Lynne Kiesling) Journoblogs The Ombudsgod Cut On The Bias (Susanna Cornett) Joanne Jacobs The Funny Pages
Cox & Forkum Day By Day Iowahawk Happy Fun Pundit Jim Treacher IMAO The Onion Amish Tech Support (Lawrence Simon) Scrapple Face (Scott Ott) Regular Reading
Quasipundit (Adragna & Vehrs) England's Sword (Iain Murray) Daily Pundit (Bill Quick) Pejman Pundit Daimnation! (Damian Penny) Aspara Girl Flit Z+ Blog (Andrew Zolli) Matt Welch Ken Layne The Kolkata Libertarian Midwest Conservative Journal Protein Wisdom (Jeff Goldstein et al) Dean's World (Dean Esmay) Yippee-Ki-Yay (Kevin McGehee) Vodka Pundit Richard Bennett Spleenville (Andrea Harris) Random Jottings (John Weidner) Natalie Solent On the Third Hand (Kathy Kinsley, Bellicose Woman) Patrick Ruffini Inappropriate Response (Moira Breen) Jerry Pournelle Other Worthy Weblogs
Ain't No Bad Dude (Brian Linse) Airstrip One A libertarian reads the papers Andrew Olmsted Anna Franco Review Ben Kepple's Daily Rant Bjorn Staerk Bitter Girl Catallaxy Files Dawson.com Dodgeblog Dropscan (Shiloh Bucher) End the War on Freedom Fevered Rants Fredrik Norman Heretical Ideas Ideas etc Insolvent Republic of Blogistan James Reuben Haney Libertarian Rant Matthew Edgar Mind over what matters Muslimpundit Page Fault Interrupt Photodude Privacy Digest Quare Rantburg Recovering Liberal Sand In The Gears(Anthony Woodlief) Sgt. Stryker The Blogs of War The Fly Bottle The Illuminated Donkey Unqualified Offerings What she really thinks Where HipHop & Libertarianism Meet Zem : blog Space Policy Links
Space Future The Space Review The Space Show Space Frontier Foundation Space Policy Digest BBS AWOL
USS Clueless (Steven Den Beste) Media Minder Unremitting Verse (Will Warren) World View (Brink Lindsay) The Last Page More Than Zero (Andrew Hofer) Pathetic Earthlings (Andrew Lloyd) Spaceship Summer (Derek Lyons) The New Space Age (Rob Wilson) Rocketman (Mark Oakley) Mazoo Site designed by 
Powered by Movable Type |
 |
|
Fedora Update Update (Part N) For those few of you who are fascinated/horrified by my computer travails, here's the current status. After removing Open Office and a Fortran compiler to resolve some otherwise unresolvable (at least by me) dependency issues, I finished the upgrade from Fedora Core 3 to Core 4 via yum update (at least I think I did--how do I know?). I rebooted, and it rebooted. I haven't attempted to reinstall Open Office yet, so I don't know if that will work, but flush with seeming victory over the machine, I decided to push my luck and go from Core 4 to Core 5. After installing the Core 5 rpm, here's the output of that exercise (from yum -y update). Setting up Upgrade Process [root@linux-station ~]# So, now what? [Update] I'm apparently supposed to uninstall the kernel before I do an upgrade. Here are all the packages that will be removed along with it: Dependencies Resolved Performing the following to resolve dependencies: TrackBack URL for this entry:
http://www.transterrestrial.com/mt-diagnostics.cgi/5566 Listed below are links to weblogs that reference this post from Transterrestrial Musings.
Comments
You've confirmed by plan to upgrade FC4 to FC5 by doing a fresh reinstall. Oho, you're trying a "live" upgrade? I've always done the from-CD upgrade. Have you seen: http://forums.fedoraforum.org/archive/index.php/t-107205.html (and from that page) Oho. http://fedoraproject.org/wiki/YumUpgradeFaq Looks interesting, and might be what your problem is. I think if you upgrade the kernel, reboot, remove the older ones, you might be able to get this to work. Posted by Addison at June 1, 2006 07:32 AMYou've confirmed by plan to upgrade FC4 to FC5 by doing a fresh reinstall. I've what? Yes, Addison, a live upgrade. I've been unable to burn a disk without errors (tried two different CD burners). I've looked at several sites, but not those. I'll check them out. Posted by Rand Simberg at June 1, 2006 07:32 AMIt would be nice if the page offered a little more info. For instance, it doesn't say to upgrade the kernel--it just says to remove any below 2.6.14. Removing the kernel and then rebooting sounds like a bad plan to me, but what do I know? Posted by Rand Simberg at June 1, 2006 07:36 AMRand: (And it's been 10 years since I did HellDesk work, I'm used to figuring this stuff out hands-on, so my apologies). What's the current output of `uname -a`? If you do a ... (I think) `yum upgrade kernel`, what do you get as a option? Posted by Addison at June 1, 2006 07:39 AMIt's 2.6.9-1.667 I'm having yum remove it, just to see what happens. Seems like administering a lobotomy on yourself while you're awake, but we'll find out. Posted by Rand Simberg at June 1, 2006 07:44 AMIt may be too late by now, but I think the idea those pages were getting at was that you should update to the most recent Core 4 kernel (which seems to be 2.6.16-1.2111_FC4 according to my up-to-date FC4 box). Once you are re-booted into FC4 using a kernel greater than 2.6.14, you can do a 'rpm -ql kernel\*' to get a list of all the kernel packages that are currently installed*. Once you have that list, you can do yum remove to remove the kernels older than 2.6.14. Then you should be able to get on with your upgrade to FC5. * Kernels are different from normal RPM poackages, in that you may have more than one installed with different versions. This feature lets you boot into an older kernel from your bootloader if something goes horribly wrong with a newly installed kernel. Posted by Jerry at June 1, 2006 07:58 AMUm. Well, hope that works. :) Don't do nuthin' til you have a new one installed, though (in way of reboots, etc.) I've got FC 3 here, I'm playing some. Removing it, then running the upgrade like you were trying to do (which should get the newer kernel)... That might be a way to go? Posted by Addison at June 1, 2006 08:00 AMYour comment filter ate a bit of my post because I had it in angle brackets. If the output of rpm -ql kernel\* looks like this: You can remove an unwanted kernel by doing this: Note the update to the post. The machine awaits my command... Posted by Rand Simberg at June 1, 2006 08:05 AMIt won't let me upgrade the kernel until I remove the old one, Jerry. My plan was to remove, then yum update, and hopefully I'll have Core 5 with the new kernel at the end of the process. Posted by Rand Simberg at June 1, 2006 08:09 AMI would not say Okay to that big list of removals. Are you trying to remove your only kernel? If so, don't do that. I think you need to have a kernel greater than 2.6.14, and no older kernels, to procede with your upgrade. You've already installed the FC5 info RPM, so I would do the following: The kernel you download depends on your machine. This is one for a single-cpu i686 class box: Install with RPM by doing rpm -i 'filename' -- note, you use -i here instead fo the more common -U to Install a new kernel without overwriting the old one. Posted by Jerry at June 1, 2006 08:19 AMFWIW at this point: http://fedoraproject.org/wiki/YumUpgradeFaq Lists some gotchas to watch out for, several of which you've hit. Apparently Live Upgades aren't really recommended for non-gurus, although they're workable in theory. YUM seems to be a bit of a work in progress; it's better than raw rpm, but not as refined yet as apt. Posted by Mike Earl at June 1, 2006 08:20 AMI've been looking at that FAQ. It's less than helpful when it comes to FC4-FC5 upgrade. OK, I said "No" and it exited without removing the packages, though it did say "Complete!" at the end, so I don't know if it left the packages but removed the kernel, or if it didn't remove anything. I tried installing that new kernel, but get the following problems: installerror: Failed dependencies: I tried installing mkinitrd, but it ran into dependency issues on kernels Scratching head now. Posted by Rand Simberg at June 1, 2006 08:53 AMRand: I don't know if I'm stating the obvious (the documention on this stuff could really be improved!) but if the dependencies are circular, you may have to do both in one pass, something like: yum update kernel mkinitrd It should realize that the end-state is valid and be able to go ahead, even if it can't update either because of the other. Posted by Mike Earl at June 1, 2006 09:03 AMOK, I tried rpming the two packages together, and it fixed the mkinitrd issue, but I got a new one: error: Failed dependencies:
According to rpmfind.net, it looks like there's a package called "selinux-policy-targeted'; I'd guess you need to do that along with udev and mkinitrd to upgrade the kernel. "selinux" is the super-fine-grained security mechanisms in the new 2.6 kernels, but actually making use of them in practice seems to be so insanely complicated that even most linux gurus ignore it as yet. Posted by Mike Earl at June 1, 2006 09:59 AMOK, I've been chasing down dependencies, and have finally solved all of them except the selinux thing: [root@linux-station ~]# rpm -i http://download.fedora.redhat.com/pub/fedora/linu x/core/updates/4/i386/kernel-2.6.16-1.2111_FC4.i686.rpm ftp://194.199.20.114/lin ux/fedora/core/4/i386/os/Fedora/RPMS/mkinitrd-4.2.15-1.i386.rpm ftp://194.199.20 .114/linux/fedora/core/4/i386/os/Fedora/RPMS/selinux-policy-targeted-1.23.16-6.n oarch.rpm ftp://194.199.20.114/linux/fedora/core/4/i386/os/Fedora/RPMS/udev-058- 1.i386.rpm ftp://194.199.20.114/linux/fedora/core/updates/4/i386/libselinux-1.23 .11-1.1.i386.rpm ftp://194.199.20.114/linux/fedora/core/updates/4/i386/policycor eutils-1.27.2-1.2.i386.rpm ftp://194.199.20.114/linux/fedora/core/updates/4/i386 /libsepol-1.5.10-1.1.i386.rpm I don't know what other version of it to find--I'm using the latest version in rpmfind for Core 4. Unless I can try a different kernel greater than 2.6.13... Rand, you're not pulling the latest version of selinux-policy-targetted there. You're pulling the version that was released with FC4, not the current updated version. Try using this URL: OK, I fixed that, but it didn't help" [root@linux-station ~]# rpm -i http://download.fedora.redhat.com/pub/fedora/linux/core/updates/4/i386/kernel-2.6.16-1.2111_FC4.i686.rpm ftp://194.199.20.114/linux/fedora/core/4/i386/os/Fedora/RPMS/mkinitrd-4.2.15-1.i386.rpm http://download.fedora.redhat.com/pub/fedora/linux/core/updates/4/i386/selinux-policy-targeted-1.27.1-2.28.noarch.rpm ftp://194.199.20.114/linux/fedora/core/4/i386/os/Fedora/RPMS/udev-058-1.i386.rpm ftp://194.199.20.114/linux/fedora/core/updates/4/i386/libselinux-1.23.11-1.1.i386.rpm ftp://194.199.20.114/linux/fedora/core/updates/4/i386/policycoreutils-1.27.2-1.2.i386.rpm ftp://194.199.20.114/linux/fedora/core/updates/4/i386/libsepol-1.5.10-1.1.i386.rpm error: Failed dependencies: Argh. Okay. I checked my running FC4 box for the versions of all of those packages that are currently installed and playing together well. The only thing different in what you're updating to is udev. I have udev-071-0.FC4.3 installed, while you appear to be trying to install udev-058-1. So, I would replace your udev URL with this one: The other option is to take a step backwards. You seem to have updated to FC4-release, but not updated with all of the patches between release and the end of FC4. It seems like we need to get you to FC4+patches before you can upgrade to FC5. Perhaps if we "downgraded" the fedora-release package back to the FC4 version, we could get yum pointed in the right places to update FC4 before attempting to move to FC5? That didn't fix it. In fact, it introduced a new problem: [root@linux-station ~]# rpm -i http://download.fedora.redhat.com/pub/fedora/linux/core/updates/4/i386/kernel-2.6.16-1.2111_FC4.i686.rpm ftp://194.199.20.114/linux/fedora/core/4/i386/os/Fedora/RPMS/mkinitrd-4.2.15-1.i386.rpm http://download.fedora.redhat.com/pub/fedora/linux/core/updates/4/i386/selinux-policy-targeted-1.27.1-2.28.noarch.rpm http://download.fedora.redhat.com/pub/fedora/linux/core/updates/4/i386/udev-071-0.FC4.3.i386.rpm ftp://194.199.20.114/linux/fedora/core/updates/4/i386/libselinux-1.23.11-1.1.i386.rpm ftp://194.199.20.114/linux/fedora/core/updates/4/i386/policycoreutils-1.27.2-1.2.i386.rpm ftp://194.199.20.114/linux/fedora/core/updates/4/i386/libsepol-1.5.10-1.1.i386.rpm http://download.fedora.redhat.com/pub/fedora/linux/core/updates/4/i386/module-init-tools-3.2-0.pre9.0.FC4.4.i386.rpm Okay, I'm afraid you've got me stumped. I know just enough to keep my own machine up to date, and I'm afraid me trying to take you any further is just a case of the blind leading the blind. There's a users mailing list here: and a forum here: Maybe one of those places would turn up someone with more experience than me. Posted by Jerry at June 1, 2006 12:05 PMHuh, I don't get it. You told it to install selinux-policy-targeted-1.27.1, and it complained that the kernel wasn't compatible with versions before 1.23. Are we sure that that selinux URL is good? Maybe turn up verbosity on rpm (-v??) to see if you can get a clearer error message; that doesn't make sense, unless I'm missing something. Posted by Mike Earl at June 1, 2006 12:05 PMI think some of the problems are stemming from doing those upgrade with 'rpm -i' instead of 'rpm -U'. You have to install the kernel with rpm -i so that it gets installed alongside the existing kernel. The rest of the packages should be upgrades of existing packages, and should be installed with rpm -U. Unfortunately, I don't know how to mix all of that into one command line, and I'm not even 100% sure that it's the source of your problem. Posted by Jerry at June 1, 2006 12:22 PMTime zones kill me. All the action happens when I'm asleep or laying in bed with my leg raised. OK... The first rule of thumb is, don't try to overreach with rpm -i, it will inevitably break on something (on selinux-policy-targeted in this case). That's because rpm does not act recursively. It's what yum is for. Also, yum knows which packages to install with -i (kernel) and which to update with -U. Just forget it and run "yum update" all the time. It is typical to remove with rpm -e if a package is interfering. Secondly, someone mentioned that removing the last kernel is not a good idea. That is quite true :-) Also, removing the currently running kernel is not a good idea. What if you'll need something like loop module? And lastly, once the system was running FC-4, you should have ran "yum clean all" (and inspect the results with "du /var/cache/yum"), before doing updates and the new cycle. Otherwise you're guaranteed to run out of space, because the whole of FC-4 would be sitting there mixed up with new packages. Thanks for all the useful advice on what I should have done, Pete. ;-) What do I do now? Posted by Rand Simberg at June 1, 2006 02:39 PMYou cannot be too far along the way yet. I suggest starting with a clean slate by running "yum clean all", and df to make sure the root (where symlinked /var/cache/yum actually resides) is about 50% full or below. Then, just rerun the "yum upgrade" that opened this post. I gather that you got rid of old kernels, so the error (if any) should be different this time. The log is going to be longish, e-mail it to me to redhat, please. If you want it documented in the blog, only the few last lines are interesting for a casual reader. I ran "yum clean all" and then reran "yum upgrade." The results weren't a large file: [root@linux-station ~]# yum upgrade ^
Ok, I'm out of my RPM depth here. If it can't figure out the dependancies but you're *sure* they're ok, you could force matters with rpm -i --force (something.rpm) (--force meaning, screw dependencies, just install what I told you) and then check that things look ok with rpm -V. You could certainly make a mess of things that way in a hurry, though. It would be a last resort before deciding to reinstall from scratch and just keep the old /home partition (which isn't necessarily a bad plan, actually). Posted by Mike Earl at June 1, 2006 06:43 PMAwesome, Rand. The metadata corruption. I hope you won't mind if I blog this. I suspect though, that some wise guy will put it down to "mirror inconsistency" - a very convenient excuse. BTW, I hope your hard drive is not going to follow your old RAM, because that would explain syntax errors in the XML file. Seen anything in "dmesg" output? Assuming the disk isn't about to retire, please do this: P.S. For the love of everything good, you aren't having reiser for you root filesystem by any chance? You want dmesg? We got dmesg: Linux version 2.6.9-1.667 (bhcompile@tweety.build.redhat.com) (gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)) #1 Tue Nov 2 14:41:25 EST 2004 As for your next request, observe: [root@linux-station ~]# cd /var/cache/yum/core && rm cachecookie primary.xml.gz primary.xml.gz.sqlite repomd.xml
And as for your last question: "For the love of everything good, you aren't having reiser for you root filesystem by any chance?" I have no idea what you're talking about... Just remove the damn thing, geeez! It's obviously corrupt. Let yum to re-download it. The dmesg seems fine, no errors. I kinda hoped you'll look at it yourself... Yeah, that definately sounds like "yum update" didn't actually get everything it was supposed to, and got only a partial copy of repomd.xml (repository meta-data?) - either something funny on your end, or the site you were downloading from was bad... Posted by Mike Earl at June 2, 2006 07:10 AM'yum update' still bombs out at the end: --> Processing Conflict: kudzu conflicts kernel< 2.6.13 I have to confess, I just don't understand Pete Zaitcev's last post. Just remove the damn thing... Which "thing" is being referred to, and what is the recommended procedure for removing it? And what is it that's corrupt? Posted by Rand Simberg at June 2, 2006 07:16 AMOh, and 'reiser': Linux supports lots of different on-disk filesystem formats, including some non-native ones (eg, Windows FAT or NTFS). "ext2" was the standard for a long time; "reiser" is one alternative, though most Redhat folks at least use "ext3" these days. Using reiser, especially as root filesystem, on a RH box can be tricky and some (many?) people believe reiser favors features and speed at the expense of reliability. This is one of those Religious Issues; you can look up more about it if you care, which I advise you not to. Posted by Mike Earl at June 2, 2006 07:16 AMOh. I'm ext3. Posted by Rand Simberg at June 2, 2006 07:17 AMRand: I'm pretty sure Pete Z. was talking about repomd.xml; the earlier errors indicated that yum couldn't parse it (possibly because parts of it were just missing?). He wanted you to delete the (apparently bad) cached copy and try again to sync up with the mirror ("yum upgrade"?). Posted by Mike Earl at June 2, 2006 07:19 AMWell, I deleted it (renamed it, actually) and did a new yum update, with exactly the same results. Here's the directory listing: drwxr-xr-x 2 root root 20480 Jun 2 09:45 headers
And here's the contents: Bizarre. I don't know anything about repomd.xml format as such, but that's certainly valid-looking XML. The errors you got before with "yum upgrade" don't make sense to me at all, then; it was complaining about craziness like 'nbsp' and 'html' and 'Copyright' tags, which make it sound like it was trying to parse some random HTML file instead of the one you're looking at there. A quick web search finds He seemed to have the same problem, and apparently it resolved when he told yum to update from the authorative Redhat site, rather than a (possibly corrupted?) mirror site. And now I'm off to do some of my ostensibile work, and lunch. Best of luck! Posted by Mike Earl at June 2, 2006 09:39 AM"Well, I deleted it (renamed it, actually) and did a new yum update, with exactly the same results." What does "exactly the same" stand for? The parser error on repoxmd.xml, or kudzu conflicting with the old kernel? Both, I think. Here's the tail: --> Processing Conflict: kudzu conflicts kernel< 2.6.13 We're obviously past the repodata corruption issuses if dependencies are being calculated. So, we are back on the old "kudzu conflicts with kernels" problem. The easiest way to avoid kudzu problems is to rev the kernel separately. We did try that before with this (copied from above): I propose trying that again, only with rpm -i --nodeps (and local file, if available - no need to download again and again). Do not reboot into the "new" kernel, it's only there to pacify kudzu. Once done, run "yum upgrade", and then see what happens. (N.B. I forgot who mentioned that using --nodeps was dangerous, Mike, Jerry, or someone else. The danger is specific: that the package installed this way may be not fully functional. In this case, we do not care because we're not going to use it. But yes, this option should not be used indiscriminately.) OK, tried that. Installed the new kernel, --nodeps, and it installed without complaint. But I still get the kudzu incompatibility, and will probably continue to until I actually remove the old one. But as you said, deleting a running kernel seems like a Really Bad Idea (particularly since I don't have a working one installed). Maybe custom build one just for reboot to get us past this problem? Posted by Rand Simberg at June 2, 2006 01:09 PM(Sorry for running off, Rand, had to attend to my own Unixen! :) ) Catching up.. Reiser. Great FS. PITA to deal with when anything goes wrong. (As of a couple years ago, also missing some basic utils. Use ext3 unless there's a reason why you shouldn't. If you know the reason, you'll know enough to know why. The custom build sounds like one plan. Sure you can't get someone you know to burn you the install CDs and install from them? :) Posted by Addison at June 2, 2006 01:34 PMI've tried burning them from two different machines. the sha2sum always checks out, but when I burn the disk, it gets errors reading it at boot time (though it works well enough to load the kernel and do the media test). I'm starting to wonder if there's a problem with the CD-drive. I'm almost tempted to go out and replace it just to test that theory. Posted by Rand Simberg at June 2, 2006 01:37 PMOH OH OH. What a pain. Very well. This is probably not important anymore, since we seem to be switching tracks to Anaconda-based upgrade off a CD (or DVD). But considering yum, I would go about it by a) verifying that the /boot/initrd-X.img is present for the new kernel, b) rebooting into the kernel which we weren't going to use (ok! I hate kudzu too!). If that works, remove the old one. You know what kudzu actually does? It detects new devices on boot. The retarted idea is completely analoguous to what Windows does. Needless to say, I always disable kudzu with "chkconfig kudzu off". Unfortunately, the kudzu package cannot be easily removed... Ignore the results of the media check. So, we've gone through all this for nada? If the media check isn't trustworthy, you probably shouldn't do it. Sorry I didn't tell you that sooner, but it is how this whole thing started. So, just trust my Core 5 disks and do the install from them? Posted by Rand Simberg at June 2, 2006 02:54 PMI was under impression that the SHA1 hashes of ISO images on the hard drive was changing initially, which is different from the media check as performed by the installer. I'm a little reluctant to suggest to upgrade from CDs, for a few reasons. 2. Early on, you asked what is safer, w.r.to a reboot. But of course yum is. No matter what it does, you have a system which is, at least, bootable. 3. I am used to yum, and I went through the procedure on my laptop, workstation, and server in this house. Now if you want an install, that should be all right, I suppose. Just boot from CDs and wipe the rest. It's especially handy when you have a separate /home partition. When I did that, I backed everything up anyway, but at least there's no need to restore. There's a different way make sure that CD is all right, without a media check. Mount it, say, on /mnt/tmp, and run: If the CD truncates unrecorded parts of the block, it does not affect the content. The mediacheck is an eqivalent of "dd if=/dev/hdc | sha1sum", so it fails. If you're resonably sure CD is all right, you can go ahead with an install or upgrade. But for some reason, I'm afraid to endorse it... Post a comment |
|
