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

Bug#269529: OldWorld pmac installation -- several problems

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

Reply to: