Red Hat 7.0, iso, disk 1 USER DESC: I've played w/ Linux for ~10 years. The first Linux version I downloaded from my college's CS mainframe was a floppy only version and had install notes from Linus. COMPUTER DESC: Let me stress: The computer has a working Win95 partition. I WIPED a perfectly good install of Slakware on the machine for Red Hat. It also had Red Hat 6.2 installed before. SOOOOO - it is NOT the machine. And its not Me. No. Bad. Bad. I had so many CRITICAL problems installing that filing separate queryable items would not impossible. Two of them even said "Please notify Red Hat" (I typed in one of these in this message). BUT that's not why I'm submitting this. I worked my way through several install problems. Red Hat 7.0 won't install PERIOD. And the way Red Hat 7.0 boots there's no way for me to "fix" it. I don't have any CVS for anaconda... Even if I did, there would be many "where - what to do" issues I would not be "clued in" on. And I'd have to re-install Red Hat 6.2 'cause my other 2 boxes are 'busy'. INFORMED? My network is up and I've read the RedHat install guide off the web during installation of a machine - 7 machines in all (now 6). Did see bug errata and bugzilla to see if it was "just me". CHECK. MACHINE SPECS: Intel P200, Intel EV board, Diamond 64 Video VRAM 3200, 32Mb, 2G, Mitsumi 4x IDE CD. An expensive machine at the time of purchas. 100MB Win95 17MB /boot 100MB swap 1.8G / (Linux) I know about partitioning? CHECK CRITICAL boot.img: both dd and rawrite used message: "vmlinuz corrupt" after several "tries" I give up... note: I did get a working kernel - didn't FTP iso in ASCII. I have compiled kernels & made new kernel modules: CHECK I know about boot: messages, rawrite, & the like? CHECK CRITICAL cdrom device errors: 1) anaconda quits after "magic number" of read errors FIXED: stop and changes out 48x for 4x drive right now... Changed to "older & slower" but stable CD drive. This drive reads the disk fine from DOS. 2) anaconda didn't like the second drive either FIXED: stop and changes out 4x for 40x drive right now... OK - this drive reads CDRs better than anything I've seen yet - BUT I had to shut an UP machine down to remove it :( CRITICAL: (4x-IDE CD) loadlin/dos using autoboot.bat (from 7.0 iso)- anaconda: intermittently exits, giving different messgaes per try: "Install exited abnormally -- received signal 11" "Install exited abnormally -- received signal 7" --------------------------------------------------------- File "/usr/bin/anaconda", line 204, in ? import rpm ImportError: libdb.so.2: cannot read file data: Input/output error --------------------------------------------------------- FIXED: anaconda operational - likes 40x CD USAGE: Tried both "custom" and "workstation" install methods - several times. anaconda finally loads: (in order of occurance, not severity) Selected "Custom" install. I've done it many times. CHECK No install time tip that a /boot partition should be made... Friendly? Create /boot, swap, / (see above) with fdisk. Forced installation of Lilo. No likey. HIGH: Just this HIGH section contains an analysis. I would like you to PLEASE consider it - it is a "Red Hat" issue and has a great bearing. Lilo: No Likey Megabytes of workaround "scripts" and horror stories avail. on internet (for the new version alone :) Many drives hosed. 2 2 many hacks to read. MBR is WHO's? Not the OEM's? Not the HD MFGR's? -> Loadlin: All users report no problem on recent version-S-. Works with all flavors of LBA (LBA is a PLURALTY!) EVEN if partitions have different versions of LBA EVEN if not all partitions USE LBA Not unusual... Note: LBA is distributively not a reversable process... Works over 2G barrier, well over it... Works over 8G barrier, well over it... Works with REALLY FAT linux kernels. Easy as "pie" to use (not Office activex pie... :) I'd say DOS/loadlin CLEARLY wins here simply by NOT doing. Lilo does not like my any 5/7 setups I have - its wise about things it knows nothing about and just doesn't cut it. ?? All to avoid the activate partition flag ?? My God I LOVE the partition flag! Its Red, White and Blue! Even NEWBIES can do it! Its the opposer of the three fingered solute and NT sas! HIGH Once I select the software anaconda cheks the dependancies. Invariably I have a few TINY programs in a large list which require 20MB of installation each that I want to get rid of. I go back to the "big list" and after a while finally find and uncheck them. All of that effort - only to find that when I select OK and the dependancy list is brought up - anaconda still intends on installing those tiny peices of software and those 20MB packages I'd rather not have. In other words: the ability to go "back" doesn't do any good because the choices are "locked in". CRITICAL Says "911MB" or so install selected (I selected packages). "Installation Begins" - but an ---> "out of space error" Error is encountered after 1 min of copying: 4xCD can't copy fast enough to fill a 1.8G HD that quick... Analysis: FOUND thiswas caused by CD READ error - which isn't handled. ANACONDA was "BSing" about the out of space thing. This is terrible - as I was forced to guess the problem was in the partitioning and wasted my time reviewing it and reinstalling - just to get the same message THREE times. CRITICAL Going "Back" from error and re-attemping install (without re-booting): "NOTIFY REDHAT" script error appears (again involving mounts) CRITICAL Ok - while writing this I, I went "Back" to install type screen and chose "Workstation" ok, Partition Manually ok (follow the easier path?) ---------------------------------------- Exeption Occured: Please report as soon as possible. Traceback (innermost last): File "/usr/bin/anaconda", line 438, in ? intf.run(trodo, test = test) File "/var/tmp/anaconda-7.0.1/usr/lib/anaconda/text.py", line 1030, in run rc = apply (step[1](), step[2]) File "/var/tmp/anaconda-7.0.1/usr/lib/anaconda/textw/partitioning_text.py", line 225, in __call__ todo.fstab.turnOnSwap() File "/var/tmp/anaconda-7.01/usr/lib/anaconda/fstab.py", line 406 in turnOnSwap isys.swapon (file) File "/usr/lib/anaconda/isys.py", line 142, in swapon return _isys.swapon (path) SystemError: (16, 'Device or resource busy') ---------------------------------------- CRITICAL FINALLY the whole thing started working & installing - I got to the END of the install - only to get a lock up at the very end: "can't find module passwd can't find module passwd" This occurs at the very end when anaconda is HALF done with - "configuring the system" at the end of the install. AGAIN - I tried installing installing both "Custom" and "Workstation" thinking I might get around this LAST detail: NO DEAL. SUPER CRITICAL AT LAST - THE LAST STRAW: After all that - the partition wasn't left bootable. I was going to do an "emergency" boot and "fix" her up - but she wasn't anywhere to be found in the realm of booting. That is the first time I've "given up" on a Linux install. HIGH: SCO states Red Hat 7.0 has changes the ABI so that their "lxrun" doesn't work for RH7. SCO works hard at linux play. SCO people have a right to contribute and play to. I not even going to expand on SCO contributions and rights - it should be self evident. "lxrun" is a "living" SCO Skunkware project that lets Linux scripts (even Red Hat 6.2) AND binaries (not incl. kernel) run under the SCO kernel. Apache, KDE, Gimp, GCC, etc. (not just little packages). It is an open project and allows "tracing" for support of the "hard" apps. LOW: (Red Hat 6.2 - linuxconf - samba: config program puts binary garbage in smb.conf or just makes it null if smb.conf is hand adjusted from smb.conf.sample) -------------------------------------------------- -------------------------------------------------- I'm not sure why I bothered to write this. Probably too much coffee and too much time. I would rather have spent time CONTRIBUTING than re- booting. How do you think that makes me feel? I liked thinking Linux was stable. That's the WORD. The BOND. Here's one thing that a sucessful Logistics support expert DAD taught me (modified): Bug database is Microsoft looser talk and looser strategy. It'll never work anyway talk. Searching Bug Database to solidify why it'll all never work: same thing. Here are some winning strategies: (the FUN ones first) Tight but acheivable (one week delay) NSXY has a recovery plan. Too early to tell. Disjoited incrementalism. We're still waiting for a CBE decision. Another problem solved by creative indifference. JACS must be easy - just look at all the experts. What could go wrong? Concurrence, however slight, implies complicity. (*#@!# "M C" we've been at this for 13 !@(* months now. Memory management on the MAC can be used to scare small children (you guessed it - Linus) (each app telling the next how much memory is left). NOW - SERIOUSLY - Just a second :( If the "basis" is wrong - so are all of the solutions: winner talk. Labeling sketchy software as Alpha with warnings: winner talk, and polite. Staying within the experience base: winner talk. Programming is math - math is programming. Do the math first. A single highly visible patch area - patch disk warnings even e-mailed. Easy to use patch disks for the "unforseable" arising complications without "errata" without COVERING UP the severity: which alone cost me 1 or 2 hours without a bunch of needless directions, options, and talk obviously excluding the OS installer Doing it the infallible UNIX way: winner talk. Complete re-write: winner talk. the "life cyle" (school book-boy dependant): winner talk?? Operations research study: winner talk. Keep coding: looser talk. Your taking too long: un-involved, uneducated, and impatient dreamer. Many amazing releases are LATE. Qaulity Assurance Testing: winner talk. More RPM Lint tools: winner talk. RPM is really an excellent innovation and pleasant for the user. Good job! NICER - apologetic :) Well - I hope this gets passed up the chain at Red Hat. To be honest I would LOVE working there and am ashamed to say anything on the downside of any linux. But hey: this release breaks the "common curtesy" barrier of "respect" for the user. I don't imagine it was on purpose. But I don't think "denial" is in order either. But again "common curtesy and respect for the user". I didn't write this to report a bug. I think it goes further than that when allot of Joe's suffer re-boots with the ultimate frustration of a no install - no Linux. People like Linux even without every whistle & bell. They like it because its Linux. Red Hat - I think - is the largest body of confering Linux distribution coders ever. They are bound to be the staple of the Linux community if I'm correct. So they need to protect the defacto legacies of linux. Now I'd peddle my petty help - but you must agree it'll take a whole team effort and a "new resolution" to fix where RH7 install has gone.
Well I read it. Most of this sounds like a single problem masquerading as a set of disasters You have missing files corrupt file reads (signal 7 signal 11) IDE CD errors. Is it possible the fundamental problem you have is a faulty CD (disk not drive). When the OS cant load pieces of binaries you will get segfaults and deep weirdness. Since we page binaries in its not going to show up as it loads but as that bit of the installer is needed. As to the SCO thing, that sounds like bad mouthing on their part. The kernel ABI is the 2.2 one with the 2.4 extensions for large files _IF_ you install the enterprise kernel. Glibc handles them being present or absent.
Closing due to inactivity.