Re: extract kernel, modules, base -- annoying aspect of dbootstrap
>
> Well, I'm becoming more and more annoyed by the whole system that
> dbootstrap uses, for instance, in choose_medium.c, to determine from
> where to extract the kernel (rescue.bin), modules, and base.
Nice to hear that I'm not the only person annoyed by that...
> For one, the system is contorted, code-wise.
>
> For two, the system is opaque. It doesn't respond with error messages
> very well when it can't find one or more files. It should log where
> it's looking so the user can fix things..
This is a more general problem. The installer should log all the user input,
actions, errors, files used, etc. into a logfile on the ramdisk which should
then be copied into the target system just before rebooting.
Also the complete dselect or apt installation output should be logged so that
any error encountered can be examined later. In my automatic installer I'm
using the `script' command to capture automatically all the installation
messages from apt and dpkg into a log file. In this way I can get the full
log of the entire installation. This is an invaluable debugging tool if you
are helping someone on the phone to install debian and something goes wrong.
If you don't do this many error or informative messages are lost forever and
you can only try to guess what caused the error, if even you notice that an
error has occurred.
> For three, it doesn't handle errors very well. I pointed it at an
> empty rescue.bin by accident recently, harddisk option, and it then
> gave a failure message (wrong disk, since it couldn't find type.txt),
> and asked me to insert another floppy! But I wasn't working from
> floppy!
>
> Fourthly, it has to be adapted to autosense subarchitectures and such.
>
> Fifthly, the whole 'list vs manually' thing is awkward for the user.
> I think it should try the 'list' method automatically looking in
> reasonable locations, then either present a list of likely candidates,
> or else go to manual.
>
> Sixthly, it should autosense std CDs, IMHO.
>
> Seventhly, ideally, it should have a little dir viewer to help with
> manual selection...
>
> Argh. Comments? Suggestions?
I suggested in the past that the whole selection process could be greatly
simplified if the cd-makers could store on the boot cd a small config file
describing where the requested files can be found. If only relative paths
are used they are still valid also if the cd is accessed via nfs or http.
The user needs then to specify only the top-level installation source, for
example:
cdrom:/debian
server:/path/to/debian
http://server/path/to/debian
The installer program can then read the dist config file from a well-known
location in the source tree and know where the other files are located
without even asking the user. This is simple and effective, and very easy to
implement for both the bootdisk programmers and the cd-makers, at least for
the official cd's.
If this becomes an accepted debian standard and is adequately doucumented
people making their custom distributions can follow the same conventions
and create cdroms compatible with the debian installer (or other custom
installer). I have been using this method from months and it worked fine
with my installer. It should be probably modified to handle multiple
architectures and so on, but it is a good starting point.
Obviously if the config file is missing or points to non existing files the
installer should fallback to old method and ask the user, but this should
not be the case of the official cd or debian mirrors, which is what we should
be most interested to.
Comments?
--
Massimo Dal Zotto
+----------------------------------------------------------------------+
| Massimo Dal Zotto email: dz@cs.unitn.it |
| Via Marconi, 141 phone: ++39-0461534251 |
| 38057 Pergine Valsugana (TN) www: http://www.cs.unitn.it/~dz/ |
| Italy pgp: finger dz@tango.cs.unitn.it |
+----------------------------------------------------------------------+
Reply to: