re: installation boot fails with standard bootdisk on 486SX/33
I previously wrote: Installation fails on this old machine shortly after hitting return at the 'Boot Parameters' prompt using the standard bootdisk. Linux 1.2.13 runs fine. Additional info: after hitting return I get from 3 to 6 dots and then a 'bad disk' message. The disk is not bad, however. I divine from the messages I have seen that this is a problem with the boot loader on the boot disk, not linux. Also, that disabling cache may work to get by this problem. Unfortunately, disabling cache did not work. This machine is old but useful. I am helping a school district in Maine which has many such old machines and will likely be donated a lot more. We are trying to standardize on Debian so that the 20 to 50 people involved in support across the 10 buildings and 200 square miles of the district will have a common approach. The easy thing to do would be to upgrade the motherboard. Anyone have any other suggestions? Thanks, Michael Laing
Re: installation boot fails with standard bootdisk on 486SX/33
On Aug 11, 7:25pm, Bruce Perens wrote: Subject: installation boot fails with standard bootdisk on 486SX/33 : From: Christopher R. Hertel [EMAIL PROTECTED] : On my system (brand-new AMD-486DX4-120), the error that I get tells : me that the failure is occurring as the kernel is being : decompressed. : : OK - if this is true that means: : : 1. Bad data on the floppy. Most common. Re-download and write : another. Have done. Several times from several sources using several floppies. I've also used several tools (including DOS format, Win95 format, Norton Utilities Format, Scandisk, chkdsk, and other Norton stuff) to verify that the floppies are in good condition before I write to them. I am using dd under Linux 1.2.8 to write the floppies. I am also using the same floppy drive to format write the disks, and to boot. I think I've covered this aspect. : 2. LFB setting in your BIOS wrong. See the installation document. : Rare. There is no LFB setting in my BIOS setup. I have read the installation documentation. : 3. Bad RAM or other hardware. Happens _rarely_, but has indeed : happened. : : try turning off the cache and see : if that fixes the problem. If it does, report it as a bug. : : It is best reported to [EMAIL PROTECTED] and copied to : us. : It's not really our job to fix the kernel - we just distribute it. I disabled the internal cache and--*poof*--the problem went away. I will send a report to [EMAIL PROTECTED] Based on my results, and the results of others (as posted to this mailing list) I believe that this is *not* a kernel problem because, as you pointed out when discussing the possibility of an APM problem, the kernel is not yet loaded when the decompression error occurs. The problem, it appears, is in the decompression code. *QUERY*: those of you who have had this problem and gotten around it by turning off the internal cache, did you turn the cache back on once you had installed the system on your hard disk? Did that work? I'd like to know whether the decompression code in the floppy is the same as that which gets loaded on the hard drive. If so, does the problem persist when the kernel is being decompressed from the hard drive or does it only appear when booting from floppy? Is the kernel decompressed directly from the floppy, or is it transferred to the RAM disk first? : Sigh. I wish you'd spend some time supporting new users booting their : systems for a while. We really do need the help. It might change your : opinions, too. It seems that you've overlooked a couple of points: 1) I *was* providing support for a new user attempting to boot his system. I explained, as you did, that APM probably wasn't the problem. I also suggested turning off the cache. In my own case, and in several others, this (unfortunately) worked. (I say unfortunately, because I believe that I should be able to use the internal cache, unless you're telling me that Linux is intended *not* to run with internal cache enabled.) 2) I spent a *year* trying to figure out the SIGVEC problem, which was reported by several Linux users via newsgroups and mailing lists. The problem appeared on a variety of motherboards using a variety of CPU types, controller types, and memory configurations. Those of us who experienced this problem tried to combine our resources to solve it, but we did not have the technical expertise, or the support, or the stable platform we needed in order to accomplish much. Think about it: how am I supposed to test a fix to the kernel if I can't compile a new kernel because the system crashes whenever I try? (The SIGVEC problem was random, but typically occurred when an attempt was made to compile anything large. No, it did *not* always appear at the same point in the compilation.) At first, I got a great deal of helpful advice regarding the SIGVEC problem. Unfortunately, all of the suggestions that I received failed to correct it. Eventually, people started telling me and the others that the problem was in our hardware. When I explained that other operating systems (including DOS, Taos, and older versions of Linux) worked fine, I was told that those systems did not exercise the hardware as much as Linux does. Great. : Now I'm being told that I can't install Debian with the 2.0.x : kernel because my hardware is incompatible? This just doesn't make : sense! : : Huh? What hardware? Who said it was incompatible? So I've finally saved enough money to buy a new motherboard. Linux 1.2.8 now runs well. I've never figured out why the old one caused random SIGVEC errors, which is a shame, because that problem is probably still biting others out there (several of whom may have given up in disgust). So, now that 1.2.x is stable, I've decided to upgrade to 2.0.x. Unfortunately, a new hardware bug has appeared: I can't decompress the 2.0.x
Re: installation boot fails with standard bootdisk on 486SX/33
On Mon, 12 Aug 1996 14:20:06 -0500, Christopher R. Hertel wrote: most cases hardware will be blamed, even though the problem appears on a variety of memory/CPU/motherboard/add-on configurations, and the same configurations can run other OSs (*including* older versions of Linux) The external cache disable is also required on certain hardware configurations for installation of OS/2. I would assume the systems where this problem exists under LInux are the same ones affected by the same problem under OS/2. One thing to check, is to make sure you don't have a buggy AMI BIOS. Make sure your BIOS date is at least April, 1993. If not, contact AMI, and you can order an upgrade for about $20 USD.
Re: installation boot fails with standard bootdisk on 486SX/33
On Aug 9, 8:18am, [EMAIL PROTECTED] wrote: Subject: installation boot fails with standard bootdisk on 486SX/33 : Installation fails on this old machine shortly after hitting return : at the 'Boot Parameters' prompt using the standard bootdisk. Linux : 1.2.13 runs fine. : I suspect (based upon bug reports) that APM is enabled in the kernel : on the standard bootdisk and that this is the problem. The kernel should print a few lines of information before it first touches APM, this is not the problem. From: Christopher R. Hertel [EMAIL PROTECTED] On my system (brand-new AMD-486DX4-120), the error that I get tells me that the failure is occuring as the kernel is being decompressed. OK - if this is true that means: 1. Bad data on the floppy. Most common. Re-download and write another. 2. LFB setting in your BIOS wrong. See the installation document. Rare. 3. Bad RAM or other hardware. Happens _rarely_, but has indeed happened. try turning off the cache and see if that fixes the problem. If it does, report it as a bug. It is best reported to [EMAIL PROTECTED] and copied to us. It's not really our job to fix the kernel - we just distribute it. Given the type of problem you've reported, you might hear the infamous hardware instability that doesn't show up when running DOS or older versions of Linux because the newest Linux makes your machine work harder cop-out. This is a completely invalid argument, IMO. I've heard it several times (not in the message quoted above :). If I can run older versions of Linux, and a new one shows up that doesn't run, then I claim that the problem is in the new software. Sigh. I wish you'd spend some time supporting new users booting their systems for a while. We really do need the help. It might change your opinions, too. You could start by reading the kernel source for the code that decompresses Linux once it's been loaded into memory. Get a good idea of what can go wrong with that code, and what it will say when something does go wrong. Then help all the people who don't get anywhere after the boot: prompt. Now I'm being told that I can't install Debian with the 2.0.x kernel because my hardware is incompatible? This just doen't make sense! Huh? What hardware? Who said it was incompatible? Sorry if I sound a bit peeved about all this... ...but I am. Pardon me for saying so, but please try to be a bit more constructive. This is an all volunteer unpaid project. Thanks Bruce
installation boot fails with standard bootdisk on 486SX/33
Installation fails on this old machine shortly after hitting return at the 'Boot Parameters' prompt using the standard bootdisk. Linux 1.2.13 runs fine. I suspect (based upon bug reports) that APM is enabled in the kernel on the standard bootdisk and that this is the problem. I propose to install on another machine and create a custom bootdisk for this old (but useful) dog. Does anyone have any pointers or is there a suitable bootdisk image somewhere I can use? I am installing from the August Pacific HiTech CD and have internet access. Thanks, Michael Laing
Re: installation boot fails with standard bootdisk on 486SX/33
On Aug 9, 8:18am, [EMAIL PROTECTED] wrote: Subject: installation boot fails with standard bootdisk on 486SX/33 : : Installation fails on this old machine shortly after hitting return : at the 'Boot Parameters' prompt using the standard bootdisk. Linux : 1.2.13 runs fine. : : I suspect (based upon bug reports) that APM is enabled in the kernel : on the standard bootdisk and that this is the problem. : -- End of excerpt from [EMAIL PROTECTED] On my system (brand-new AMD-486DX4-120), the error that I get tells me that the failure is occuring as the kernel is being decompressed. This would suggest that APM is *not* the problem, as the kernel (if it does have APM support) has not yet started to run. I have seen postings on this mailing list that claim that the problem is level 2 cache, level 1 cache, EDO RAM on a board that doesn't support it, or generic hardware instability. Some 486sx system boards do have cache. If this is the case, try turning off the cache and see if that fixes the problem. If it does, report it as a bug. ...and now for the soapbox... Given the type of problem you've reported, you might hear the infamous hardware instability that doesn't show up when running DOS or older versions of Linux because the newest Linux makes your machine work harder cop-out. This is a completely invalid argument, IMO. I've heard it several times (not in the message quoted above :). If I can run older versions of Linux, and a new one shows up that doesn't run, then I claim that the problem is in the new software. I've already had this happen once. I ran Linux 1.0.8 without problems on a board with a Cyrix 486DLC-40. When I installed 1.2.8 I started getting frequent, random SIGVEC errors. These would often bring the system to its knees, forcing a power cycle. I heard from several others who had the same problem, but the only help we ever got were suggestions that we should buy new motherboards. I finally gave in, because I wanted a math co-processor and a faster CPU, and I wanted to get the *^@#%^! machine running (and because I'd finally saved up enough money). So, I have just purchased my new motherboard (with the AMD chip), and 1.2.8 runs very well. I have not seen any SIGVECs at all since the upgrade. Now I'm being told that I can't install Debian with the 2.0.x kernel because my hardware is incompatible? This just doen't make sense! From what I've seen in the few days I've been on this mailing list, there are several people out there who are having trouble installing Debian because of conflicts with the cache. Of those, several are running an older version of Linux successfully, or have managed to install the system by temporarily turning off the cache, and have no problems decompressing the kernel from the hard disk. Sorry if I sound a bit peeved about all this... ...but I am. Chris -)- -- Christopher R. Hertel -)- University of Minnesota [EMAIL PROTECTED] Networking and Telecommunications Services
