[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Fwd: Installation report: Fujitsu Siemens Amilo pro laptop - freezes on reboot (PCMCIA issue?)]

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


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]


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

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

- 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.



[ 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

Reply to: