Your message dated Wed, 17 Jan 2007 02:33:42 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Bug#406813: installation-report: Installation mostly went 
well. Mostly.
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: installation-reports
Version: 2.23
Severity: wishlist

The installation mostly went well.  Mostly.  In the first attempt, I
selected the danish dkuug mirror.  The UI went unresponsive at 40% of
the [downloading a couple of `Release' files] step (it said wget
$mirror/$path/Release in the syslog).  In my impatience, I killed off
wget and select-mirror (did I get the name right?).  I'd suggest
making the ui provide more feedback ("waiting for dkuug to start
sending data", "connection time out, retrying"), and giving the user
the option of cancelling the download and choosing a different mirror,
at any time in the download process.

I would also suggest (i.e. like to have) some way of verifying that
what I think I'm inputting (based on keyboard layout selection) is
what I'm actually inputting (based on on-display feedback) when I'm
typing my password(s).  i can think of two ways to implement this:
either make an "input test" text field next to the password input
field, or make a "show passwords in the clear" checkbox.

Back to my story: the second attempted install went fine.  When I
rebooted, grub gave an error 22.  I previously had grub on my [br]oot
disk (hdb, /, bootable), but before the installer I repartitioned and
created a new type of file system (reiserfs became ext3).  I had the
installation media on my other disk (hda, /home, unbootable); I booted
the installer with a grub that was stored on a floppy disk.

What I think has happened is that the installer installed grub on hda
instead of hdb due to device.map saying "that's the first disk".  I
seem to recall that the device.map I had used previously didn't do the
obvious thing, and so I'm not disappointed in grub getting it wrong
(if that is the case).  However, the installer might want to give
hints to grub as to where to install; the installer might consider
that hdb was bootable and remains so and that hda was unbootable and
remains unchanged.

It is of course possible that the installer fux0red the installation
of grub.  I'm not sure how to test for that; if you want me to
investigate, let me know.

This is my installation media:
http://ftp.debian.org/debian/dists/testing/main/installer-i386/current/images/hd-media/vmlinuz
http://ftp.debian.org/debian/dists/testing/main/installer-i386/current/images/hd-media/initrd.gz
http://cdimage.debian.org/cdimage/weekly-builds/i386/bt-cd/debian-testing-i386-CD-1.iso.torrent

-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-686
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=ISO-8859-1) (ignored: 
LC_ALL set to en_GB.ISO-8859-1)

installation-report depends on no packages.

Versions of packages installation-report recommends:
ii  pciutils                  1:2.2.4~pre4-1 Linux PCI Utilities
ii  reportbug                 3.31           reports bugs in the Debian distrib

-- no debconf information



--- End Message ---
--- Begin Message ---
On Sunday 14 January 2007 11:17, Jonas Koelker wrote:
> The installation mostly went well.  Mostly.  In the first attempt, I
> selected the danish dkuug mirror.  The UI went unresponsive at 40% of
> the [downloading a couple of `Release' files] step (it said wget
> $mirror/$path/Release in the syslog).

Bad mirrors are unfortunately one of the more common causes of failures 
during installations. Often the best solution is to restart and try 
again.

> I would also suggest (i.e. like to have) some way of verifying that
> what I think I'm inputting (based on keyboard layout selection) is
> what I'm actually inputting (based on on-display feedback) when I'm
> typing my password(s).  i can think of two ways to implement this:
> either make an "input test" text field next to the password input
> field, or make a "show passwords in the clear" checkbox.

This may be improved in future by using a different method of keyboard 
selection.

> What I think has happened is that the installer installed grub on hda
> instead of hdb due to device.map saying "that's the first disk".

Grub indeed installs to the MBR of the "first" hard disk. Problems can 
occur if what the installer thinks is the first hard disk is different 
from what the BIOS thinks. However, you can choose to install grub to a 
different location.

We are aware the selecting the disk/partition to install to can be 
improved and this may happen in the future,

As the issues you report are already known and documented, I'm closing 
your report. Thanks for submitting it and for your comments.

Cheers,
FJP

--- End Message ---

Reply via email to