Bug#501306: update-grub fails with raid1 boot partition

[Dan Poltawski]

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
Description: Digital signature

Bug#501306: update-grub fails with raid1 boot partition

[Dan Poltawski]

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
Oct  3 16:43:24 kernel: sd 6:0:0:0: [sda] Attached SCSI removable disk
Oct  3 16:43:24 kernel: sd 6:0:0:1: [sdb] Attached SCSI removable disk
Oct  3 16:43:24 kernel: sd 6:0:0:2: [sdc] Attached SCSI removable disk
Oct  3 16:43:24 kernel: sd 6:0:0:3: [sdd] Attached SCSI removable disk
Oct  3 16:43:24 kernel: ata3.00: configured for UDMA/100
Oct  3 16:43:24 kernel: ata4: SATA link down (SStatus 4 SControl 300)
Oct  3 16:43:24 kernel: ata5: SATA link down (SStatus 0 SControl 0)
Oct  3 16:43:24 kernel: ata6: SATA link down (SStatus 4 SControl 300)
Oct  3 16:43:24 kernel: scsi 0:0:0:0: Direct-Access ATA  ST3250310AS
  4.AD PQ: 0 ANSI: 5
Oct  3 16:43:24 kernel: sd 0:0:0:0: [sde] 488281250 512-byte hardware sectors 
(25 MB)
Oct  3 16:43:24 kernel: sd 0:0:0:0: [sde] Write Protect is off
Oct  3 16:43:24 kernel: sd 0:0:0:0: [sde] Mode Sense: 00 3a 00 00
Oct  3 16:43:24 kernel: sd 0:0:0:0: [sde] Write cache: enabled, read cache: 
enabled, doesn't support DPO or FUA
Oct  3 16:43:24 kernel: sd 0:0:0:0: [sde] 488281250 512-byte hardware sectors 
(25 MB)
Oct  3 16:43:24 kernel: sd 0:0:0:0: [sde] Write Protect is off
Oct  3 16:43:24 kernel: sd 0:0:0:0: [sde] Mode Sense: 00 3a 00 00
Oct  3 16:43:24 kernel: sd 0:0:0:0: [sde] Write cache: enabled, read cache: 
enabled, doesn't support DPO or FUA
Oct  3 16:43:24 kernel:  sde: sde1 sde2 sde3
Oct  3 16:43:24 kernel: sd 0:0:0:0: [sde] Attached SCSI disk
Oct  3 16:43:24 kernel: scsi 1:0:0:0: Direct-Access ATA  ST3250310AS
  4.AD PQ: 0 ANSI: 5
Oct  3 16:43:24 kernel: sd 1:0:0:0: [sdf] 488281250 512-byte hardware sectors 
(25 MB)
Oct  3 16:43:24 kernel: sd 1:0:0:0: [sdf] Write Protect is off
Oct  3 16:43:24 kernel: sd 1:0:0:0: [sdf] Mode Sense: 00 3a 00 00
Oct  3 16:43:24 kernel: sd 1:0:0:0: [sdf] Write cache: enabled, read cache: 
enabled, doesn't support DPO or FUA
Oct  3 16:43:24 kernel: sd 1:0:0:0: [sdf] 488281250 512-byte hardware sectors 
(25 MB)
Oct  3 16:43:24 kernel: sd 1:0:0:0: [sdf] Write Protect is off
Oct  3 16:43:24 kernel: sd 1:0:0:0: [sdf] Mode Sense: 00 3a 00 00
Oct  3 16:43:24 kernel: sd 1:0:0:0: [sdf] Write cache: enabled, read cache: 
enabled, doesn't support DPO or FUA
Oct  3 16:43:24 kernel:  sdf: sdf1
Oct  3 16:43:24 kernel: sd 1:0:0:0: [sdf] Attached SCSI disk


signature.asc
Description: Digital signature

Bug#501306: update-grub fails with raid1 boot partition

[Jeroen Dekkers]

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




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#501306: update-grub fails with raid1 boot partition

[Dan Poltawski]

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
Description: Digital signature

Bug#501306: update-grub fails with raid1 boot partition

[Samat K Jain]

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  | 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
Description: This is a digitally signed message part.

Bug#501306: update-grub fails with raid1 boot partition

[Dan Poltawski]

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:

[EMAIL PROTECTED]:~$ 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
Description: Digital signature

Bug#501306: update-grub fails with raid1 boot partition

[Felix Zielcke]

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?




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#501306: update-grub fails with raid1 boot partition

[Felix Zielcke]

Hello,

Am Montag, den 06.10.2008, 13:44 +0100 schrieb Dan Poltawski:
> [EMAIL PROTECTED]:~# /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.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#501306: update-grub fails with raid1 boot partition

[Dan Poltawski]

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:

[EMAIL PROTECTED]:~# update-grub 
Searching for GRUB installation directory ... found: /boot/grub
[EMAIL PROTECTED]:~# 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:

[EMAIL PROTECTED]:~# /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 Optio