Bug#694974: grub-common: grub2 fails to boot from hdd with 'pv5: no such device', grub-probe reports 'no such disk'
Mike Edwards
pf-debian-bugs at mirkwood.net
Sun Dec 2 20:16:17 UTC 2012
Package: grub-common
Version: 1.98+20100804-14+squeeze1
Severity: important
grub2 fails to boot from hdd, throwing error 'pv5: no such device'. This has
forced me to boot from an external flash drive, as grub is completely unusable
as installed.
Some further information on this problem:
System uses mdraid + lvm. When this problem first appeared, I created a
separate boot lv, and moved it to a different pv from / (previously, /boot
was a part of /). The same error persists, which leads me to believe grub's
problem is with the pv that / resides on.
There are three md mirrors on this system:
md0: version 0.90
md1: version 1.2
md2: version 1.2
/ lives on md2:
# lvs -o+devices balrog/root-squeeze
LV VG Attr LSize Origin Snap% Move Log Copy% Convert Devices
root-squeeze balrog -wi-ao 10.00g /dev/md2(144)
grub-probe can locate md0 and md1, but NOT md2:
# grub-probe -vv -t abstraction -d /dev/md0 2>&1 | grep md0
disk/raid.c:629: Found array md0 (mdraid)
kern/disk.c:245: Opening `md0'...
disk/raid.c:134: md0: total_devs=2, disk_size=488391808
disk/raid.c:163: md0: level=1, total_sectors=488391808
kern/disk.c:245: Opening `md0'...
disk/raid.c:134: md0: total_devs=2, disk_size=488391808
disk/raid.c:163: md0: level=1, total_sectors=488391808
kern/disk.c:334: Closing `md0'.
kern/disk.c:245: Opening `md0'...
disk/raid.c:134: md0: total_devs=2, disk_size=488391808
disk/raid.c:163: md0: level=1, total_sectors=488391808
kern/disk.c:334: Closing `md0'.
grub-probe: info: opening md0.
kern/disk.c:245: Opening `md0'...
disk/raid.c:134: md0: total_devs=2, disk_size=488391808
disk/raid.c:163: md0: level=1, total_sectors=488391808
kern/disk.c:334: Closing `md0'.
# grub-probe -vv -t abstraction -d /dev/md1 2>&1 | grep md/1
disk/raid.c:629: Found array md/1 (mdraid)
kern/disk.c:245: Opening `md/1'...
disk/raid.c:134: md/1: total_devs=2, disk_size=1953517682
disk/raid.c:163: md/1: level=1, total_sectors=1953517682
kern/disk.c:245: Opening `md/1'...
disk/raid.c:134: md/1: total_devs=2, disk_size=1953517682
disk/raid.c:163: md/1: level=1, total_sectors=1953517682
kern/disk.c:334: Closing `md/1'.
kern/disk.c:245: Opening `md/1'...
disk/raid.c:134: md/1: total_devs=2, disk_size=1953517682
disk/raid.c:163: md/1: level=1, total_sectors=1953517682
kern/disk.c:334: Closing `md/1'.
grub-probe: info: opening md/1.
kern/disk.c:245: Opening `md/1'...
disk/raid.c:134: md/1: total_devs=2, disk_size=1953517682
disk/raid.c:163: md/1: level=1, total_sectors=1953517682
kern/disk.c:334: Closing `md/1'.
# grub-probe -vv -t abstraction -d /dev/md2 2>&1 | grep md/2
grub-probe: info: opening md/2.
kern/disk.c:245: Opening `md/2'...
kern/disk.c:320: Opening `md/2' failed.
kern/disk.c:334: Closing `md/2'.
Using gdb to examine what grub-probe is doing:
# gdb --args grub-probe -vv -t abstraction -d /dev/md2
(gdb) break grub_raid_open if name = "md/2"
Breakpoint 1 at 0x4255f0: file ../../disk/raid.c, line 114.
(gdb) run
...
gdb shows something interesting here:
/usr/sbin/grub-probe: info: opening md/2.
kern/disk.c:245: Opening `md/2'...
Breakpoint 1, grub_raid_open (name=0x6d3d60 "md/2", disk=0x66aa90)
at ../../disk/raid.c:114
114 {
(gdb) n
118 for (array = array_list; array != NULL; array = array->next)
(gdb)
120 if (!grub_strcmp (array->name, name))
(gdb) print array->name
$2 = 0x66a370 "md/1"
(gdb) print array[0]
$3 = {number = 1073741824, level = 1, layout = 0, total_devs = 2,
chunk_size = 64, disk_size = 1953517682, index = 1, uuid_len = 16,
uuid = 0x66a530 "G\256\215\372Y\377Ͱ\274\062K\302\374\263\ap",
name = 0x66a370 "md/1", nr_devs = 2, allocated_devs = 32,
members = 0x66a160, next = 0x669820}
(gdb) print array[1]
$4 = {number = 1953517682, level = 0, layout = 529, total_devs = 0,
chunk_size = 6726784, disk_size = 2048, index = 6725200, uuid_len = 0,
uuid = 0x800 <Address 0x800 out of bounds>, name = 0x0, nr_devs = 0,
allocated_devs = 0, members = 0x0, next = 0x0}
It appears that grub is incorrectly getting 'md/1' for device md/2, which
further appears to cause grub-probe to fail. This may also be related to
grub's inability to find the device at boot time.
-- System Information:
Debian Release: 6.0.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-0.bpo.3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages grub-common depends on:
ii base-files 6.0squeeze2 Debian base system miscellaneous f
ii dpkg 1.15.8.11 Debian package management system
ii gettext-base 0.18.1.1-3 GNU Internationalization utilities
ii install-info 4.13a.dfsg.1-6 Manage installed documentation in
ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib
ii libdevmapper1.02.1 2:1.02.48-5 The Linux Kernel Device Mapper use
ii libfreetype6 2.4.2-2.1 FreeType 2 font engine, shared lib
ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime
Versions of packages grub-common recommends:
ii os-prober 1.42 utility to detect other OSes on a
Versions of packages grub-common suggests:
ii grub-emu 1.98+20100804-14+squeeze1 GRand Unified Bootloader, version
pn multiboot-doc <none> (no description available)
ii xorriso 0.5.6.pl00-2 command line iso9660+RR manipulati
-- Configuration Files:
/etc/grub.d/20_linux_xen [Errno 2] No such file or directory: u'/etc/grub.d/20_linux_xen'
/etc/grub.d/40_custom changed:
exec tail -n +3 $0
menuentry 'balrog lenny/sid, Linux 2.6.32-5-xen-amd64 / XEN 3.4-amd64' --
class debian --class gnu-linux --class gnu --class os --class xen {
insmod part_msdos
insmod ext2
set root='(hd6,msdos1)'
search --no-floppy --fs-uuid --set 48e8de01-8640-4e44-8ea7-7e75d833b89a
echo 'Loading Linux 2.6.32-5-xen-amd64 ...'
multiboot /xen-4.0-amd64.gz placeholder
module /vmlinuz-2.6.32-5-xen-amd64 placeholder root=/dev/mapper/balrog-root ro quiet
echo 'Loading initial ramdisk ...'
module /initrd.img-2.6.32-5-xen-amd64
}
menuentry "Debian GNU/Linux (6.0.1) (on /dev/mapper/balrog-root)" {
insmod part_msdos
insmod ext2
set root='(hd6,msdos1)'
search --no-floppy --fs-uuid --set 48e8de01-8640-4e44-8ea7-7e75d833b89a
linux /vmlinuz-2.6.32-5-amd64 root=/dev/mapper/balrog-root ro
initrd /initrd.img-2.6.32-5-amd64
}
-- no debconf information
More information about the Pkg-grub-devel
mailing list