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

Re: YAIE: Debian on a PowerTower Pro

On Tue, Aug 01, 2000 at 05:44:22PM -0700, C.M. Connelly wrote:
> The quality of Debian's installer varies wildly; some parts seem
> polished and others seem like the kinds of hacks we might have
> seen five years ago.  Debian's current installer isn't just likely
> to put off an iMac owner who wants to play with that cool Linux
> thing she's been hearing about, but may also alienate seasoned
> hackers who have come to expect a certain degree of
> professionalism and polish in an OS installer.

Please remember what you're dealing with here.  It's written by
volunteers, maintained by volunteers, polished by volunteers.  As it
happens, the only person working on Power Mac installs was -me-, and I
only have one.  Not to mention a full time course load at the time.

I'll try to limit myself, but my response to more than half of the
gripes below is "are you volunteering to fix it?".  No one else will. 
I've deleted a lot of those upon rereading, they add nothing but my
annoyance at the problems.

> Some of the choices the installer presented were inappropriate for
> the particular hardware the installer was running on, and
> sometimes entire interaction sequences lead nowhere (such as the
> sequence for creating a boot floppy, which ended with the
> installer informing me that that it couldn't create a boot floppy
> on the PowerPC/PowerMac platform!).

I consider it a miracle that the installer ran on Power Macs at all. 
It took over a month to get it there.  I've got lots I want to see
done, like yaboot configuration, but if you've noticed lately, potato
is frozen.  In fact, it's about to release.  A little late to add
features or major design changes!

> Initial boot using installation and root diskettes.
>    Fine, except for many complaints from the floppy driver of the
>    form:
>       swim3: expected cylinder <n>, got <n+1>

Talk to linuxppc-dev about that one.  It's a kernel bug.  I don't see
it here.

> Debian installer starts
>    Configure keyboard
>       We have a ``mac-us-ext'', but I was surprised by the very
>       limited number of options.  (I believe there were three,
>       only one of which was a non-US keyboard.)

That's because that's all the keymaps that were ever made for the mac
keyboard layer.  That's all redone in late (past few weeks) 2.2 and 2.4
kernels.  We'll have the full set in the next (woody) release.

>    Partitioning hard disk using pdisk
>       The first screen allows you to choose which disk to
>       partition.  On our system, it offered us a menu with
>       /dev/sda, /dev/sdb, and /dev/sdc, but no hints as to which
>       disk was what.  Since the kernel knows which disk
>       corresponds to what device (in /proc/scsi/scsi), it would be
>       more helpful to include that information in the dialog.

A good idea.  Tell debian-boot, which is where most of this belongs,
and maybe someone will try to add it in woody.

>       Once you've chosen a disk, you are unceremoniously dumped
>       into pdisk, without any instructions as to how the program
>       works or what you should do.

That's because pdisk has no documentation :)  I intend to replace it
this coming year.

>       It would be nice if there were some information about the
>       number and size of partitions the user should create (how
>       would a new user have any idea that they need at least two
>       partitions -- root and swap, and that those partitions have
>       to be special types, or have special names?), as well as a
>       quick overview of the commands available within pdisk
>       (especially how to get help, how to save the partitions
>       they've created, and the fact that you can quit pdisk
>       *without* disturbing your existing partitions!).  It would
>       be even better if the partitioning tool were more
>       user-friendly.

People have written up descriptions of what partitions you need.  No
one has added them to the install manual yet.

>       lots of partitions.  I've used partitioning tools for Linux
>       that are much more user-friendly.  They allow you to specify
>       the size of partitions in ``real'' units (megabytes or
>       gigabytes), and can handle at least some of the details
>       related to start points.

And not a single one of them groks Mac partition tables.  We're stuk
with what we have.

>       When you're ready to save the partition map, pdisk says
> 	 Writing the map destroys what was there before.  Is that
>          okay?  [n/y]
>       which is horrible from a user-interface--design standpoint.

File bugs on pdisk's package, mac-fdisk.

>    Initializing and activating the swap partition
>       Because we named the swap partition ``swap'', the installer
>       was able to figure out which partition to use.  If a naive

Yea, that code's crufty.  It will all be rewritten in time.

>    Initializing and activating other partitions
>       A dialog appears that offers you the option to make the ext2
>       partition be compatible with Linux 2.0.x kernels.  Is that a
>       reasonable question to ask given that the 2.0.x kernels
>       won't run on the PowerPC/PowerMac architecture?  Even if
>       they did, or if someone might move the disk to another
>       machine running an older kernel, should the default be to
>       include these features?

This has been discussed on debian-boot in great detail.  The decision
was made to leave the default as it is for all architectures.  I don't
recall why.

>       Once you've decided to go ahead and initialize a partition,
>       a dialog box pops up warning you that initializing
>       partitions will cause them to lose all the data in that
>       partition.  But the default is ``yes''!  (By the time you've
>       repartitioned your disk you've pretty much already lost
>       access to any data, but the issue here is consistency: The
>       installer should either should assume that the user is
>       enough of an expert to default to "Yes" for *all*
>       dangerous-yet-common actions, or take the safe path of
>       defaulting to "No".)

I disagree.  You've already selected to initialize the partition; Enter
to confirm a dangerous action seems logical in that case.  Sometimes it
bears more repeating than other times.  You should be reading the
dialogs anyway.

>       One minor quibble: How many people are going to install the
>       base system from floppy rather than CD, network (http/ftp),
>       NFS, or files downloaded to a hard disk?  (Remember that the
>       base system is 15.7 MB gzipped!)  Why is floppy the default?

No good reason, though we support it.  Choosing an intelligent default
is tricky, though - I think we default to CD when installing from CD
already, on Sparc at least.  Since we can't easily fix it right we left
it alone.

>    Configure device driver modules
>       This procedure requires you to go through a bunch of lists
>       and sublists and pick drivers out by hand.  Unfortunately,
>       it assumes that you actually know not only what each module
>       does, but that a particular module actually works on your
>       hardware.  Some of the modules have useful descriptions, but
>       many of them are cryptic at best, and many others have no
>       descriptions at all!

We get the documentation from the modules themselves.   Fix it in the
kernel if you want it fixed in the installer, at this point.

>       Some examples:


>       In any case, picking modules is pointless.  For every one we
>       tried (and we tried a bunch; at least one from every
>       submenu), we got the error message
> 	 modprobe: Can't locate module XXX
> 	 Installation failed.
>       Poking around, we discovered that there *were* no modules in
>       /lib/modules.  There was a tar file in /tmp, but it had
>       apparently never been unpacked, or else was unpacked to
>       somewhere the installer didn't know about.

Uh.  No one else has reported this.  Also, the list of modules is
generated from /lib/modules last I checked.  If the kernel package is
broken then that needs to be fixed.  What did 'uname -a' show?  What is
in /target/lib/modules?

>    Make Linux bootable directly from the hard disk
>       Runs Quik, apparently.  A dialog appears with lots of text,
>       but it disappears before you can even focus on it.  (All I
>       managed to catch was the word ``Quik''.)  Exactly what
>       happened here, and whether or not it actually worked, is
>       completely unclear.

It rarely works.  You need to configure Quik by hand and be lucky. 
Blame Open Firmware.  This will NOT be fixed for potato, if ever,
since no one wants the nightmare of maintaining quik.

>    Make a boot floppy
>       But our root floppy is still in the drive.  The installer
>       hasn't ejected the disk, and Mac floppies, of course, can
>       only be ejected by software or by poking a bent paperclip
>       into a hole beneath the drive slot.  We decide to overwrite
>       the root floppy with the boot floppy image (we can always
>       make another one, after all.)

Cancel, and choose Eject from the menu.  It's not everywhere in the UI
it should be, because it was only added as a hack.

>       At which point the installer tells us that
> 	 ``Creating a boot floppy is still not possible for
>            PowerPC/PowerMac''
>       It isn't?  Then why did the installer waste our time
>       pretending it was?  Oh, yes, and yet another dialog flashes
>       by too fast to make out.

Because the core logic of dbootstrap is a twisted and impossible mess. 
Will not be fixed for potato.

>    Reboot the system
>       The next dialog assumes that we have a working boot floppy,
>       and tells us to eject it before restarting the machine.
>       Only (1) we don't have a boot floppy, because the system
>       claimed it couldn't make one, and (2) we can't eject it,
>       because the computer is supposed to be smart enough to do
>       that for us.
>       Also, the dialog says ``Please take care of *that* before
>       you answer "Yes" to the following question.''  What,
>       exactly, is ``that'' meant to refer to?  Ejecting the disk?
>       In any case, why do you have to answer ``yes'' to a separate
>       question?  Why not choose ``Proceed'' or ``Reboot now'' or
>       something similarly meaningful?
>       We choose yes.  The machine reboots.  The floppy, of course,
>       is still in the drive, but luckily the Mac is smart enough
>       to recognize that it's not a bootable floppy (remember, it's
>       still a root floppy) and spits it out.
>       The machine then reboots into MacOS.  Huh?  What happened to
>       that Quik stuff we didn't actually get to read anything
>       about?

Did you read any of my announcements on debian-powerpc of boot floppies
releases?   I said, "Make bootable" does NOT work on powerpc, and is
impractical to fix for potato release.  You'll need to go into the
shell on VT2 and do it by hand, or configure BootX.

> A workaround -- Booting with BootX
>    Now what do we do?  Quik wasn't installed, apparently, and the
>    installer couldn't (or wouldn't) create a boot disk.  Luckily, we
>    have BootX and the kernel image (``linux'') downloaded from the
>    installation floppies directory and we know how to use them.  Not
>    everyone would.

