Rick_Thomas wrote: > Output of lspci and lspci -n: > > 0000:00:0b.0 Host bridge: Apple Computer Inc. Bandit PowerPC host bridge (rev 03) > 0000:00:10.0 ff00: Apple Computer Inc. O'Hare I/O (rev 01) > 0000:00:11.0 Ethernet controller: Digital Equipment Corporation DECchip 21041 [Tulip Pass 3] (rev 21) > 0000:00:12.0 VGA compatible controller: ATI Technologies Inc 3D Rage I/II 215GT [Mach64 GT] (rev 41) > > 0000:00:0b.0 0600: 106b:0001 (rev 03) > 0000:00:10.0 ff00: 106b:0007 (rev 01) > 0000:00:11.0 0200: 1011:0014 (rev 21) > 0000:00:12.0 0300: 1002:4754 (rev 41) > Note 1: > > During the language/keyboard choice phase, I took all the defaults > (Language->English, Region->UnitedStates, KeyboardType->USB) until it > came to the Keymap choice. There the default was "European". This is > *not* what I expected -- or what was the default behavior in the past! > Having done everything possible to indicate that I was in the USA and > speaking English, I would have expected the default keymap to be > AmericanEnglish. > > A serious violation of the principle of least astonishment. That's wierd, we don't get that on eg, i386. > Note 2: > > In spite of what lspci says about the ethernet chip being a "Tulip", > it seems to much prefer the "d4x5" driver. I can find nothing in the > output of lspci or in the /proc/device-tree structure that would give > a clue that this is the case. Does anybody know what the difference > between the two drivers is? > > In any case, the network initial configuration phases tried to load > the "tulip" driver, but failed to activate the interface with that > driver, so I had to chose the d4x5 driver manually from the fall-back > list of network drivers. I'll clone a bug off to discover1-data to change the pci ID in its database from tulip to d4x5. > The CD-rom drive is on the apple "mesh" scsi controller. I had go to > the F2 console and manually "modprobe mesh" to get it to recognize the > CD-ROM drive and the SCSI disk. Because the mesh driver module was > loaded behind d-i's back (so to speak), d-i didn't know about it, and > as a result, "mesh" wasn't present in /etc/modules after the reboot. > > Many oldworld PowerMac's have the "mesh" scsi controller as their > *only* (and in any case *primary*) mass-storage interface. Failure to > load the mesh driver module will make it impossible for inexperienced > users to install Debian on their machines. It seems to me that the > mesh driver should be loaded by default on *all* oldworld PowerMac > machines. I suppose this is not an automatically detectable pci device, so I'll clone a bug off to hw-detect, which should do whatever probing it can (maybe using /proc/device-tree like it does for some other mac stuff, if possible), and get the mesh module loaded. > The partitioner seems to default to putting the "noatime" attribute on > new ext3 partitions. This is a violation of the principle of least > astonishment. The default should be standard UNIX behavior! I agree and this is fixed in unstable. > > Note 5: > > For reasons I don't entirely understand, wget does not recover well > from occasional dropped packets, so it times-out and fails during the > "install base system" phase. Retrying the phase works (usually, > barring another dropped packet). This is a common enough problem that > it would seem a good idea to automatically re-try a failing wget a few > times before giving up and bugging the user. d-i itself is rather good about retrying several times. debootstrap is not. Bug cloned to there. > Note 6: > > Prior to the reboot, I tried to "Save debug logs" to a floppy disk. > It failed because "No floppy device was found". The oldworld Macs all > use the "swim3" floppy controller. Do you know if the floppy module is supposed to support this controller? > The default kernel that is offered in the base install phase is 2.6.7, > even though the d-i is running under the 2.6.8 kernel. The 2.6.7 kernel is still hardcoded as the one to install in base-installer. We're in the middle of a kernel transition, I assume this will be changed eventually. > When I > manually chose to install the 2.6.8 kernel, the reboot failed. It > hung very early in the boot process -- before the Tux Penguin image > was supposed to appear at the top of the screen. > > I had to go back and re-do the install and accept the default 2.6.7 > kernel. Very strange! Can you try installing the 2.6.8 kernel package on your system, and boot it and see if you can reproduce this? If so, please file a bug on that kernel package. -- see shy jo
Attachment:
signature.asc
Description: Digital signature