Forwarding this to the mailing list (as installation-reports get there but probably this one didn't because of the attachment size). BTW, assigned Bug# is 301112. ----- Forwarded message from Javier Fernández-Sanguino Peña <jfs@computer.org> ----- From: Javier Fernández-Sanguino Peña <jfs@computer.org> Date: Wed, 23 Mar 2005 21:48:22 +0100 To: submit@bugs.debian.org Subject: Installation report: Fujitsu Siemens Amilo pro laptop - freezes on reboot (PCMCIA issue?) User-Agent: Mutt/1.5.6+20040907i Package: installation-reports INSTALL REPORT Debian-installer-version: netboot.iso from 20050305 uname -a: Linux metano 2.4.27-2-686 #1 Thu Jan 20 11:10:41 JST 2005 i686 GNU/Linux Date: Wed, 23 Mar 2005 14:13:11 +0100 Method: Install through CD-ROM, packages downloaded from local mirror. Machine: Fujitsu Siemens AMILO PRO laptop Processor: Pentium Mobile (Intel(R) Pentium(R) M processor 1.60GHz) Memory: 512Mb Root Device: IDE disk (hda) Root Size/partition table: Output of lspci and lspci -n: [Please see the attached info] Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot worked: [O] Configure network HW: [O] Config network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Create file systems: [O] Mount partitions: [O] Install base system: [O] Install boot loader: [O] Reboot: [E] Comments/Problems: When the system was rebooted it will not start and froze (no answer to INTRO key) when starting up the Linux PCMCIA services. The precise lines before the freeze: Linux Kernel Card Services 3.1.2 No IRQ known for interrupt pin A of device 01:03.1 No IRQ known for interrupt pin A of device 01:03.0 <frozen> This same error messages already happened when booting the system through the netboot CD, but the system did not froze. Booting in 'recover' mode in GRUB did not work, as didn't work trying to pass the Linux kernel the 'pci=biosirq' arguments it asked me to pass through. I had to reuse the CD, start up the installer in order to access the hard disk and try to rescue the situation by editing the init.d scripts in order to pass that stage. However, I had several issues with that: - I could not get the system to recognise the harddisk until I setup the mirror location so that the installer could download the d-i modules that provided hardware autodetection. - I could not mount the harddisk until I first did 'mknod hda block 3 0' to be able to have a /dev/hda and view the partition table with cfdisk so that I could see the partition and then 'mknod /dev/hda8 block 3 8; mkdir /mnt/; mount -t ext3 /dev/hda8 /mnt' to mount the partition. - I could not determine precisely which init script had the issue (since the name of the init.d script was not shown before it was executed) so I added 'exit 0' statements to both discover, pcmcia and hotplug. With this done I was able to boot the system, test the discover script and hotplug scripts (which worked) and left the pcmcia script disabled. Then proceeded to the rest of the installation. This is hardly something a novice user would be able to do. IMHO this could have been easier if it would be possible (in Debian, not specific to the installer actually) to run the init.d script in an atomic way (i.e. the user is asked before any init.d script is run and he can control all the bootup process) this is something RedHat has been doing since the 7.x releases IIRC and something that even Windows does. We should definitely push that way, maybe by introducing lsb-standard calls to init.d services. Usability notes: ---------------- - As I mentioned in #260934, the d-i screens only have a 'Back' button and not an 'OK' button. This is not only confusing (users are _used_ to see both buttons in a screen, be it a GUI or a curses-UI) but also is not consistent with what boot-floppies did, what the base-config script does and what the debconf screens do. Pretty, please, put back the 'OK' buttons in a next d-i release. - There is no introduction to the console prompt available in the d-i media. It could, at least, indicate that the available editor is 'nano' (IIRC in boot-floppies there was a message saying that it was 'ae') - The console prompt does not indicate that there is only a limited set of commands available in netboot until you download the d-i udeb packages from a mirror. - The 'choose-mirror' module will only use 'http' for downloads in normal mode and the only way to get the 'ftp' mechanism is going "Back" and selecting the menu item and then the method. For non-expert users it might be OK to ask only for the server (and directory) for the local Debian mirror but it would be good to test that with _both_ http and ftp so that the user doesn't start scratching his head on why did the download fail. Actually, there is no message of _why_ the mirror access fails when you are trying http access for a ftp mirror (that could be improved). Shouldn't it be better if 'validate_mirror' in choose-mirror's choose-mirror.c tested first for http access and, if it fails, for ftp access? - After the d-i run, base-config asks (again) for the current location for both timezone configuration and package downloads. This information was already asked for in d-i and it should be reused there (maybe passing it as other parameters in the deboostrap config placed in Post-installation notes: ------------------------ - nfs-common and the portmapper are installed by default, this is probably because these are Standard: priority and aptitude pulls them in (as I suggested in #260934) but the first one doesn't seem needed at all for a desktop environment. - gcc, g++, libc6-dev, flex and some other development-only packages where pulled in even if I only selected the "Desktop" task and no other packages. I believe this is because apt "Suggests:" dpkg-dev and aptitude pulls that package and all its dependancies. It seems rather stupid to have compilers installed in a desktop only system, and this is even somewhat dangerous since some worms have used this in the past to propagate. This is probably a bug in aptitude (no -dev packages should be pulled in from Suggests unless you are installing a -dev package itself) but IMHO base-config should have prevent this by (maybe) trimming down the packages that aptitude would pull in. Given the current status, there is no way for base-config to override what aptitude might want to do and if somebody places a wrong 'Suggests:' in some packages a default installation might end up bloated. This feature might be needed in the future for some point cases in case aptitude does not work around this, and could have been used in this installation to prevent base-config from asking the installation of nfs-common when I'm actually asking for a Desktop Environment. In a Desktop install a judicious user ends up with the following services exposed to the network: rpc.statd, portmap, and authd (again, blame the inetd default configuration, like I did in #260934). Since we _don't_ provide a custom firewall configuration then that means that desktop users running Debian are more exposed than they should be. Hopefully this information is useful. Regards Javier [ For full logs of the installation as well as some additional information (lsof, dpkg --get-selections, lsmod, etc.) please see the attached info ]
Attachment:
signature.asc
Description: Digital signature