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
s/had/hate/g
> > 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".
Doug.
Reply to: