[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#282652: installation report

On Sat, 2004-11-27 at 19:46 -0800, Steve Langasek wrote:
> On Tue, Nov 23, 2004 at 11:06:47AM -0500, Greg Folkert wrote:
> > Tried to do the Multi-User thing and aboot just would not install. This
> > is the guided one-partition thing. I have a gaggle of disk for this
> > thing too.
> Known bug in partman, should be listed now in the errata for RC2.

I'll check. Thanks. Maybe I'll re-build again and see what happens.

> > Output of lspci and lspci -n:
> > 
> > undead:~# lspci
> > 0000:00:00.0 Ethernet controller: Digital Equipment Corporation DECchip
> > 21040 [Tulip] (rev 22)
> > 0000:00:01.0 Non-VGA unclassified device: LSI Logic / Symbios Logic
> > 53c810 (rev 01)
> > 0000:00:02.0 Non-VGA unclassified device: Intel Corp. 82375EB/SB PCI to
> > EISA Bridge (rev 03)
> > undead:~# lspci -n
> > 0000:00:00.0 0200: 1011:0002 (rev 22)
> > 0000:00:01.0 0000: 1000:0001 (rev 01)
> > 0000:00:02.0 0000: 8086:0482 (rev 03)
> > I installed kernel-image-2.4.27-1-generic. It installed OK, but the
> > sym53c8xx module would not load at all. It would not detect the card. I
> > even passed along boot parametrs to get things work, no go. (This
> > I believe is a kernel bug). The funny thing is the installer was using
> > 2.4.26-something. This lead me to try kernel-image-2.6.8-1-generic
> > (v2.6.8-8). I know about v2.6.8-9. I booted from tftp again and
> > did a chroot into the just install system. I installed the
> > 2.6.8-1-generic kernel and rebooted.
> Given the directory you downloaded from, it's not surprising that 2.4.26 was
> used by the installer.  Using the current RC2 images (netboot or otherwise)
> should give you 2.4.27 now.

Good enough, I will re-install as I haven't really done anything with it

> According to discover1-data, the driver for your LSI chip is sym53c8xx_2.
> This module is present in the 2.4.27 kernel images for alpha, so assuming
> this is the right driver, a kernel bug seems a likely explanation.  Do you
> know if this has been reported to the kernel maintainers?

Actually the module is located in a subdir of scsi


undead:/proc/bus# modinfo sym53c8xx
filename:       /lib/modules/2.6.8-1-generic/kernel/drivers/scsi/sym53c8xx_2/sym53c8xx.ko
license:        Dual BSD/GPL
vermagic:       2.6.8-1-generic gcc-3.3
depends:        scsi_transport_spi,scsi_mod
alias:          pci:v00001000d00000001sv*sd*bc*sc*i*
alias:          pci:v00001000d00000002sv*sd*bc*sc*i*
alias:          pci:v00001000d00000003sv*sd*bc*sc*i*
alias:          pci:v00001000d00000004sv*sd*bc*sc*i*
alias:          pci:v00001000d00000005sv*sd*bc*sc*i*
alias:          pci:v00001000d00000006sv*sd*bc*sc*i*
alias:          pci:v00001000d0000000Asv*sd*bc*sc*i*
alias:          pci:v00001000d0000000Bsv*sd*bc*sc*i*
alias:          pci:v00001000d0000000Csv*sd*bc*sc*i*
alias:          pci:v00001000d0000000Dsv*sd*bc*sc*i*
alias:          pci:v00001000d0000000Fsv*sd*bc*sc*i*
alias:          pci:v00001000d00000010sv*sd*bc*sc*i*
alias:          pci:v00001000d00000012sv*sd*bc*sc*i*
alias:          pci:v00001000d00000013sv*sd*bc*sc*i*
alias:          pci:v00001000d00000020sv*sd*bc*sc*i*
alias:          pci:v00001000d00000021sv*sd*bc*sc*i*
alias:          pci:v00001000d0000008Fsv*sd*bc*sc*i*

Basically the same one from 2.4.27-1-generic as well.

> > That booted really well, except for this "sym0:0:0:M_REJECT to send
> > for : 1-2-3-1." was scrolling everything off the screen. Eventually the
> > machine locked up. This was all before the base config was completed. So
> > I ended up booting the installer again and doing a chroot into the
> > installed machine and added ' sym53c8xx="debug:0x80" ' to the boot lines
> > in aboot. That allowed me to boot proper into the base-config at first
> > boot and quell 99% of the debug info.
> Of course, the installer lets you specify module options when run with low
> or medium debconf priority, but you would have to know about this issue when
> first installing to make use of it.

Right, I look into those to see if I can make heads or tails out of it.
If you have the location (URI) of the most recent, I'd be ahppy to make
due with reading it.

> > Once I got the machine to boot proper, I have edited aboot.conf to
> > "appear" to work similarly to update-grub. Someone (if I can hack it)
> > should consider doing a update-aboot script similar to update-grub. It
> > would make things much more simple. It would allow to update the kernel
> > without having to futz with the aboot.conf and hope you got it right.
> > There are some limitations in aboot.conf, but those could be written
> > into the script. Then you could also use this script to actually help
> > the people maintain or change the auto-boot sequence in SRM as well.
> Mmm, I don't see much advantage to a complex script for managing aboot.conf,
> when for most uses all that's needed is to manage a pair of kernel and
> initrd symlinks for the current and previous kernels...

Yeah, I can see the reasoning, not many Alpha "play" machines out there.

> > Also, some explanation of the whole SRM auto-boot setup should probably
> > be discussed during the aboot install. Not that it is hard, just that
> > some people have really never had to deal with SRM. Only ARC (for
> > Windows NT on Alpha). There are even fewer people that have done a
> > conversion from VMS-AXP to Debian Linux as well, dealing with SRM is
> > very archaic to some people.
> I think this is best left to the installation manual, especially considering
> I know of no way to reliably map Linux device names to SRM device names. 
> Suggestions on how to improve the current install manual text are welcome.

Yes, it is best to leave this to the manual. Even the SRM How-to at
alphalinux.org isn't quite readable enough to help figure out changes
being needed. I'll try to re-write the SRM section of the Install Manual
to see if I can help others make heads and tails out of it. 
greg, greg@gregfolkert.net

The technology that is
Stronger, better, faster:  Linux

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: