Bug#1475: base disk (16th September) test install results
Package: base disks
Version: 16th September
The kernel problem I reported earlier is still present, so I had to
boot from a fairly old 1.2.x kernel of my own with some funny boot
I asked for a uk keymap and saw
sed: can't read /root/etc/init.d/console
or some such.
The network setup bit of the base configuration doesn't leave room for
hosts without an FQDN. If you give it a null domain portion you end
up with an FQDN of `<hostname>.' with a spurious full stop, and this
gets copies into various files. There are systems which do not have
FQDNs and we should allow people to set their machines up to reflect
I couldn't select any modules - I tried to select msdos, lp and
binfmt_elf, but in each case I was told the module didn't exist.
When I asked to reboot the system, just before it rebooted I saw:
error writing /etc/mtab.tmp: No space left on device
or something like it.
When I tried to reboot using the bootdisk the root disk made for me I
got the same kernel problem as before.
The kbd console problem (Bug#1181) bit me *again* and I had to reboot
using my emergency floppy and replace the contents of
/etc/init.d/console with `exit 0'.
When it started syslogd as part of the initial boot I saw the message
about syslog/udp unknown service (see Bug#1189).
My TERM variable was set to con132x43, unfortunately (this was a
feature of the kernel I was using). This caused ncurses (as compiled
into dselect) to critique the /etc/termcap file and then fail to work
properly. Retrying with TERM=linux helped, but by then I'd had to
leave the auto-installer thing that runs dselect automatically (this
may or may not be relevant to some of the other problems).
I tripped over a bug in the 0.93.75 dselect hard disk method script,
and had to upgrade manually to 0.93.77 and re-run dselect.
dpkg produced serious warning messages about the files lists for the
following packages being missing: ncurses_runtime, samba, librl,
binutils, libc, netbase. Even half-installed packages need a file
When it came to configuring the system (as part of the [I]nstall
dselect menu option) Smail failed because hostname failed with
`unknown server error'. It turned out that I was lacking an
/etc/host.conf file, so I created one containing just `order hosts'.
Rerunning the configuration produced a complaint from Smail's postinst
that the FQDN it got from hostname --fqdn wasn't valid (it got
`chiark.' with a trailing full stop). I edited the spurious dot out
of /etc/hosts and then things went better.
/var/spool/mail was missing. This file is NOT part of the MTA
packages (so that, for example, you can switch MTA without getting
messages about the mail spool and ENOTEMPTY). Please ensure that the
base disks come with:
chiark:~> ll -d /var/spool/mail
drwxrwsr-x 2 root mail 1024 Sep 22 23:23 /var/spool/mail/
chiark:~> ll -dn /var/spool/mail
drwxrwsr-x 2 0 8 1024 Sep 22 23:23 /var/spool/mail/
The lack of /var/spool/mail caused the test message to fail (and of
course it couldn't bounce it anywhere either, so it left it in the
spool and wrote a message to its logs).
I got many conffiles prompts about things like /etc/init.d/netbase,
/etc/gateways and /etc/smb.conf, but there weren't any differences to
be seen and I didn't think any scripts had done much editing. This
indicates a problem with the /var/lib/dpkg/status file provided on the
base disks. This file should contain, for each conffile, the MD5
checksum of the version in the installed .deb file - if it doesn't
then dpkg will produce a conffiles prompt at the next upgrade (ie, at
the time of the initial dpkg run).
You can either get dpkg to set up these conffiles for you, for example
by using the --configure option on the base disks' system (though this
would run postinst scripts too), or by editing the status file
directly. The format of the conffiles info is as in the following
[ many other fields deleted ]
In place of the MD5 checksum you may also see `newconffile' which
means that the file wasn't noted as a conffile before, but is in the
process of being marked that way (this state is frequently found after
packages have been unpacked but not configured), or `nonexistent',
which means that the .deb file corresponding to the most recent
install didn't contain a copy of the file.