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. > 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. 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? > 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. > 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... > 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. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature