Debian Bug report logs - #501306
update-grub fails silently with wrong device.map

version graph

Package: grub; Maintainer for grub is GRUB Maintainers <pkg-grub-devel@lists.alioth.debian.org>;

Reported by: Dan Poltawski <dan.poltawski@lancaster.ac.uk>

Date: Mon, 6 Oct 2008 12:48:01 UTC

Severity: critical

Merged with 498353

Found in version grub/0.97-47

Fixed in version grub/0.97-47lenny1

Done: Robert Millan <rmh@aybabtu.com>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#501306; Package grub. (Mon, 06 Oct 2008 12:48:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Dan Poltawski <dan.poltawski@lancaster.ac.uk>:
New Bug report received and forwarded. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Mon, 06 Oct 2008 12:48:04 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Dan Poltawski <dan.poltawski@lancaster.ac.uk>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: update-grub fails with raid1 boot partition
Date: Mon, 06 Oct 2008 13:44:48 +0100
Package: grub
Version: 0.97-47
Severity: critical
Justification: breaks unrelated software


When installing new kernels onto the system, the kernel package post
instalation fails on update-grub (output attached below), this 
problem has also affected a number of my collegues, all of us have
a raid1 configuration on our boot partition.

I tried to get to the bottom of the problem by running the following 
steps:

Running update-grub manually produces the errored status:

root@cream:~# update-grub 
Searching for GRUB installation directory ... found: /boot/grub
root@cream:~# echo $?
1

Upon investigation of the update-grub script, I tracked the problem down to
line 155 of update grub:
    GRUB_LEGACY_0_BASED_PARTITIONS=1 grub-probe --device-map=${device_map} -t drive -d "$1" 2> /dev/null


I discovered the options that were being used and this is the command which is being run:

root@cream:~# /usr/sbin/grub-probe --device-map=/boot/grub/device.map -t drive -d "/dev/sda1"
error: cannot open `/dev/sdf'
error: cannot open `/dev/sdf'
grub-probe: error: Cannot find a GRUB drive for /dev/sda1.  Check your device.map.


This results in convert() returning error status.

Please let me know if I can be of any more assistance



APT OUTPUT:

Setting up linux-image-2.6.26-1-686 (2.6.26-5) ...
Running depmod.
Running mkinitramfs-kpkg.
initrd.img(/boot/initrd.img-2.6.26-1-686
) points to /boot/initrd.img-2.6.26-1-686
 (/boot/initrd.img-2.6.26-1-686) -- doing nothing at /var/lib/dpkg/info/linux-image-2.6.26-1-686.postinst line 569.
vmlinuz(/boot/vmlinuz-2.6.26-1-686
) points to /boot/vmlinuz-2.6.26-1-686
 (/boot/vmlinuz-2.6.26-1-686) -- doing nothing at /var/lib/dpkg/info/linux-image-2.6.26-1-686.postinst line 569.
Running postinst hook script update-grub.
Searching for GRUB installation directory ... found: /boot/grub
/dev/sda1 /boot/grub/device.map
User postinst hook script [update-grub] exited with value 1
dpkg: error processing linux-image-2.6.26-1-686 (--configure):
 subprocess post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of linux-image-2.6-686:
 linux-image-2.6-686 depends on linux-image-2.6.26-1-686; however:
  Package linux-image-2.6.26-1-686 is not configured yet.
dpkg: error processing linux-image-2.6-686 (--configure):
 dependency problems - leaving unconfigured
Setting up libpq5 (8.3.4-1) ...
Errors were encountered while processing:
 linux-image-2.6.26-1-686
 linux-image-2.6-686
E: Sub-process /usr/bin/dpkg returned an error code (1)


-- Package-specific info:

*********************** BEGIN /boot/grub/device.map
(hd0)	/dev/sde
(hd1)	/dev/sdf
*********************** END /boot/grub/device.map

*********************** BEGIN /proc/mounts
/dev/mapper/vg0-root / ext3 rw,errors=remount-ro,data=ordered 0 0
/dev/mapper/vg0-root /dev/.static/dev ext3 rw,errors=remount-ro,data=ordered 0 0
/dev/md0 /boot ext3 rw,errors=continue,data=ordered 0 0
/dev/mapper/vg0-home /home ext3 rw,errors=continue,data=ordered 0 0
/dev/mapper/vg0-srv /srv ext3 rw,errors=continue,data=ordered 0 0
/dev/mapper/vg0-usr /usr ext3 rw,errors=continue,data=ordered 0 0
/dev/mapper/vg0-var /var ext3 rw,errors=continue,data=ordered 0 0
*********************** END /proc/mounts

*********************** BEGIN /boot/grub/menu.lst
# menu.lst - See: grub(8), info grub, update-grub(8)
#            grub-install(8), grub-floppy(8),
#            grub-md5-crypt, /usr/share/doc/grub
#            and /usr/share/doc/grub-legacy-doc/.

## default num
# Set the default entry to the entry number NUM. Numbering starts from 0, and
# the entry number 0 is the default if the command is not used.
#
# You can specify 'saved' instead of a number. In this case, the default entry
# is the entry saved with the command 'savedefault'.
# WARNING: If you are using dmraid do not change this entry to 'saved' or your
# array will desync and will not let you boot your system.
default		0

## timeout sec
# Set a timeout, in SEC seconds, before automatically booting the default entry
# (normally the first entry defined).
timeout		5

# Pretty colours
color cyan/blue white/blue

### PASSWORD LINE REMOVED ###
# If used in the first section of a menu file, disable all interactive editing
# control (menu entry editor and command-line)  and entries protected by the
# command 'lock'
### PASSWORD LINE REMOVED ###
### PASSWORD LINE REMOVED ###
### PASSWORD LINE REMOVED ###

#
# examples
#
# title		Windows 95/98/NT/2000
# root		(hd0,0)
# makeactive
# chainloader	+1
#
# title		Linux
# root		(hd0,1)
# kernel	/vmlinuz root=/dev/hda2 ro
#

#
# Put static boot stanzas before and/or after AUTOMAGIC KERNEL LIST

### BEGIN AUTOMAGIC KERNELS LIST
## lines between the AUTOMAGIC KERNELS LIST markers will be modified
## by the debian update-grub script except for the default options below

## DO NOT UNCOMMENT THEM, Just edit them to your needs

## ## Start Default Options ##
## default kernel options
## default kernel options for automagic boot options
## If you want special options for specific kernels use kopt_x_y_z
## where x.y.z is kernel version. Minor versions can be omitted.
## e.g. kopt=root=/dev/hda1 ro
##      kopt_2_6_8=root=/dev/hdc1 ro
##      kopt_2_6_8_2_686=root=/dev/hdc2 ro
# kopt=root=/dev/mapper/vg0-root ro

## default grub root device
## e.g. groot=(hd0,0)
# groot=(hd0,0)

## should update-grub create alternative automagic boot options
## e.g. alternative=true
##      alternative=false
# alternative=true

## should update-grub lock alternative automagic boot options
## e.g. lockalternative=true
##      lockalternative=false
# lockalternative=false

## additional options to use with the default boot option, but not with the
## alternatives
## e.g. defoptions=vga=791 resume=/dev/hda5
# defoptions=

## should update-grub lock old automagic boot options
## e.g. lockold=false
##      lockold=true
# lockold=false

## Xen hypervisor options to use with the default Xen boot option
# xenhopt=

## Xen Linux kernel options to use with the default Xen boot option
# xenkopt=console=tty0

## altoption boot targets option
## multiple altoptions lines are allowed
## e.g. altoptions=(extra menu suffix) extra boot options
##      altoptions=(single-user) single
# altoptions=(single-user mode) single

## controls how many kernels should be put into the menu.lst
## only counts the first occurence of a kernel, not the
## alternative kernel options
## e.g. howmany=all
##      howmany=7
# howmany=all

## should update-grub create memtest86 boot option
## e.g. memtest86=true
##      memtest86=false
# memtest86=true

## should update-grub adjust the value of the default booted system
## can be true or false
# updatedefaultentry=false

## should update-grub add savedefault to the default options
## can be true or false
# savedefault=false

## ## End Default Options ##

title		Debian GNU/Linux, kernel 2.6.26-1-vserver-686-bigmem
root		(hd0,0)
kernel		/vmlinuz-2.6.26-1-vserver-686-bigmem root=/dev/mapper/vg0-root ro 
initrd		/initrd.img-2.6.26-1-vserver-686-bigmem

title		Debian GNU/Linux, kernel 2.6.26-1-vserver-686-bigmem (single-user mode)
root		(hd0,0)
kernel		/vmlinuz-2.6.26-1-vserver-686-bigmem root=/dev/mapper/vg0-root ro single
initrd		/initrd.img-2.6.26-1-vserver-686-bigmem

title		Debian GNU/Linux, kernel 2.6.26-1-686
root		(hd0,0)
kernel		/vmlinuz-2.6.26-1-686 root=/dev/mapper/vg0-root ro 
initrd		/initrd.img-2.6.26-1-686

title		Debian GNU/Linux, kernel 2.6.26-1-686 (single-user mode)
root		(hd0,0)
kernel		/vmlinuz-2.6.26-1-686 root=/dev/mapper/vg0-root ro single
initrd		/initrd.img-2.6.26-1-686

title		Debian GNU/Linux, kernel 2.6.24-1-686
root		(hd0,0)
kernel		/vmlinuz-2.6.24-1-686 root=/dev/mapper/vg0-root ro 
initrd		/initrd.img-2.6.24-1-686

title		Debian GNU/Linux, kernel 2.6.24-1-686 (single-user mode)
root		(hd0,0)
kernel		/vmlinuz-2.6.24-1-686 root=/dev/mapper/vg0-root ro single
initrd		/initrd.img-2.6.24-1-686

### END DEBIAN AUTOMAGIC KERNELS LIST
*********************** END /boot/grub/menu.lst

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-vserver-686-bigmem (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages grub depends on:
ii  grub-common             1.96+20080724-10 GRand Unified Bootloader, version 
ii  libc6                   2.7-13           GNU C Library: Shared libraries
ii  libncurses5             5.6+20080830-1   shared libraries for terminal hand

grub recommends no packages.

Versions of packages grub suggests:
pn  grub-legacy-doc               <none>     (no description available)
ii  mdadm                         2.6.7-3.1  tool to administer Linux MD arrays
pn  multiboot-doc                 <none>     (no description available)

-- no debconf information




Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#501306; Package grub. (Mon, 06 Oct 2008 17:06:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Felix Zielcke <fzielcke@z-51.de>:
Extra info received and forwarded to list. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Mon, 06 Oct 2008 17:06:02 GMT) Full text and rfc822 format available.

Message #10 received at 501306@bugs.debian.org (full text, mbox):

From: Felix Zielcke <fzielcke@z-51.de>
To: Dan Poltawski <dan.poltawski@lancaster.ac.uk>, 501306@bugs.debian.org
Subject: Re: Bug#501306: update-grub fails with raid1 boot partition
Date: Mon, 06 Oct 2008 19:02:52 +0200
Hello,

Am Montag, den 06.10.2008, 13:44 +0100 schrieb Dan Poltawski:
> root@cream:~# /usr/sbin/grub-probe --device-map=/boot/grub/device.map -t drive -d "/dev/sda1"
> error: cannot open `/dev/sdf'
> error: cannot open `/dev/sdf'
> grub-probe: error: Cannot find a GRUB drive for /dev/sda1.  Check your device.map.


> *********************** BEGIN /boot/grub/device.map
> (hd0)	/dev/sde
> (hd1)	/dev/sdf
> *********************** END /boot/grub/device.map

If you do `grub-install /dev/sda' then it should be in your device.map.
Either run "grub-mkdevicemap --no-floppy" or grub-install with `--recheck --no-floppy'.

By the way grub2 does support the linux software raid fully, with it you
could just do `grub-install "(md0)"' if /dev/md0 is your /boot, to
install it on all raid disks.





Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#501306; Package grub. (Mon, 06 Oct 2008 17:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Felix Zielcke <fzielcke@z-51.de>:
Extra info received and forwarded to list. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Mon, 06 Oct 2008 17:21:03 GMT) Full text and rfc822 format available.

Message #15 received at 501306@bugs.debian.org (full text, mbox):

From: Felix Zielcke <fzielcke@z-51.de>
To: 501306@bugs.debian.org
Cc: Dan Poltawski <dan.poltawski@lancaster.ac.uk>
Subject: Re: Bug#501306: update-grub fails with raid1 boot partition
Date: Mon, 06 Oct 2008 19:18:08 +0200
Am Montag, den 06.10.2008, 19:02 +0200 schrieb Felix Zielcke:

> 
> If you do `grub-install /dev/sda' then it should be in your device.map.
> Either run "grub-mkdevicemap --no-floppy" or grub-install with `--recheck --no-floppy'.

Urm I forgot somehow that you're talking about update-grub not
grub-install.
But somewhere /dev/sda has to come from which isn't visible on the
report.
Is your /dev/md0 over sda or something like that?





Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#501306; Package grub. (Mon, 06 Oct 2008 19:09:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Samat K Jain <samat@samat.org>:
Extra info received and forwarded to list. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Mon, 06 Oct 2008 19:09:05 GMT) Full text and rfc822 format available.

Message #20 received at 501306@bugs.debian.org (full text, mbox):

From: Samat K Jain <samat@samat.org>
To: 501306@bugs.debian.org
Subject: Incorrect device.map
Date: Mon, 6 Oct 2008 15:07:41 -0400
I've seen this on one of my machines as well, I've fixed it with what I've provided below.

I've 8 PATA disks (4 of which make up a RAID1 array used for booting), and 3 SATA disks. /boot's device was /dev/md0 (Dan appears to have a similar configuration).

During some previous upgrade, /boot/grub/device.map was regenerated, and it was missing some of the devices that made up the boot RAID array. That device.map is missing devices seems to be the problem here.

Felix, as you mention, my solution was to run:

grub-mkdevicemap --no-floppy

which regenerated the device.map file. This time, the regenerated file was correct, and update-grub ran successfully.

You could also edit device.map manually to make sure all required devices are there.

-- 
Samat Jain <http://samat.org/> | GPG: 0x1A1993D3
Partner, Chief Technology Officer | Rhombic Networks, LLC

A witty saying proves nothing, but saying something pointless gets people's attention.
-- Anonymous (409)




Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#501306; Package grub. (Tue, 07 Oct 2008 08:57:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Dan Poltawski <dan.poltawski@lancaster.ac.uk>:
Extra info received and forwarded to list. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Tue, 07 Oct 2008 08:57:07 GMT) Full text and rfc822 format available.

Message #25 received at 501306@bugs.debian.org (full text, mbox):

From: Dan Poltawski <dan.poltawski@lancaster.ac.uk>
To: Felix Zielcke <fzielcke@z-51.de>
Cc: 501306@bugs.debian.org, Dan Poltawski <dan.poltawski@lancaster.ac.uk>
Subject: Re: Bug#501306: update-grub fails with raid1 boot partition
Date: Tue, 7 Oct 2008 09:53:57 +0100
[Message part 1 (text/plain, inline)]
Hi,

(sorry for second mail -  didn't send to bug)

On Mon, Oct 06, 2008 at 07:18:08PM +0200, Felix Zielcke wrote:
> Am Montag, den 06.10.2008, 19:02 +0200 schrieb Felix Zielcke:
> > If you do `grub-install /dev/sda' then it should be in your device.map.
> > Either run "grub-mkdevicemap --no-floppy" or grub-install with `--recheck --no-floppy'.
> 
> Urm I forgot somehow that you're talking about update-grub not
> grub-install.
> But somewhere /dev/sda has to come from which isn't visible on the
> report.
> Is your /dev/md0 over sda or something like that?

Yes, md0 is over sda1 and sdb1:

danp@cream:~$ cat /proc/mdstat 
Personalities : [raid1] 
md2 : active raid1 sdb3[1] sda3[0]
      241207872 blocks [2/2] [UU]
      
md1 : active (auto-read-only) raid1 sda2[0] sdb2[1]
      1951808 blocks [2/2] [UU]
      
md0 : active raid1 sda1[0] sdb1[1]
      979840 blocks [2/2] [UU]


> During some previous upgrade, /boot/grub/device.map was regenerated, and it was missing some 
> of the devices that made up the boot RAID array. 

Just in response to this - my problem has not been caused by an upgrade - it was a clean lenny install
onto a new machine a few days ago.

Thanks,

Dan
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#501306; Package grub. (Wed, 08 Oct 2008 05:39:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Samat K Jain <samat@samat.org>:
Extra info received and forwarded to list. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Wed, 08 Oct 2008 05:39:02 GMT) Full text and rfc822 format available.

Message #30 received at 501306@bugs.debian.org (full text, mbox):

From: Samat K Jain <samat@samat.org>
To: 501306@bugs.debian.org, Dan Poltawski <dan.poltawski@lancaster.ac.uk>
Cc: Felix Zielcke <fzielcke@z-51.de>
Subject: Re: Bug#501306: update-grub fails with raid1 boot partition
Date: Wed, 8 Oct 2008 01:35:53 -0400
[Message part 1 (text/plain, inline)]
On Tuesday 07 October 2008 04:53:57 am Dan Poltawski wrote:
> Just in response to this - my problem has not been caused by an upgrade - it was a clean lenny install
> onto a new machine a few days ago.

Well, something regenerated device.map since installation. I don't think your system would boot with the device.map you've provided---grub would have ever installed properly. I believe, from what you've provided, your device.map should contain:

(hd0) /dev/sda
(hd1) /dev/sdb

Did you try the workaround? Namely running `grub-mkdevicemap --no-floppy` again?

-- 
Samat Jain <http://samat.org/> | GPG: 0x1A1993D3
Partner, Chief Technology Officer | Rhombic Networks, LLC

The universe is like a safe to which there is a combination -- but the combination is locked up in the safe.
-- Peter DeVries (152)
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#501306; Package grub. (Wed, 08 Oct 2008 09:54:18 GMT) Full text and rfc822 format available.

Acknowledgement sent to Dan Poltawski <dan.poltawski@lancaster.ac.uk>:
Extra info received and forwarded to list. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Wed, 08 Oct 2008 09:54:18 GMT) Full text and rfc822 format available.

Message #35 received at 501306@bugs.debian.org (full text, mbox):

From: Dan Poltawski <dan.poltawski@lancaster.ac.uk>
To: Samat K Jain <samat@samat.org>
Cc: 501306@bugs.debian.org, Dan Poltawski <dan.poltawski@lancaster.ac.uk>, Felix Zielcke <fzielcke@z-51.de>
Subject: Re: Bug#501306: update-grub fails with raid1 boot partition
Date: Wed, 8 Oct 2008 10:46:26 +0100
[Message part 1 (text/plain, inline)]
On Wed, Oct 08, 2008 at 01:35:53AM -0400, Samat K Jain wrote:
> On Tuesday 07 October 2008 04:53:57 am Dan Poltawski wrote:
> > Just in response to this - my problem has not been caused by an upgrade - it was a clean lenny install
> > onto a new machine a few days ago.
> 
> Well, something regenerated device.map since installation. I don't think your system would boot with the device.map you've provided---grub would have ever installed properly. I believe, from what you've provided, your device.map should contain:
> 
> (hd0) /dev/sda
> (hd1) /dev/sdb
> 
> Did you try the workaround? Namely running `grub-mkdevicemap --no-floppy` again?

Yes I did, this does resolve the problem and also contains the same map as
you guessed at.

I'm looking through the apt log to see if I can find anything which would
regenerate the device.map since install.


Dan
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#501306; Package grub. (Thu, 09 Oct 2008 19:30:10 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jeroen Dekkers <jeroen@dekkers.cx>:
Extra info received and forwarded to list. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Thu, 09 Oct 2008 19:30:10 GMT) Full text and rfc822 format available.

Message #40 received at 501306@bugs.debian.org (full text, mbox):

From: Jeroen Dekkers <jeroen@dekkers.cx>
To: Dan Poltawski <dan.poltawski@lancaster.ac.uk>
Cc: Samat K Jain <samat@samat.org>, 501306@bugs.debian.org, Felix Zielcke <fzielcke@z-51.de>
Subject: Re: Bug#501306: update-grub fails with raid1 boot partition
Date: Thu, 9 Oct 2008 21:27:51 +0200
On Wed, Oct 08, 2008 at 10:46:26AM +0100, Dan Poltawski wrote:
> On Wed, Oct 08, 2008 at 01:35:53AM -0400, Samat K Jain wrote:
> > On Tuesday 07 October 2008 04:53:57 am Dan Poltawski wrote:
> > > Just in response to this - my problem has not been caused by an upgrade - it was a clean lenny install
> > > onto a new machine a few days ago.
> > 
> > Well, something regenerated device.map since installation. I don't think your system would boot with the device.map you've provided---grub would have ever installed properly. I believe, from what you've provided, your device.map should contain:
> > 
> > (hd0) /dev/sda
> > (hd1) /dev/sdb
> > 
> > Did you try the workaround? Namely running `grub-mkdevicemap --no-floppy` again?
> 
> Yes I did, this does resolve the problem and also contains the same map as
> you guessed at.
> 
> I'm looking through the apt log to see if I can find anything which would
> regenerate the device.map since install.

It might be possible that the names sda to sdd were used for something
that wasn't an hard disk during the install (a card reader with 4
different slots might be a good candidate). Then your system would
still boot properly with your old device.map because grub detected
that sde was the first hard disk, but then you wouldn't be able to
run update-grub because your first hard disk is sda now. Could you
check this in the installation log or by running the debian installer
again to the point where it detects all the disks?


Regards,

Jeroen Dekkers





Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#501306; Package grub. (Thu, 09 Oct 2008 20:39:12 GMT) Full text and rfc822 format available.

Acknowledgement sent to Dan Poltawski <dan.poltawski@lancaster.ac.uk>:
Extra info received and forwarded to list. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Thu, 09 Oct 2008 20:39:12 GMT) Full text and rfc822 format available.

Message #45 received at 501306@bugs.debian.org (full text, mbox):

From: Dan Poltawski <dan.poltawski@lancaster.ac.uk>
To: Jeroen Dekkers <jeroen@dekkers.cx>
Cc: Dan Poltawski <dan.poltawski@lancaster.ac.uk>, Samat K Jain <samat@samat.org>, 501306@bugs.debian.org, Felix Zielcke <fzielcke@z-51.de>
Subject: Re: Bug#501306: update-grub fails with raid1 boot partition
Date: Thu, 9 Oct 2008 21:28:56 +0100
[Message part 1 (text/plain, inline)]
On Thu, Oct 09, 2008 at 09:27:51PM +0200, Jeroen Dekkers wrote:
> It might be possible that the names sda to sdd were used for something
> that wasn't an hard disk during the install (a card reader with 4
> different slots might be a good candidate). Then your system would
> still boot properly with your old device.map because grub detected
> that sde was the first hard disk, but then you wouldn't be able to
> run update-grub because your first hard disk is sda now. Could you
> check this in the installation log or by running the debian installer
> again to the point where it detects all the disks?

You are exactly right! The machine has a 4 slot card reader (as do my
collegues who experienced the exact same problem. Looking at the installer
log this is exactly what happened.

Attached is the relevant part of /var/log/installer/syslog

Dan
[syslog (text/plain, attachment)]
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#501306; Package grub. (Thu, 09 Oct 2008 20:42:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Dan Poltawski <dan.poltawski@lancaster.ac.uk>:
Extra info received and forwarded to list. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Thu, 09 Oct 2008 20:42:09 GMT) Full text and rfc822 format available.

Message #50 received at 501306@bugs.debian.org (full text, mbox):

From: Dan Poltawski <dan.poltawski@lancaster.ac.uk>
To: Dan Poltawski <dan.poltawski@lancaster.ac.uk>
Cc: Jeroen Dekkers <jeroen@dekkers.cx>, Samat K Jain <samat@samat.org>, 501306@bugs.debian.org, Felix Zielcke <fzielcke@z-51.de>
Subject: Re: Bug#501306: update-grub fails with raid1 boot partition
Date: Thu, 9 Oct 2008 21:39:35 +0100
[Message part 1 (text/plain, inline)]
On Thu, Oct 09, 2008 at 09:28:56PM +0100, Dan Poltawski wrote:
> On Thu, Oct 09, 2008 at 09:27:51PM +0200, Jeroen Dekkers wrote:
> > It might be possible that the names sda to sdd were used for something
> > that wasn't an hard disk during the install (a card reader with 4
> > different slots might be a good candidate). Then your system would
> > still boot properly with your old device.map because grub detected
> > that sde was the first hard disk, but then you wouldn't be able to
> > run update-grub because your first hard disk is sda now. Could you
> > check this in the installation log or by running the debian installer
> > again to the point where it detects all the disks?
> 
> You are exactly right! The machine has a 4 slot card reader (as do my
> collegues who experienced the exact same problem. Looking at the installer
> log this is exactly what happened.
> 
> Attached is the relevant part of /var/log/installer/syslog

And here is dmesg output of currently running system (they have indeed 
swapped since the installer):

[   13.029040] scsi 6:0:0:0: Direct-Access     TEAC     USB   HS-CF Card
4.08 PQ: 0 ANSI: 0
[   13.030753] scsi 6:0:0:1: Direct-Access     TEAC     USB   HS-xD/SM
4.08 PQ: 0 ANSI: 0
[   13.039924] scsi 6:0:0:2: Direct-Access     TEAC     USB   HS-MS Card
4.08 PQ: 0 ANSI: 0
[   13.042754] scsi 6:0:0:3: Direct-Access     TEAC     USB   HS-SD Card
4.08 PQ: 0 ANSI: 0
[   13.048067] sd 6:0:0:0: [sdc] Attached SCSI removable disk
[   13.048131] sd 6:0:0:0: Attached scsi generic sg3 type 0
[   13.053311] sd 6:0:0:1: [sdd] Attached SCSI removable disk
[   13.053373] sd 6:0:0:1: Attached scsi generic sg4 type 0
[   13.058303] sd 6:0:0:2: [sde] Attached SCSI removable disk
[   13.058365] sd 6:0:0:2: Attached scsi generic sg5 type 0
[   13.062752] sd 6:0:0:3: [sdf] Attached SCSI removable disk
[   13.062752] sd 6:0:0:3: Attached scsi generic sg6 type 0

Dan
[signature.asc (application/pgp-signature, inline)]

Changed Bug title to `update-grub fails silently with wrong device.map' from `update-grub fails with raid1 boot partition'. Request was from Felix Zielcke <fzielcke@z-51.de> to control@bugs.debian.org. (Sat, 11 Oct 2008 15:39:06 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#501306; Package grub. (Wed, 22 Oct 2008 09:15:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Martin Hansen <mah_list1@cfsi.dk>:
Extra info received and forwarded to list. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Wed, 22 Oct 2008 09:15:05 GMT) Full text and rfc822 format available.

Message #57 received at 501306@bugs.debian.org (full text, mbox):

From: Martin Hansen <mah_list1@cfsi.dk>
To: 501306@bugs.debian.org
Subject: confirmation
Date: Wed, 22 Oct 2008 11:12:09 +0200
I just want to confirm, that the problem is in difference in device mapping in 
the installer and in final system, i got the exact same error.
removing devicemap file, and thereby triggering update-grub to regenerate with 
call to grub, solved the problem.
making update-grub regenerate devicemap every time (including deleting the old 
one)  would have solved my problem, but might create other problems. 

But just an error message telling me that it was the convert functions call to 
grup-probe that failed, and I should take a look at the device map, would 
have saved me a lot of time.

I think the right solution is to have the installer trigger a regenerate on 
final system after first boot. or make the installer map devices the same way 
as final system (maybe more difficult)
-- 
Martin Hansen




Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#501306; Package grub. (Thu, 23 Oct 2008 15:48:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Felix Zielcke <fzielcke@z-51.de>:
Extra info received and forwarded to list. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Thu, 23 Oct 2008 15:48:02 GMT) Full text and rfc822 format available.

Message #62 received at 501306@bugs.debian.org (full text, mbox):

From: Felix Zielcke <fzielcke@z-51.de>
To: 501306@bugs.debian.org
Subject: update-grub fails silently with wrong device.map
Date: Thu, 23 Oct 2008 17:45:40 +0200
[Message part 1 (text/plain, inline)]
Attached is now an ugly patch which would display the grub-probe error
"Check your device.map" if it fails.

Else I had the idea to make an environment variable like
GRUB_PROBE_HIDE_ERRORS=1 which would hide the output of
grub_print_error() but then we would need to change grub-common and grub
package to fix this bug.

What do you think Robert?

-- 
Felix Zielcke
[update-grub-l.diff (text/x-patch, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#501306; Package grub. (Mon, 27 Oct 2008 19:21:04 GMT) Full text and rfc822 format available.

Message #65 received at 501306@bugs.debian.org (full text, mbox):

From: Robert Millan <rmh@aybabtu.com>
To: Felix Zielcke <fzielcke@z-51.de>, 501306@bugs.debian.org
Subject: Re: Bug#501306: update-grub fails silently with wrong device.map
Date: Mon, 27 Oct 2008 20:16:58 +0100
On Thu, Oct 23, 2008 at 05:45:40PM +0200, Felix Zielcke wrote:
> Attached is now an ugly patch which would display the grub-probe error
> "Check your device.map" if it fails.
> 
> Else I had the idea to make an environment variable like
> GRUB_PROBE_HIDE_ERRORS=1 which would hide the output of
> grub_print_error() but then we would need to change grub-common and grub
> package to fix this bug.
> 
> What do you think Robert?

Sounds like a good idea.  Except that the message in first hunk is not correct
(it should say Cannot find a device for $1 or something like that).

Thanks Felix for finding a way out of this!

> Index: update-grub
> ===================================================================
> --- update-grub	(revision 1080)
> +++ update-grub	(working copy)
> @@ -115,7 +115,8 @@ find_device ()
>  	if ! test -e ${device_map} ; then
>  		echo quit | grub --batch --no-floppy --device-map=${device_map} > /dev/null
>  	fi
> -	grub-probe --device-map=${device_map} -t device $1 2> /dev/null
> +	grub-probe --device-map=${device_map} -t device $1 2> /dev/null || \
> +	(echo "Cannot find a GRUB drive for $1.  Check your device.map." && exit 1)
>  }
>  
>  # Usage: convert_raid1 os_device
> @@ -152,7 +153,8 @@ convert () {
>  	if ! test -e ${device_map} ; then
>  		echo quit | grub --batch --no-floppy --device-map=${device_map} > /dev/null
>  	fi
> -	GRUB_LEGACY_0_BASED_PARTITIONS=1 grub-probe --device-map=${device_map} -t drive -d "$1" 2> /dev/null
> +	GRUB_LEGACY_0_BASED_PARTITIONS=1 grub-probe --device-map=${device_map} -t drive -d "$1" 2> /dev/null || \
> +        (echo "Cannot find a GRUB drive for $1.  Check your device.map." && exit 1)
>  }
>  
>  # Usage: convert_default os_device


-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."




Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#501306; Package grub. (Tue, 28 Oct 2008 09:39:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Tue, 28 Oct 2008 09:39:21 GMT) Full text and rfc822 format available.

Message #70 received at 501306@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Robert Millan <rmh@aybabtu.com>
Cc: Felix Zielcke <fzielcke@z-51.de>, 501306@bugs.debian.org
Subject: Re: Bug#501306: update-grub fails silently with wrong device.map
Date: Tue, 28 Oct 2008 10:27:29 +0100
On Mon, 27 Oct 2008, Robert Millan wrote:
> On Thu, Oct 23, 2008 at 05:45:40PM +0200, Felix Zielcke wrote:
> > Attached is now an ugly patch which would display the grub-probe error
> > "Check your device.map" if it fails.
> > 
> > Else I had the idea to make an environment variable like
> > GRUB_PROBE_HIDE_ERRORS=1 which would hide the output of
> > grub_print_error() but then we would need to change grub-common and grub
> > package to fix this bug.
> > 
> > What do you think Robert?
> 
> Sounds like a good idea.  Except that the message in first hunk is not correct
> (it should say Cannot find a device for $1 or something like that).

I have two concerns with this:
- grub-probe can possibly fail in other circumstances and we will display
  a misleading error message in those cases
- the installation will still fail and most users have no idea what
  device.map really is. If you go that route, you should at least give
  them the command-line to execute to regenerate the device.map

On the long term, the best would be to use UUID instead of partition names
to be able to reliably find the device name of the intended partition/and
hence drive. I think this is already done for grub2.

But in the mean time for Grub 1, wouldn't the best solution simply be
to regenerate the device.map in case of errors and try again ?

Someone with a customized but working device.map wouldn't get it rewritten
but someone with a bad file would get it fixed.

> > +	GRUB_LEGACY_0_BASED_PARTITIONS=1 grub-probe --device-map=${device_map} -t drive -d "$1" 2> /dev/null || \
> > +        (echo "Cannot find a GRUB drive for $1.  Check your device.map." && exit 1)

We would then have something like this:
GRUB_LEGACY_0_BASED_PARTITIONS=1 grub-probe --device-map=${device_map} -t drive -d "$1" 2> /dev/null || \
 (grub-mkdevicemap --device-map=${device_map} --no-floppy >/dev/null 2>&1 || true; \
  GRUB_LEGACY_0_BASED_PARTITIONS=1 grub-probe --device-map=${device_map}  -t drive -d "$1")

If it fails, we regenerate the device.map and try again but this time we
won't hide any error so that if it fails again the user has a chance to
debug it but with the real error message instead.

Does that sound reasonable ?

I'll try that and post a patch if my test shows that it works.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#501306; Package grub. (Tue, 28 Oct 2008 11:18:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Tue, 28 Oct 2008 11:18:02 GMT) Full text and rfc822 format available.

Message #75 received at 501306@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: 501306@bugs.debian.org
Cc: Robert Millan <rmh@aybabtu.com>
Subject: grub: diff for NMU version 0.97-47.1
Date: Tue, 28 Oct 2008 12:14:59 +0100
[Message part 1 (text/plain, inline)]
tags 501306 + patch
thanks

Hello,

here's the patch that I announced sooner. I tested here by changing
device.map to not reference my /boot and / partitions. Running
udpdate-grub still works but it displays one line more saying that
device.map got regenerated.

I don't think that find_device() needs any change.

If you want me to upload this as NMU, please say so, otherwise I'll let
you handle it.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
[grub-0.97-47.1-nmu.diff (text/x-diff, attachment)]

Tags added: patch Request was from Raphael Hertzog <hertzog@debian.org> to control@bugs.debian.org. (Tue, 28 Oct 2008 11:18:04 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#501306; Package grub. (Tue, 28 Oct 2008 13:48:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Martin Hansen <mah@cfsi.dk>:
Extra info received and forwarded to list. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Tue, 28 Oct 2008 13:48:06 GMT) Full text and rfc822 format available.

Message #82 received at 501306@bugs.debian.org (full text, mbox):

From: Martin Hansen <mah@cfsi.dk>
To: 501306@bugs.debian.org
Subject: Re: Bug#501306: update-grub fails silently with wrong device.map
Date: Tue, 28 Oct 2008 14:44:44 +0100
Tirsdag den 28. Oktober 2008 skrev Raphael Hertzog:
> - the installation will still fail and most users have no idea what
>   device.map really is. If you go that route, you should at least give
>   them the command-line to execute to regenerate the device.map

> But in the mean time for Grub 1, wouldn't the best solution simply be
> to regenerate the device.map in case of errors and try again ?
the command-line is already in the script, so a switch and/or env. variable, 
telling grub to overwrite device.map, combined with an error mesage like this 
on grub-probe fail:

"something went wrong with grub-probe. maybe a problem of your device.map file
If You dont' know what device.map is, try regenerate this by running 
grub-update as:
grub-update --replace-devicemap"

path in the region of
-       if ! test -e ${device_map}  ; then
+       if ! test -e ${device_map} -o {switch/env. check} ; then
               echo quit | grub --batch --no-floppy\
             --device-map=${device_map}  /dev/null
       fi

-- 
 Med venlig hilsen / Mojn / Best regards

 Martin Hansen
 Opensource Software Specialist

 Center for Software Innovation
 Alsion 2
 DK-6400 Snderborg
 Tel.:+4573477000
 Dir.:+4573477017
 Mail:mah@cfsi.dk
 Web :www.cfsi.dk

Kommende CSI arrangementer:[http://www.cfsi.dk/Default.aspx?ID=27]

Kursus: Basiskursus Embedded Linux
IT i jordh&#248;jde
AFLYSNING: FPGA-days
Morgenmadsm&#248;de: Innovation og kreativitet, hvordan h&#230;nger det sammen 
i en mekatronik virksomhed?
Teknologikaravanen






Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#501306; Package grub. (Tue, 28 Oct 2008 19:21:02 GMT) Full text and rfc822 format available.

Message #85 received at 501306@bugs.debian.org (full text, mbox):

From: Robert Millan <rmh@aybabtu.com>
To: Raphael Hertzog <hertzog@debian.org>
Cc: Felix Zielcke <fzielcke@z-51.de>, 501306@bugs.debian.org
Subject: Re: Bug#501306: update-grub fails silently with wrong device.map
Date: Tue, 28 Oct 2008 20:17:45 +0100
On Tue, Oct 28, 2008 at 10:27:29AM +0100, Raphael Hertzog wrote:
> 
> I have two concerns with this:
> - grub-probe can possibly fail in other circumstances and we will display
>   a misleading error message in those cases

grub-probe's messages aren't always appropiate for grub legacy's update-grub
(see #495909).  Besides, when "-t drive" fails it always means that device.map
is wrong.

> - the installation will still fail and most users have no idea what
>   device.map really is. If you go that route, you should at least give
>   them the command-line to execute to regenerate the device.map

Seems fine.

> But in the mean time for Grub 1, wouldn't the best solution simply be
> to regenerate the device.map in case of errors and try again ?

We tried this, and the solution was worse than the problem.  In the end it
had to be reverted.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."




Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#501306; Package grub. (Tue, 28 Oct 2008 19:21:03 GMT) Full text and rfc822 format available.

Message #88 received at 501306@bugs.debian.org (full text, mbox):

From: Robert Millan <rmh@aybabtu.com>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 501306@bugs.debian.org
Subject: Re: grub: diff for NMU version 0.97-47.1
Date: Tue, 28 Oct 2008 20:18:37 +0100
tags 501306 - patch
thanks

On Tue, Oct 28, 2008 at 12:14:59PM +0100, Raphael Hertzog wrote:
> tags 501306 + patch
> thanks
> 
> Hello,
> 
> here's the patch that I announced sooner. I tested here by changing
> device.map to not reference my /boot and / partitions. Running
> udpdate-grub still works but it displays one line more saying that
> device.map got regenerated.
> 
> I don't think that find_device() needs any change.
> 
> If you want me to upload this as NMU, please say so, otherwise I'll let
> you handle it.

Hi,

This is not ok, see my last reply.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."




Tags removed: patch Request was from Robert Millan <rmh@aybabtu.com> to control@bugs.debian.org. (Tue, 28 Oct 2008 19:21:04 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#501306; Package grub. (Tue, 28 Oct 2008 20:18:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Tue, 28 Oct 2008 20:18:03 GMT) Full text and rfc822 format available.

Message #95 received at 501306@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Robert Millan <rmh@aybabtu.com>
Cc: Felix Zielcke <fzielcke@z-51.de>, 501306@bugs.debian.org
Subject: Re: Bug#501306: update-grub fails silently with wrong device.map
Date: Tue, 28 Oct 2008 21:13:30 +0100
On Tue, 28 Oct 2008, Robert Millan wrote:
> On Tue, Oct 28, 2008 at 10:27:29AM +0100, Raphael Hertzog wrote:
> > 
> > I have two concerns with this:
> > - grub-probe can possibly fail in other circumstances and we will display
> >   a misleading error message in those cases
> 
> grub-probe's messages aren't always appropiate for grub legacy's update-grub
> (see #495909).  Besides, when "-t drive" fails it always means that device.map
> is wrong.
>
> > But in the mean time for Grub 1, wouldn't the best solution simply be
> > to regenerate the device.map in case of errors and try again ?
> 
> We tried this, and the solution was worse than the problem.  In the end it
> had to be reverted.

Sorry but I don't understand how you concile the two sentences that you
gave:
- on one side you say that "-t drive" only fails when device.map is wrong
  and you accept that we invite the user to regenerate it
- on the other side you tell me that trying to regenerate it only when "-t
  drive" fails has been tried and was worse than the problem

What do I miss ?

I could understand that always regenerating device.map would be worse and
wrong (and it's possibly this that got tried). But I only suggested to
regenerate it when we have serious suspicion that device.map is wrong
and _not_ always.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#501306; Package grub. (Tue, 28 Oct 2008 21:18:08 GMT) Full text and rfc822 format available.

Message #98 received at 501306@bugs.debian.org (full text, mbox):

From: Robert Millan <rmh@aybabtu.com>
To: Raphael Hertzog <hertzog@debian.org>
Cc: Felix Zielcke <fzielcke@z-51.de>, 501306@bugs.debian.org
Subject: Re: Bug#501306: update-grub fails silently with wrong device.map
Date: Tue, 28 Oct 2008 22:13:38 +0100
On Tue, Oct 28, 2008 at 09:13:30PM +0100, Raphael Hertzog wrote:
> On Tue, 28 Oct 2008, Robert Millan wrote:
> > On Tue, Oct 28, 2008 at 10:27:29AM +0100, Raphael Hertzog wrote:
> > > 
> > > I have two concerns with this:
> > > - grub-probe can possibly fail in other circumstances and we will display
> > >   a misleading error message in those cases
> > 
> > grub-probe's messages aren't always appropiate for grub legacy's update-grub
> > (see #495909).  Besides, when "-t drive" fails it always means that device.map
> > is wrong.
> >
> > > But in the mean time for Grub 1, wouldn't the best solution simply be
> > > to regenerate the device.map in case of errors and try again ?
> > 
> > We tried this, and the solution was worse than the problem.  In the end it
> > had to be reverted.
> 
> Sorry but I don't understand how you concile the two sentences that you
> gave:
> - on one side you say that "-t drive" only fails when device.map is wrong
>   and you accept that we invite the user to regenerate it

s/regenerate/check/g.  When device.map is wrong, it doesn't necessarily mean
we have to regenerate it.  This could be our own fault, e.g. if
grub-mkdevicemap doesn't recognise a new device type.

> - on the other side you tell me that trying to regenerate it only when "-t
>   drive" fails has been tried and was worse than the problem
> 
> What do I miss ?

The behaviour is inconsistent with what users tend to reasonably expect, and
very confusing to those who aren't aware of it.  See for example #479056.
Also, it makes debugging a PITA.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."




Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#501306; Package grub. (Wed, 29 Oct 2008 08:27:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Wed, 29 Oct 2008 08:27:02 GMT) Full text and rfc822 format available.

Message #103 received at 501306@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Robert Millan <rmh@aybabtu.com>
Cc: Felix Zielcke <fzielcke@z-51.de>, 501306@bugs.debian.org
Subject: Re: Bug#501306: update-grub fails silently with wrong device.map
Date: Wed, 29 Oct 2008 09:22:18 +0100
[Message part 1 (text/plain, inline)]
On Tue, 28 Oct 2008, Robert Millan wrote:
> > Sorry but I don't understand how you concile the two sentences that you
> > gave:
> > - on one side you say that "-t drive" only fails when device.map is wrong
> >   and you accept that we invite the user to regenerate it
> 
> s/regenerate/check/g.  When device.map is wrong, it doesn't necessarily mean
> we have to regenerate it.  This could be our own fault, e.g. if
> grub-mkdevicemap doesn't recognise a new device type.

What do you expect the user to do when he "checks" the device.map ?

He will likely try to re-generate it or hand-edit it if he knows what this
is all about. But most users will be left in the cold… I believe that an
advanced user will sort it out even if the file has been regenerated, in
particular if he has been informed of it. We could also keep a copy of
the file if we regenerate it to ease debugging.

> > - on the other side you tell me that trying to regenerate it only when "-t
> >   drive" fails has been tried and was worse than the problem
> > 
> > What do I miss ?
> 
> The behaviour is inconsistent with what users tend to reasonably expect, and
> very confusing to those who aren't aware of it.

That's why I added an echo statement that explicitely informs the user
that the file got regenerated.

> See for example #479056. Also, it makes debugging a PITA.

From what I see, the device.map regeneration was included in grub-probe
itself and the user was only informed through a "info:" that is only
displayed in verbose mode.

Of course this made debugging difficult.


Ok, if you really don't want to replace the device.map on the fly,
let me propose yet another solution: in case of grub-probe failure, we
regenerate a device.map in a temporary file and we try grub-probe again
but with --device-map pointing to this temporary file. That way the
default device.map doesn't get modified and we still have a chance to make
it work by default. We would display a message saying that the device.map
has to be verified if we succeed through the fallback solution.

Please find the corresponding patch attached.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
[patch (text/plain, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#501306; Package grub. (Wed, 29 Oct 2008 13:33:04 GMT) Full text and rfc822 format available.

Message #106 received at 501306@bugs.debian.org (full text, mbox):

From: Robert Millan <rmh@aybabtu.com>
To: Raphael Hertzog <hertzog@debian.org>
Cc: Felix Zielcke <fzielcke@z-51.de>, 501306@bugs.debian.org
Subject: Re: Bug#501306: update-grub fails silently with wrong device.map
Date: Wed, 29 Oct 2008 14:30:40 +0100
On Wed, Oct 29, 2008 at 09:22:18AM +0100, Raphael Hertzog wrote:
> 
> Ok, if you really don't want to replace the device.map on the fly,
> let me propose yet another solution: in case of grub-probe failure, we
> regenerate a device.map in a temporary file and we try grub-probe again
> but with --device-map pointing to this temporary file. That way the
> default device.map doesn't get modified and we still have a chance to make
> it work by default. We would display a message saying that the device.map
> has to be verified if we succeed through the fallback solution.
> 
> Please find the corresponding patch attached.

I don't like that it is an ugly hack, in the sense that we're trying to stop
reliing on this sort of heuristic, and this only works around the problem.
Our long-term fix is to use only reliable identifiers like UUIDs.

But since all of this is temporary, I suppose we could live with it.  Felix,
what do you think?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."




Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#501306; Package grub. (Wed, 29 Oct 2008 14:00:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Felix Zielcke <fzielcke@z-51.de>:
Extra info received and forwarded to list. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Wed, 29 Oct 2008 14:00:03 GMT) Full text and rfc822 format available.

Message #111 received at 501306@bugs.debian.org (full text, mbox):

From: Felix Zielcke <fzielcke@z-51.de>
To: Robert Millan <rmh@aybabtu.com>
Cc: Raphael Hertzog <hertzog@debian.org>, 501306@bugs.debian.org
Subject: Re: Bug#501306: update-grub fails silently with wrong device.map
Date: Wed, 29 Oct 2008 14:56:52 +0100
Am Mittwoch, den 29.10.2008, 14:30 +0100 schrieb Robert Millan:

> I don't like that it is an ugly hack, in the sense that we're trying to stop
> reliing on this sort of heuristic, and this only works around the problem.
> Our long-term fix is to use only reliable identifiers like UUIDs.
> 
> But since all of this is temporary, I suppose we could live with it.  Felix,
> what do you think?

I aggree. 

-- 
Felix Zielcke





Tags added: pending Request was from Robert Millan <rmh@aybabtu.com> to control@bugs.debian.org. (Wed, 29 Oct 2008 14:21:02 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#501306; Package grub. (Wed, 29 Oct 2008 16:00:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Wed, 29 Oct 2008 16:00:09 GMT) Full text and rfc822 format available.

Message #118 received at 501306@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Felix Zielcke <fzielcke@z-51.de>
Cc: Robert Millan <rmh@aybabtu.com>, 501306@bugs.debian.org
Subject: Re: Bug#501306: update-grub fails silently with wrong device.map
Date: Wed, 29 Oct 2008 16:56:54 +0100
On Wed, 29 Oct 2008, Felix Zielcke wrote:
> Am Mittwoch, den 29.10.2008, 14:30 +0100 schrieb Robert Millan:
> 
> > I don't like that it is an ugly hack, in the sense that we're trying to stop
> > reliing on this sort of heuristic, and this only works around the problem.
> > Our long-term fix is to use only reliable identifiers like UUIDs.
> > 
> > But since all of this is temporary, I suppose we could live with it.  Felix,
> > what do you think?
> 
> I agree. 

Indeed, it's too late for any major change in lenny at this point and this
is a good compromise IMO.

Robert, I saw that you comitted the fix in SVN with a version 0.97-52 but
unstable/lenny has 0.97-47, and the changes in between are probably
unwanted by release managers. Will you prepare a 0.97-47lenny1 version
for unstable ?

I wanted to ask you to upload shortly to get the RC bug count down but I
noticed that grub also suffers from #500336. We need to get the ball
rolling there too. There's a patch but Ian wanted something even better.
I'll follow-up there.

Regards,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/




Forcibly Merged 498353 501306. Request was from Raphael Hertzog <hertzog@debian.org> to control@bugs.debian.org. (Wed, 29 Oct 2008 16:09:10 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#501306; Package grub. (Wed, 29 Oct 2008 17:15:02 GMT) Full text and rfc822 format available.

Message #123 received at 501306@bugs.debian.org (full text, mbox):

From: Robert Millan <rmh@aybabtu.com>
To: Raphael Hertzog <hertzog@debian.org>
Cc: Felix Zielcke <fzielcke@z-51.de>, 501306@bugs.debian.org
Subject: Re: Bug#501306: update-grub fails silently with wrong device.map
Date: Wed, 29 Oct 2008 18:13:24 +0100
On Wed, Oct 29, 2008 at 04:56:54PM +0100, Raphael Hertzog wrote:
> 
> Robert, I saw that you comitted the fix in SVN with a version 0.97-52 but
> unstable/lenny has 0.97-47, and the changes in between are probably
> unwanted by release managers. Will you prepare a 0.97-47lenny1 version
> for unstable ?

I already did (see branches/lenny), but I notice the version should be
0.97-47lenny1, thanks for spotting that.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."




Reply sent to Robert Millan <rmh@aybabtu.com>:
You have taken responsibility. (Fri, 07 Nov 2008 19:00:05 GMT) Full text and rfc822 format available.

Notification sent to Dan Poltawski <dan.poltawski@lancaster.ac.uk>:
Bug acknowledged by developer. (Fri, 07 Nov 2008 19:00:05 GMT) Full text and rfc822 format available.

Message #128 received at 501306-close@bugs.debian.org (full text, mbox):

From: Robert Millan <rmh@aybabtu.com>
To: 501306-close@bugs.debian.org
Subject: Bug#501306: fixed in grub 0.97-47lenny1
Date: Fri, 07 Nov 2008 18:47:04 +0000
Source: grub
Source-Version: 0.97-47lenny1

We believe that the bug you reported is fixed in the latest version of
grub, which is due to be installed in the Debian FTP archive:

grub-disk_0.97-47lenny1_all.deb
  to pool/main/g/grub/grub-disk_0.97-47lenny1_all.deb
grub-doc_0.97-47lenny1_all.deb
  to pool/main/g/grub/grub-doc_0.97-47lenny1_all.deb
grub-legacy-doc_0.97-47lenny1_all.deb
  to pool/main/g/grub/grub-legacy-doc_0.97-47lenny1_all.deb
grub_0.97-47lenny1.diff.gz
  to pool/main/g/grub/grub_0.97-47lenny1.diff.gz
grub_0.97-47lenny1.dsc
  to pool/main/g/grub/grub_0.97-47lenny1.dsc
grub_0.97-47lenny1_amd64.deb
  to pool/main/g/grub/grub_0.97-47lenny1_amd64.deb
multiboot-doc_0.97-47lenny1_all.deb
  to pool/main/g/grub/multiboot-doc_0.97-47lenny1_all.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 501306@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Robert Millan <rmh@aybabtu.com> (supplier of updated grub package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Fri,  7 Nov 2008 19:28:46 +0100
Source: grub
Binary: grub grub-disk grub-doc grub-legacy-doc multiboot-doc
Architecture: source amd64 all
Version: 0.97-47lenny1
Distribution: unstable
Urgency: high
Maintainer: Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>
Changed-By: Robert Millan <rmh@aybabtu.com>
Description: 
 grub       - GRand Unified Bootloader (Legacy version)
 grub-disk  - GRUB bootable disk image (dummy package)
 grub-doc   - Documentation for GRand Unified Bootloader (dummy package)
 grub-legacy-doc - Documentation for GRUB Legacy
 multiboot-doc - The Multiboot specification
Closes: 500336 501306
Changes: 
 grub (0.97-47lenny1) unstable; urgency=high
 .
   * update-grub: Try to regenerate device.map when grub-probe fails (and
     inform the user about it).  Thanks Raphaël Hertzog.  (Closes: #501306)
   * update-grub: Do not attempt to detect CONFIG_PARAVIRT Xen images.
     Thanks Raphaël Hertzog et al.  (Closes: #500336)
Checksums-Sha1: 
 94e7b82c7300e9c76c9fc9428b6728b5441ff517 1335 grub_0.97-47lenny1.dsc
 7d19066491f09c483efa06b07e55a57b06fecfa6 93826 grub_0.97-47lenny1.diff.gz
 88c2cd84ce3b90f8dd1f1ba75a5553cb89510822 924212 grub_0.97-47lenny1_amd64.deb
 59e17ee8b2aeb29f3449b4a56d36eb93b78dfcd6 115486 grub-disk_0.97-47lenny1_all.deb
 dfd030c7284dc2fa718cccd37f9974c6bb8fb740 115502 grub-doc_0.97-47lenny1_all.deb
 15928d7c9ad175f1df90aa575540ae233ef0cf0c 252818 grub-legacy-doc_0.97-47lenny1_all.deb
 88e5d234d245da663cd428ee85cd1478cf20fd29 160550 multiboot-doc_0.97-47lenny1_all.deb
Checksums-Sha256: 
 8e7a302f32c971e188f8df43b685535394ba9eefbd7a6f6eecdfd274ebe0cb9e 1335 grub_0.97-47lenny1.dsc
 af3e003f74ddaed35cbddb70100a1d06ce120340e3ae7316e4e6f20645a08986 93826 grub_0.97-47lenny1.diff.gz
 9cf8199a472b49918221b95990027ec982c33372e2af9971728b3cf1202863f5 924212 grub_0.97-47lenny1_amd64.deb
 063d7606bd0fb985d7bf540ff7430b0ebed9894e311a64913c3f54b7e4ef607c 115486 grub-disk_0.97-47lenny1_all.deb
 98d18cee7efbd5f80f968d04914c904d7c5237ae4a897710996299d7dfaacbac 115502 grub-doc_0.97-47lenny1_all.deb
 1d38ae800107084e25f49dca090db7761712820ddefe1ed14038854bcd5bd0c1 252818 grub-legacy-doc_0.97-47lenny1_all.deb
 b640f7d0bc683079391341eb336d6198219bfc90e369a5ded18e6423fc29e185 160550 multiboot-doc_0.97-47lenny1_all.deb
Files: 
 d57735b6b6742ca407837a4fe5ae57d6 1335 admin optional grub_0.97-47lenny1.dsc
 bac404d0a92757509be9c19085d930a3 93826 admin optional grub_0.97-47lenny1.diff.gz
 4236503893c79c62b09e1f74a89d0116 924212 admin optional grub_0.97-47lenny1_amd64.deb
 44642ddb7cdc680838fd29ad5ffad776 115486 admin optional grub-disk_0.97-47lenny1_all.deb
 7a45eba493eef628cea53df46a3f4136 115502 doc optional grub-doc_0.97-47lenny1_all.deb
 5af0191118eb1c7332933dd25b0132da 252818 doc optional grub-legacy-doc_0.97-47lenny1_all.deb
 0515bea9b1718c8644bb908a262081c8 160550 doc optional multiboot-doc_0.97-47lenny1_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkkUivMACgkQC19io6rUCv/uDQCbBiFoNoelJ8SlJla++gn3xb5/
gyoAnRK5rEekMMOMEOnhgPE9/A5hr9oN
=b32m
-----END PGP SIGNATURE-----





Reply sent to Robert Millan <rmh@aybabtu.com>:
You have taken responsibility. (Fri, 07 Nov 2008 19:00:06 GMT) Full text and rfc822 format available.

Notification sent to Michal Čihař <nijel@debian.org>:
Bug acknowledged by developer. (Fri, 07 Nov 2008 19:00:06 GMT) Full text and rfc822 format available.

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Thu, 22 Jan 2009 07:25:48 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Apr 17 19:21:10 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.