Slackware 13.1 Install Error
in [Slackware]
|
Prev: Knode double-posting (was Re: OT: Newbie question: Current directory in path?)
Next: How can i disable nepomuk system globally?
From: Martin on 16 Jul 2010 17:14 Eef Hartman wrote: > Martin <no(a)spam.invalid> wrote: >> I think you're up a blind alley. The kernel itself has two IDE drivers, >> namely the old ATA/ATAPI/MFM/RLL driver (now deprecated) and the newer >> SATA/PATA driver. Both are perfectly up to the job even in the most >> recent kernel. > > Yes, but "huge.s", being a monolitic kernel, no modules, only uses > a SINGLE one of those schemes (the "libata" one) and mostly even > through ahci, which only newer bios/sata controllers support > (haven't checked this, but I think some of the more common S-ata > drivers ARE included too in huge.s). You are right, of course, to point out that controller support may be an issue. From personal experience I can confirm that some of the VIA & Intel southbridges from the P3 era are supported by the driver and huge.s, though. > That's why I suggested going for a initrd with "your own" drivers. > > Best, of course, always is building your own custom kernel with > "exactly what you need for this system", but I'm not sure the OP > is up to that. I feel, creating an initrd is also a little advanced. ;-) Anyway, as the OP has reported the same issue with Slack 12.2 and Slack 13.1 we need to look somewhere else. My take is, either someone steps up who has run into the issue before, or the OP needs to provide more information (like the stack trace) and maybe get on the LKML (linux kernel mailing list) with that. Martin
From: Grant on 16 Jul 2010 18:11 On Fri, 16 Jul 2010 14:24:59 GMT, Edwin Johnson <edwinljohnson(a)bellsouth.net> wrote: >I am trying to install Slackware 13.1 in an older computer with a Centaur >VIA 800mHz chip and containing a 40gig HD, a 3.5" floppy, CD drive, and 640 >meg RAM. > >When booting using the install CD, I must use huge.s rather than the >hugesmp.s image as a note tells me the latter will not work. I've divided >the HD into four partitions, two large and two small, the last to be used >for swap and will install the system on /dev/sda1 or the first partition. > >During formatting of the HD first partition, I am getting the dreaded >"Kernel panic - not syncing: Fatal exception in interrupt" error. This error >does not appear at any time until formatting the drive. BIOS is reporting >all peripherals correctly and the memory check is fine. TOPS shows memory >correct. > >At first, my feeling was that this was a HD controller error and found >another 40gig drive which contained Win(ugg!)98 on it as well as a Linux >partition. I booted the drive to dos and Win(ugg!) and all worked correctly. >I then decided to reformat the Linux partition, /dev/sda3, which would not >touch the other partitions after booting up again with the Linux install disk. >I received the same error as above. Thus, it appears the problem is _not_ the >HD itself. > >I have read of this error in various links, but nothing I've tried, such as >pci=nomsi, ide=nodma, pci=noapci, etc. has worked. I eventually used the >command line, mkfs.ext2 -c /dev/sda1, to format and check for bad blocks so >that I could perhaps see what was going on. Could this be some strange >reaction of Linux and the VIA or older motherboard architecture? The sada >drivers have been suggested in some cases read about. > >Incidentally, reverting to Slackware 12.2, produces the same results. Also, >I may note that I installed Slackware 13.1 on a Panasonic CF-45 with a >450mHz ? Pentium III chip and it all went fine. The error is only occurring >at the time of formating the partition. > >Any help would be appreciated. My impression is that you'll need to compile a custom kernel for that box, on another box, in order to install slackware. Two reasons, the Centaur chip is unusual, and the disk system probably wants the old drivers, not the default libata new stuff which is not tested on all the old hardware. There's nothing wrong or bad with using the old disk drivers, they're being maintained separately to the new libata development effort. (Apart from the early sata driver, use libata for sata drives). I have made a custom kernel to install slackware on a box that the default install failed on, but the reasons were different, and I forget the details (of course). And, I don't think I wrote it up anywhere :( Just checked, I wrote up a summary of issues -- it was early 64 bit days (Slamd64-11.0) and I had to insert later kernel to get CD driver to suit my hardware, must've easy 'cos there's no mention of how I did that :) It is possible. So more work for you to give it a go. The scripts and pattern for inserting a new kernel into the install image is all there for you to look at, on whatever install media you have. Extract the install filesystem somewhere, build new kernel, make new install boot CD/DVD, off you go? Easy? 640MB RAM? Seems so little these days! Grant.
From: Grant on 16 Jul 2010 20:28
On Fri, 16 Jul 2010 23:14:16 +0200, Martin <no(a)spam.invalid> wrote: >Eef Hartman wrote: > >> Martin <no(a)spam.invalid> wrote: >>> I think you're up a blind alley. The kernel itself has two IDE drivers, >>> namely the old ATA/ATAPI/MFM/RLL driver (now deprecated) and the newer >>> SATA/PATA driver. Both are perfectly up to the job even in the most >>> recent kernel. >> >> Yes, but "huge.s", being a monolitic kernel, no modules, only uses >> a SINGLE one of those schemes (the "libata" one) and mostly even >> through ahci, which only newer bios/sata controllers support >> (haven't checked this, but I think some of the more common S-ata >> drivers ARE included too in huge.s). > >You are right, of course, to point out that controller support may be an >issue. From personal experience I can confirm that some of the VIA & Intel >southbridges from the P3 era are supported by the driver and huge.s, though. > >> That's why I suggested going for a initrd with "your own" drivers. >> >> Best, of course, always is building your own custom kernel with >> "exactly what you need for this system", but I'm not sure the OP >> is up to that. > >I feel, creating an initrd is also a little advanced. ;-) > >Anyway, as the OP has reported the same issue with Slack 12.2 and Slack 13.1 >we need to look somewhere else. My take is, either someone steps up who has >run into the issue before, or the OP needs to provide more information (like >the stack trace) and maybe get on the LKML (linux kernel mailing list) with >that. lkml is a kernel development list not really geared to and users unless the end user can concisely state their issue, and somebody has a spare moment to reply -- YMMV -- by heaps :) Anyway, see my reply, it's not easy either, but I do think it's a track worth looking at if nothing better turns up. Grant. > >Martin |