d-i on ancient hardware
Whee?!
I tested d-i (2006.07.02 daily netinst) on a real 80486 with 24MB
memory, and here's the story. Just note that d-i is completely
outside of my area of expertise, so this is quite a newbish report.
1. The BIOS was too old to support booting from CD. Someone
suggested using SBM, but, too bad, it doesn't appear to be on the
netinst CD. The box doesn't have a working floppy, and the woody on
it lacks drivers for the network card. Fortunately, the box
dual-booted to MS-DOS 6.22(!). And here goes loadlin...
I wonder what's the purpose in shipping loadlin these days. It
needs to be run in real mode, and AFAIK even Windows98 can't be
forced to start it. The incidence of real-mode-capable DOS is so low
that loadlin can be reasonably purged from any space-tight images.
On the other hand, if you insist on keeping loadlin, please provide a
.bat file. A beginner user won't know to look in isolinux.cfg to
copy the append line; also, there's no GPM in stone-age OSes...
2. [G-I]: If the graphics card is not VESA-compliant, the error
message about an invalid _text_ mode can be confusing.
3. [G-I]: On lowmem, it would be better to flat-out refuse to run the
graphical installer; a blank screen is an ugly way to die.
4. [G-I] [Off-topic]: As you already don't support my magnificent 486
and similar, why won't you slap any theme on? The current widgets
are hideous, and since there's space for games...
Ok, let's continue with the text installer...
5. A question "Choose a country, territory or area" has "Choose
language" on the dialog caption. What language, who, where?
Especially as lowmem just gave me a message about continuing in
English, this can be confusing. What about "Choose location"?
6. As proceeding through module selection on lowmem is doomed to
lose, the user needs to turn swap on before. Too bad, the initial
lowmem message doesn't suggest _when_ swap can be turned on.
Various points:
* the lowmem message: console 2 is not yet available
* "Detecting CD-ROMs": this is when ide drivers are probed
* d-i module selection: can't continue past
A simple hint in the lowmem message would save people some time.
7. On 24MB+37MB swap, even with no extra d-i modules chosen, anna
goes into an OOM loop. Increasing the swap to 100MB doesn't help
either.
In fact, I failed to find _any_ way to go past on 24MB physical.
Oh well, I moved the disk to the next machine in my junk pile, a
Pentium1 MMX with 32MB ram.
8. I chosen IPv6 support -- incidentally, my network segment was
v6-only. Yet, DHCP failed and stateless configuration wasn't used
either. The manual config, being given 2002:5033:a761:4::1 started
to lecture me how an "IP" address looks like -- saying "IP" where it
meant "IPv4".
I set up network connectivity manually. By the way, having "ping"
and the like around would be helpful; installation is exactly the
point where network diagnostics is the most useful.
Fortunately, ping works two-way. I had the box world-reachable
(tested) with untested DNS resolution.
9. But yet, the installer won't let me continue until I complete
"network config". With no other option, I gave it a bogus IPv4
address and then restored the connectivity it overwrote.
10. And yet, even though ftp.pl.debian.org is reachable over IPv6,
mirror-chooser wasn't happy. It turns out that the 'wget' binary
provided by busybox is a crippled IPv4-only.
So oh well, I had to make IPv4 work to make it happy.
11. It turned out the disk controller/mobo/something on the P1 box
was somewhat flaky, causing intermittent faults. If something bad
happens during debootstrap, the d-i wrapper over it gives a dialog
box with two choices: "Go back" and "Continue". Too bad, whatever
you choose, it proceeds with the latter -- yet, failing at the end
even if you fix the error manually.
That is, this is the case only if the error happened during the
retrieval/verifying phase. If the error happens during unpack or
configure, _both_ choices act as "Go back", regardless whether you
fix the error by hand or not.
12. Why does it use debootstrap AT ALL? This is something that could
be much better done at d-i build time instead of the installation
itself. Unpacking a tarball takes seconds even on this bitty box.
Debootstrap takes ages on modern hardware, too -- on the order of
5mins on my desktop when pulling debs from a proxy over a 350KB/s
link.
Shaving at least several minutes off every install is not something
to shake a stick at...
Due to unsound hardware, I repeated successful installation thrice to
make sure no further errors can be blamed on the damn P1. For this
reason I also delayed tasksel until after the reboot, on the 486
which is in good condition.
13. When booting, I get "Begin: Waiting for root file system... ..."
and a >5min wait before getting dropped to a shell. It then needs a
"modprobe ide-disk". Curiously, you need to wait several seconds
before closing the shell or it will fail again -- this gives a good
hint towards the cause.
(This happens both on the 486 and the P1, with the same disk).
14. On minimal systems, shouldn't the locale be C.UTF-8 instead of C?
It's a matter of a 9KB deb (much bigger uncompressed). Having both
8bit and UTF-8 locales on a single box -- hell, even on the same
network/company -- is nothing but loudly asking for data loss.
Off-topic: it appears that just opening the locale file takes 20% of
process creation time. This just asks for getting hard-coded[1] into
glibc -- the code is there, it appears that ISO-8859-1 and KOI8-R
used to be hard-coded in the past. And since iswfoo() are always
present anyway...
[1]. "Hard-coded" as in "linked in glibc's code, without a need to
consult external files".
15. Once the installation finished, the keyboard mapping got screwed
on the next boot with regards to Caps Lock:
aBcDeFGHIJKlMnoPQRsTUVWxYz
(especially funny considering that I used a cluster of uppercase
letters as a part of my password)
The nonCapsLockiness touches every letter that has any extra
functions -- like acelnosxz in the polish keymap, cdfgijklmnqsvwxyz
in hungarian, cdeijklmnqsy in danish.
[not subscribed to debian-boot]
Regards,
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
Reply to: