Re: Installation report on AMD Duron system
Thanks for the detailed report.
Paul L. Rogers wrote:
> o Since this is a X window system/desktop environment
> install I would expect installation to complete with
> starting gdm/kdm/xdm. Perhaps a note should be added to
> the "Have fun!" message suggesting a reboot or how to
> manually get the system into the same state as a reboot
> would.
Branden, what should I do here? Is there some reason xdm's postinst
doesn't start xdm?
> o As part of the "Configuring Xserver-xfree86" process, I
> took the default <Yes> when asked "Use kernel
> framebuffer device interface". X would not start since
> the framebuffer drivers for the Matrox G200 video card
> are not included in the kernel that is installed as part
> of the installation process (vmlinuz-2.4.18-bf2.4). It
> would seem to me that at least on the Intel platform,
> <No> would be a better default. Perhaps more specific
> guidance than:
> In theory, either approach should work, but in
> practice, sometimes one does and the other does
> not. Enabling this option is the safe bet, but
> feel free to turn it off if it appears to cause
> problems.
> In my case, enabling this option was NOT the safe bet.
Leaving this for Branden.
> o It appears that support for the RealTek RTL-8139 PCI
> Fast Ethernet Adapter is compiled into the installation
> kernel (vmlinuz-2.4.18-bf2.4). The card was detected
> and configured with no problems. However after
> installing a new kernel (vmlinuz-2.4.18-k7) in an
> attempt to resolve the framebuffer issue, support for
> the 8139 card is via a module (8139too) which was not
> installed during the boot process. What other drivers
> are compiled into the "boot floppies" kernel that are
> not present in the "standard" kernel images? This
> behavior is not very user friendly.
You can copy the /boot/config-2.4.18-bf2.4 file to .config in your
source tree to start at the same place as the shipped kernel.
> o The "rec" command from the sox package is broken. "rec
> x.au" results in "sox: Unknown output file format for
> '': Filetype was not specified". Shouldn't packages
> that are installed by default work? I ran into this one
> a while back upgrading another box that used "rec" as
> part of a real application. See Debian Bug #143262
> <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=143262&repeatmerged=yes>.
> It appears to be fixed in unstable, will the fixed
> package make it into Woody?
Nope, it's too late for this kind of thing to go in.
> o The default /etc/X11/XF86Config-4 file includes a
> reference to the device file "/dev/input/mice". When X
> is started, xf86OpenSerial reports as an error "Cannot
> open device /dev/input/mice No such device." (in
> /var/log/:0.log). No big deal though.
Leaving for Branden..
> o Consideration should be given to splitting dialup and
> ISDN PPP support into two tasks instead of having both
> as part of the dialup system task. I have been using
> dselect to unselect the ISDN packages.
We have talked about it, but are the isdn packages causing you
particular greif, or just eating hard drive space? The next release
after woody will allow drilling down into tasks and fiddling with
individual packages.
> o The partimage-server package will not install properly.
> See the transcript below.
Please file a bug on this.
> o It's too easy to exit tasksel with no obvious way to go
> back.
This is already addressed in unstable, it loops until you tell it you're
done.
--
see shy jo
--
To UNSUBSCRIBE, email to debian-testing-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: