Re: [VA-Debian] Comments from a first-time Debian install.....
From: Adam Di Carlo <adam@onshore.com>
Date: 03 Dec 2000 01:49:26 -0500
Well, as you probably already know, since the PCMCIA subsystem is by
definition in the form of kernel modules, the only way to solve this
would be to put cardmgr and the pcmcia modules on the "root"
filesystem, so you don't need to load it subsequently.
Yup.... it would probably require making a 2.88 meg el torito boot/root
image, which means it wouldn't fit on a standard 3.5 inch floppy
anymore, but it should be possible on a CD-ROM boot.
> > So I booted back into
> > Windows, created a scratch partition, and copied the entire Debian
> > Potato 2.2 Binary-i386 R0 CD-ROM into that scratch partition and then
> > tried again.
Ah. You probalby could have gotten away with just putting rescue.bin
and drivers.tgz there, but no harm.
Yup, I didn't know that at the time. (No instructions, or at least none
that I was able to find on short notice.)
And it turns out that since I was doing this under Windows, I copied
over files onto a VFAT partition, which means that the symlinks didn't
copy over correctly. This turned out to be a headache later when I
actually tried to use the VFAT partition to apt-get the dhcp-client
client. (No, I didn't realize that pump was installed by default, or I
would have used it, despite the fact that it violates the DHCP RFC's.
Why anyone would want to use pump is beyond me. I guess it is simple.
But anyway....)
> > The second time I tried, I was able to load the kernel modules. This
> > screen here really needs simplifying. There's no reason to make the
> > user decide which modules should be loaded on a full system at such an
> > early point in the install. Regardless of where you fall on the
> > "modules should be dynamically loaded" versus the "modules should be
> > statically loaded at boot-time" argument, at the initial install time
> > only those modules which are desperately needed to install the system
> > should be asked for. If nothing else, deferring this means that the
> > installation system may have more resources at its disposal to provide
> > a more friendly interface to the user.
Well, for instance, even with booting with the 'compact' set, which
has a lot of ethernet cards included, on my system at home, I need the
3c509 driver installed. So, if I want to install the rest of the
system over the network, I need to load the module here.
I guess I should try to clarify in the UI that this step is for
loading modules which are needed for the installation process.
That would definitely be a good thing. And perhaps you should filter
out some modules such as the one for IP Masquerading for Real Audio? Or
the Cyclades serial port driver? Somehow I doubt you'd ever need those
for the installation process. :-)
I assumed since all of the modules that you might ever need were there,
and those modules were loaded upon boot once the system was installed,
that it was a intentional design decision to present all of the modules
at this stage of the game. I also didn't find an easy, obvious way to
bring up the kernel modules dialog box after the system was fully
installed. (My generic gripe about Debian; there's no easy, advertised
way to figure out how to get back to any configuration screen after the
fact. With Red Hat, I can just run "linuxconf", and most things are
there, in one place....) This isn't a major disaster, since I plan to
replace the whole kernel with a custom one that I'm building anyway, but
I did think it was curious.
> > However, because it bombed out, it wasn't able to find the CD-ROM
> > automatically. So the system went into what I later discovered was
> > apt-setup, where one of the questions it asked me was whether I wanted
> > the non-free software or not. I said yes, but given that CD-1 (which I
> > had copied onto a spare partition) doesn't have non-free software, the
> > debian configuration system bombed out that that point ---- no obvious
> > way of restarting it, and nothing on the system except the base system.
> > I fiddled with it a while, and finally decided I was wasting my time, so
> > I rebooted the system, and reinstalled a third time, blowing away
> > everything from the 2nd try installation.
>
> I suppose you told apt-setup to use a mounted filesystem as its access
> method?
>
> Apt-setup should be more robust than that -- it should notice apt has
> failed and tell you and let you correct it. I'd like to try to reproduce
> this problem.
Yes, we should track this down and get a bug filed.
I'm not sure the problem was with apt-setup or with whatever mysterious
configuration program ("Debian System Configuration") that was calling
apt-setup. The point was, though, once apt-setup bombed out, I couldn't
figure out anyway to restart that configuration program short of doing
the installation from scratch again. I tried rebooting, and it had
already taken itself out of whatever bootpath it had used to make sure
it started the first time the system was booted after the install.
(Maybe it shouldn't remove itself until after the
installation/configuration is completely successful?)
> > Networking was not set up automatically for me. The fact that I was
> > using a laptop with a PCMCIA networking card may have caused this; I
> > don't know if a system with a hard-wired networking card would have
> > fared better. I'm surprised that some kind of dhcp client isn't
> > suggested by task-laptop.
>
> There is a dhcp client in the installer itself, and it's supposed to ask
> you about using dhcp when you set up the network.
It does ask you. Works fine for and most users. On the 'configure
network' step, it asks if you wanna use a DHCP server. The default is
yes, and works well.
Umm..... I must have missed it. I didn't see a "configure network"
screen. When I can find a free machine, I'll try reinstalling Debian
again on it and see. Does it always bring up the "configure network"
screen?
> > As a Linux expert, lots of packages I take for granted aren't
> > installed. For example, I had to manually apt-get gpm and strace.
> > (Or if there was a magical task package that would have found them, it
> > wasn't obvious from the install.) That's fine if the machine is on
> > the network, but it gets tiresome pretty quickly if you're not on the
> > network (or you're fighting to get on the network and you need why
> > various networking tools are failing....)
A harder question to answer. Debian has the "standard" priority for
packages which are standard on any unix box. Gpm has always been
installed for me, since it is priority "standard", so that is some
sort of bug that ought to be tracked down, e.g., why you didn't get
this. 'tasksel' is the package in question, that bugs should be filed
against.
Yeah, I was going to ask about that. When I started up "dselect" (I
know, always the wrong answer because of its horrible UI), I saw that it
had selected all of the priority "standard" packages, which were all
pretty much ones I that wanted. I was wondering why the "standard"
packages weren't installed by default in the install process. There
was a list of task packages, for C development, etc. and I checked all
of those, but if there was a task package for all of the "standard"
packages, I must have missed it. (And if I missed it, who supposedly
knows something about computers and Linux, and I don't want to think
what a novice user would have done when faced with the task selection
screen. :-)
Are the "standard" packages always installed by default? I assumed that
they weren't, so it was possible to have a very minimal system (which
is a good thing). But there probably should have been a "task-standard"
packages option, which is checked by default, but which could be
disabled if someone really wanted a minimal system (for example, for a
high security Kerberos server).
Perhaps this exists in the installation system already, in which
consider this a bug report that it should be made more obvious. (Or
perhaps I'm just stupid; you can decide that. :-)
However, the real problem is two-fold: the current installation system
is a hack of nasty C code, shell scripting, and tons and tons of
interdependancies. For people to improve the system is a rather large
curve, and it's quite easy to break things without realizing it.
Yeah, I've started to gather that. I'm still trying to figure out the
interactions between apt-get and dpkg and dselect. You're in a maze of
twisty packages, all different..... (I assume I'd be asking too much if
I asked for a pointer to some documentation on the subject?)
The second reason is simply that it's a volunteer project, and the
volunteers in question (debian developers) don't tend to work on, or I
guess prioritize, the installation system. This is probably quite
related to the first problem.
Good point.....
Hopefully Joey's replacement system will solve all this, will come in
soon, and I won't have to spend my volunteer time maintainer a
basically unmaintainable code base for merely incremental improvements
when it's obvious a gut overhaul is needed.
Well, I'm glad Joey's working on a replacement system. Debian's
certainly isn't; it just reminds me of Red Hat's system in the RH 3.0.3
days. And it's certainly true that Red Hat and Caldera and other
commercial distros have a lot more resources to spend on improving their
installers after every single release, to the point where Red Hat's 6.2
installer (I haven't tried 7.0 yet) is better than a Windows install, at
least in my opinion.
One good thing is that at least Red Hat and I think Caldera's
installation systems are GPL'ed, so it'll be possible to steal a few
components from there, although the fact their system is RPM based will
probably restrict how much you can steal. But for example, the code
that does the setup for a VGA-16 X-based install might be something
which you guys could "borrow".
Anyway, thanks for replying. I'm glad to here that folks are dedicated
towards improving the install process.
- Ted
Reply to: