Re: Fresh Etch netinstall problems...
On Sun, Oct 28, 2007 at 03:55:24PM +0000, Digby Tarvin wrote:
> > On Sun, Oct 28, 2007 at 01:09:32AM +0000, Digby Tarvin wrote:
> > > On Sat, Oct 27, 2007 at 07:40:27PM -0400, Douglas A. Tutty wrote:
> > > > On Sat, Oct 27, 2007 at 05:30:49PM +0100, Digby Tarvin wrote:
> > > > > I hope there are some experts out there that can offer some suggestions
> > > > > regarding a problem I am having installing Debian Etch (40r1-386-netinst
> > > > > downloaded on 23/10/07) on a Dell Precision 410 MT...
> > > > >
> > > > > Everything goes fine through the initial install, up to the point
> > > > > where I have to reboot using the freshly installed kernel on the
> > > > > hard drive.
> > > > > Either the package transfer fails after a few minutes with messages like
> > > > > E: Method http has died unexpectedly!
> > > > > segmentation fault
> > > > > or dpkg falls over during the installation of the package, eg
> > > > > /bin/sh: line 1: 2284 Segmentation fault /usr/bin/dpkg_preconfigure...
> > > > > It seems that the kernel used during the initial install was stable,
> > > > > but the kernel it installed on the hard disk is not.
> > > > > Model: Dell Precision Workstation 410 MT
> > > > > BIOS revision A08
> > > > > CPU: 2xPIII 450MHz
> > > > > Video card: 3DLabs Oxygen GVX1
> > > > > Ram: 1024MB
> > > > > Adaptec AIC-7890 BIOS DELL-V2.01.05
> > > > > SCSI ID 0 COMPAQ DDRS-34560W ULTRA2-SE
> > > > > SCSI ID 1 SEAGATE ST173404LW ULTRA2-SE
> > > > > Adaptec AIC-7880 BIOS DELL-V2.01.05
> > > > > SCSI ID 1 MATSHITA DVD-RAM LF-200
> > > > > Primary IDE1 ZIP drive
> > > >
> > > >
> > > > You could use the install CD as a rescue system, choose "run a command
> Ok, that seemed to work ok. Here is what uname -a produces:
> Linux precision 2.6.18-5-486 #1 Fri Jun 1 00:07:22 UTC 2007 i686 GNU/Linux
> vs the kernel on the hard drive, which is:
> Linux precision 2.6.18-5-686 #1 SMP Fri Jun 1 00:47:00 UTC 2007 i686 GNU/Linux
> The only difference I see is the SMP - which as mentioned, I have tried
> disabling with a 'nosmp' argument.
The big difference is the -486 vs -686. Of course, there are no boxes
with more than one 486 so it doesn't need SMP either.
> > > The initial install seems to require the 'aic7xxx.aic7xxx=no_probe' to
> > > complete properly. If I omit that then I get no error but the install
> > > completes much sooner and I assume was truncated by an unreported error,
> > > as much less software ends up being installed.
> > If its happing in the regular filesystem boot (after initrd) then you
> > can add in /etc/modprobe.conf a line:
> > options aic7xxx aic7xxx=no_probe
> Tried that, but it didn't seem to have any effect. There was no
> /etc/modprobe.conf to start with, so I created one with the line
> you suggested. But I'm not sure how to tell if the system is
> paying any attention to it at all...
Try the first command after you boot with your kernel (not the installer
CD) (you could even boot with init=/bin/sh to avoid the init.d scripts)
$ lsmod |grep aic
See if the aic module is even being loaded.
> > if its happening in the initrd, then you have to get the module
> > presumabley the aic7xxx, try adding the module to
> > /etc/initramfs-tools/modules with the parameter
> > aic7xxx no_probe
> > Then you'll need to re-run update-initramfs (possibly from a rescue CD).
> I expected this to be the more likely solution, as the hard disk drivers
> will obviously need to be loaded before any modules can be loaded from
> hard disk...
> Havn't tried it yet - it will be next on my agenda...
> > > After rebooting the system comes up with initd.rc aborting at some
> > > random place with a 'segmentation fault'. But I usually end up with
> > > a login prompt and can log in and execute commands. Errors are sporadic
> > > and unpredictable, and usually involve a command failing with a
> > > segmentation fault. But eventually I get a system lockup that requires
> > > a hard reset to recover from (CTL-ALT-DEL ignored, no key echo etc).
> > > I have also tried adding the aic7xxx.aic7xxx=no_probe kernel option
> > > to /boot/grub/menu.lst as follows:
> > > title Debian GNU/Linux, kernel 2.6.18-5-686
> > > root (hd1,0)
> > > kernel /boot/vmlinuz-2.6.18-5-686 root=/dev/sdb1 ro aic7xxx.aic7xxx=no_probe
> > > initrd /boot/initrd.img-2.6.18-5-686
> > > savedefault
> > >
> > > But that produced no appreciable change. Is there anything wrong with the
> > > way I am doing it?
> > kernel options would only work if the module was actually built into the
> > kernel. Its not, its a separate module inserted by the initrd.
> That explains why my neive approach didn't work. Which is good, because it
> means there is still hope that the no_probe parameter will fix things once
> I get it installed...
> One thing that puzzles me at the moment though, is that I didn't pass
> the 'aic7xxx.aic7xxx=no_probe' option to the rescue system, which seems
> to be working ok.
I don't understand either, but then again, the install CD and its boot
loader are quite complex. I haven't looked at what different kernel
command lines are between 'install' and 'rescue'. Perhaps check on the
CD. I don't know on a CD; on a floppy it was syslinux.cfg.
> That suggests to me that the problem may be a kernel difference and not
> necessarily the scsi driver. I suppose I need to find a way to boot
> properly onto the installed kernel with the scsi disabled to be sure...
> > >
> > > I should also add that the Windows 2000 which was already installed when I
> > > got he system seems to run reliably, as does the obsolete Ubuntu 5.04.
> > > Newer versions of Ubuntu wont install - some giving me a blank screen
> > > after trying to boot the install media, others (including the latest 7.10
> > > release) freeze if the adaptec AIC-7890 is not disabled in the BIOS (which
> > > prevents the install getting very far.
> > In case its not obvious, I had loadable kernel modules for the reasons
> > you're experiencing. If you ever give up on Etch, try OpenBSD.
> Thanks. I do run BSD on my main server, so it is an option ;)
Good luck. You're at the limit of my knowledge and beyond the limit of
my experience. Keep at it. Hopefully someone else will jump in with
"the magic answer".