Primarily for Debian developer use:

These are observations on installing Debian on the HP 715/64 platform. Most items noted here will likely be fixed in future versions of the debian-installer and not be a problem.

The atftpd package is incompatible with the PDC bootp client, resulting in timeouts and errors. I tried both with default options and with --retry-timeout 15 --notimeout with the same results. The vanilla tftpd package works fine. At the time I tested tftpd-hpa was broken due to GID problems for which there was an open bug report, so it was not tried.

The plaform used was a 715/64 with 32M of RAM, so the installer was running in low-memory mode. At first I was using installer image 20040801. Then I was told that even though this image is what is under testing's "current" symlink that it was junk and I should use the newest, so I got that from here, filesize 12081152, link dated 15-Sep-2004 01:17. This had all the same problems. I'm told people using a CD ISO between the versions I tried didn't have any major issues, so the problem is likely specific to the network boot image.

Results and comments

During the first install attempt I intentionally forgot to create a palo partition because I was interested in seeing how this was handled by the installer. Overall, the solution chosen was good -- it warns about not having a palo partition when the user finishes and lets them reenter parted. However, the installer is quite slow and some prior warning to help them get it right the first time through would probably improve the user experience.

Here are some suggestions for that and other minor items:

• Some sort of warning should be printed on the main parted window that you need to read instructions on palo. This would decrease the chance of a rework of partitions being needed.
• I didn't check if instructions for palo were available in the help menu items, but if not they need to be there.
• The second time through with the newer image, there was no mount point option on the palo partition. If it is brought back, the palo partition's mount point should either default to none or /boot. The default which the installer offered was /home.
• I don't know if it even matters whether it is set or not, but the "bootable flag" default on a newly created palo partition should probably be set to "on" just so people don't feel obliged to set it.
• On the first install, the palo partition offers no choice for filesystem type, and defaults to ext3. This causes a format failure for small partitions (mine was 88M) probably due to the journal not fitting. So if formatting the palo partition returns in a future release, ext3 should be changed to ext2 automatically on small partitions, and offering a choice on larger partitions might be good too. (I went back in and changed the mount point to "none" before continuing.)
• On the main screen a palo partition's type and use fields are blank. It should say something like "palo/ext3" and "/boot" (or "palo", "none" as the case is with the newer image).
• Once I worked through some other issues, palo failed to run and I had to do so by hand.
• The kernel 2-4-27-32-smp wedges on this platform. The last message is that md: was initialized.
• Two packages, gcc-3.0-base and libstdc++3 would not download at all. They were not listed in the sarge Packages file and no attempt to actually download them was made, though the error message said "can't download". Placing the .debs into the apt cache by hand did not work. Eventually I found that deleting these packages from the hppa section of the architecture switch in scripts/sarge allowed the install to continue. My best guess is that palo used to need these, but no longer does (it did run successfully, albeit by hand.)
• After the system booted, I noticed one package that was selected for installation that probably does not need to be on this arch: bin86.

General (non-HP) comments

• In general, the primary installer developers should all try their product out on a slow system with low memory, so they can gain an appreciation of just how slow it can be and consider that in the overall design.
• When installing the base system, several downloads failed. Unlike the di components, no simple "retry" option was presented. Each time this happened it was necessary to back out and restart the install, which although this allowed the install to continue from where it left of download-wise, took a very long time as packages were rechecked and revalidated.
• It would be nice if an apt-cacher could be specified. This could be done in the same dialogue box as proxy selection. Apt-cacher could also be used for installer components, but might need to be taught how. (Note to self: nominate apt-cacher as one of the most useful peices of truly awful perl code. Along with mrtg and cricket.)
• In the latest image, in lowmem mode at least, loading the ssh client and sshd remote console module fails due to a missing libutil1.