Re: Fresh Etch netinstall problems...
Hi Doug,
Many thanks again for your help and suggestions..
> I've moved your comments around to intersperse them for easier reading.
>
> 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
> > >
>
> > Uname -a returns:
> > Linux precision 2.6.18-5-686 #1 SMP Fri Jun 1 00:47:00 UTC 2007 i686 GNU/Linux
>
> looks OK.
>
> > and /etc/apt/sources.list contains:
> > #
> > # deb cdrom:[Debian GNU/Linux 4.0 r1 _Etch_ - Official i386 NETINST Binary-1 20070820-20:21]/ etch contrib main
> >
> > deb cdrom:[Debian GNU/Linux 4.0 r1 _Etch_ - Official i386 NETINST Binary-1 20070820-20:21]/ etch contrib main
> >
> > deb http://ftp.uk.debian.org/debian/ etch main
> > deb-src http://ftp.uk.debian.org/debian/ etch main
> >
> > deb http://security.debian.org/ etch/updates main contrib
> > deb-src http://security.debian.org/ etch/updates main contrib
> >
>
> looks OK.
>
> > >
> > > You could use the install CD as a rescue system, choose "run a command
> > > on the rootfs" (or whatever it says); it runs your command chrooted to
> > > the system. Try aptitude there (thus with the installer's kernel). If
> > > that works, do a uname -a there and notice any difference.
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.
> > > Needless to say, what you're experiencing shouldn't happen under any
> > > circumstances with Etch (stable).
>
> >
> > 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.
> >
>
> /usr/share/doc/linux-doc-2.6.18/Documentation/scsi/aic7xxx.txt.gz
> says that probing is disabled by default. Perhaps somehow your's is
> being probed. The question is, is it happening in the initrd or on
> a module insertion.
>
> 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...
> if its happening in the initrd, then you have to get the module
> parameters set there. I've never tinkered with initramfs, so the first
> thing to do is to copy your initrd to something like initrd-works.
> Then, since /etc/initramfs-tools/initramfs.conf likely has a line:
>
> MODULES=most
>
> which means that all hard drive modules will be loaded, including
> 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...
In order to try and decide once and for all if it is the AIC-7890 that
is causing the problem, I tried disabling it in the bios and re-installing
onto an external usb drive. Unfortunately the bios doesnt know how to boot
from usb, but I figured I could get around it by installing grub on a
floppy. But unfortunately that didn't seem able to access the usb drive
either, so the only way I could test it was booting of the install CD
and going into rescue mode, forking a shell chrooted into the usb system.
I'm not sure how complete the resulting environment is (I had to manually
mount /proc before I could do a ps), but I was able to run 'startx' and
for the first time (since the obsolete 5.04 Ubuntu) I saw X come completely
up!! The only thing that didn't work for some reason was the mouse - but I
am putting that down to some incompleteness in the chrooted environ,
> > 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.
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 ;)
Regards,
DigbyT
--
Digby R. S. Tarvin digbyt(at)digbyt.com
http://www.digbyt.com
Reply to: