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 yet. > 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 /lib/modules/2.6.8-1-generic/kernel/drivers/scsi/sym53c8xx_2/sym53c8xx.ko and /lib/modules/2.4.27-1-generic/kernel/drivers/scsi/sym53c8xx_2/sym53c8xx.o Cut-n-Paste: 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