Write a howto.  Put it somewhere useful.  Preferably submit it for
inclusion in the documentation.

> The system boots
>    While booting, the kernel complains about ``Unresolved symbols in
>    pcmcia''.  But that's fine, since we don't have PCMCIA hardware
>    anyway.

That's a longstanding kernel bug on powerpc.  I've not been able to
track it down.

>    PCMCIA stuff again
>       The system has figured out that we don't have PCMCIA
>       hardware, and wants to know if it should remove the packages
>       that support that hardware.  Yes!  But why didn't it ask
>       during the install?  (Or, better, figure it out on its own?)

Because dbootstrap can not do any more than it already does; it's a
miracle that it fits on a floppy.  It can NOT figure it out on its own,
because there are enough cases where it would detect lack of PCMCIA and
you want the drivers installed for some reason.  We don't do point and
click average installations; the installer needs to be flexible. 
PCMCIA has to be installed on the boot floppy to support laptop net

>    Apt configuration
>       Asks about the method to use (we choose http), then whether
>       we want to use non-us and non-free.  Asking about non-free
>       here really does make it sound like non-free is part of
>       Debian, which is kind of uncool.  I'm in favor of enabling
>       people to use non-free software if they need or want to, but
>       maybe that support should have its own dialog, or, even
>       better, shouldn't be asked about at all during the basic
>       installation/configuration process, and should require the
>       user to figure out how to get non-free software by reading
>       some documentation (which would, of course, contain plenty
>       of reasons to not use non-free before actually explaining
>       how to do it).

Take this flame to debian-boot, preferably to the archives, where it's
been hashed out a thousand times.

>       Also, it seems weird that the configuration program tests
>       the apt sources by doing an apt-get update, and then does
>       another update before downloading the packages.  Why
>       wouldn't the files it just downloaded work?

Ask tasksel@packages.debian.org.

>    anXious
>       Doesn't know about our video card (an IMS TwinTurbo), and
>       suggests running xviddetect.  How many basic (as in
>       ``shipped with'') cards are there for PowerMacs, and is it
>       at all reasonable for this utility to not know about most if
>       not all of them?  Given that the only X server provided by
>       Debian for PowerPC is the fbdev server, why doesn't anXious
>       know that, and not suggest that we use other X servers that
>       won't work?

Because anXious was not developed by someone with a PowerPC to use it
on, and no one has offered him a patch.  It'll be obsolete in a few
months anyway when we've finished the transition to XF4.

>    SCSI weirdness
>       The system tried to load /lib/modules/2.2.17/scsi/53c7,8xx.o, 
>       and reports some ``unresolved symbols''.  Why would it try
>       to load this module, which has nothing to do with the
>       hardware on the system?  (Doesn't appear to be a problem
>       since I've rebuilt the kernel.)

Did you select it?  Is it in /etc/modules?

> Post-installation oddities
> ==========================
> No X
>    X configuration for PowerPC is still nonexistent.  The base
>    XF86_Config allowed X to start, but it used a bizarre video
>    mode (one that involved setting the display up as a window onto
>    a much larger virtual screen) leaving us to (1) figure out some
>    necessary kernel boot arguments, and (2) hack the XF86_Config
>    file by trial and error.  Not a new complaint, I know, but how
>    difficult can it really be to port the tools that LinuxPPC has
>    to work properly on Debian?  Will this configuration problem go
>    away with XFree86 4.X when it becomes available?

That's a pretty standard XFree86 video mode, actually.  And, porting
the tools is actually fairly complicated, because we handle keyboard
configuration differently.  Of course, it's possible.  No one has done

> Running gdm
>    After installing GDM, which apparently isn't considered to be
>    an integral part of GNOME (?!), GNOME starts with twm, which is
>    not an GNOME-aware window manager.  task-gnome-desktop installs
>    Window Maker, which *is* GNOME-aware.  Shouldn't Window Maker
>    be set to be the default window manager, at least for GNOME?

Talk to debian-gnome?  I think there's such a list.

> /dev missing many useful devices
>    /dev is still grossly underpopulated, although it's better than
>    it was when we built my main system a year ago (at that time,
>    there were no /dev/sdc* devices, which was kind of a hassle
>    since my Linux disk was the third disk on the system).  We had
>    to run MAKEDEV by hand to create additional devices -- why
>    can't the installation or configuration program do that
>    automatically?

Uh.  What are you missing?  We create quite a few.

>    The Debian kernel also doesn't include SCSI generic support, so
>    I had to build a new kernel to get that functionality.  Once
>    that was done, we discovered that the /dev/sg* devices were
>    created with the wrong ownership and permissions, and had to
>    correct them by hand.

OK, if there's need for a new kernel, I'll try to add SG support.  I'm
not going to force a new build of boot floppies for that, though.


/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

Reply to: