Re: [VA-Debian] Comments from a first-time Debian install.....
tytso@valinux.com writes:
> 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.
Well, we do make such an image, but it's just the root and rescue
disks slapped together.
This would make a good feature request however.
> > > 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.
There aren't a lot of symlinks -- just for the safe images and
documentation. Which symlinks?
> 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....)
Yes, simple and small. We couldn't fit dhcp-client. Maybe someone
should file bugs against pump so that it complies... ?
> 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. :-)
Yes -- bugs here should be filed against whatever is the relevant
kernel. I think the compact and idepci kernels already do this for
the most part.
> 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.
Well, I don't have much choice -- partially due to the division of
labor in Debian. The kernel maintainers maintain the different
kernels. We just show whatever modules are available. Part of the
problem is that we are using the stock kernels for the most part, so
we really don't have a way to distinguish between modules that are
needed for installation and modules which are perhaps needed at some
point after installation is complete.
Frankly, rather than go through all the effort to fix this, I'd rather
wait for the debian-installer (new installation system), since that
will have most stuff covered via auto-sensing and all that.
> I also didn't find an easy, obvious way to
> bring up the kernel modules dialog box after the system was fully
> installed.
Yes, that should be documented. It's called 'modconf'.
> (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....)
Well, due to the fact that Debian is so big and agnostic, I don't know
if we'll ever have that unity of config that RedHat does.
> 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.
'dpkg-reconfigure base-config'
> (Maybe it shouldn't remove itself until after the
> installation/configuration is completely successful?)
Probably.
> > > 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?
If it sees that there is a network device, yes.
> > > 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).
That's a good idea.
I think the standard packages, contradictorily, are only selected when
there is no tasks selected.
> 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. :-)
No, you're not stupid.
> 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?)
Well, the apt package has pretty good documentation.
> Anyway, thanks for replying. I'm glad to here that folks are dedicated
> towards improving the install process.
Well, thanks for all your good constructive critique. I'll try to get
the time to formulate this as bugs.
--
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
Reply to: