Bug#526615: fails to install to RAID across virtual (kvm/virtio) disks
also sprach Felix Zielcke fziel...@z-51.de [2009.07.24.1410 +0200]: We currently use in grub-setup ioctl (GET_ARRAY_INFO) and ioctl (GET_DISK_INFO) and unfortunately they return the major and minor of the device and not the name of the device file. But you have to somehow map that to the device file later, right? mdadm-lab:~# ls -la /dev/vda brw-rw 1 root disk 254, 0 2009-08-04 13:53 /dev/vda /dev/vda is a regular device like any other, except that it uses the 'experimental' major number 254. I don't understand why that should be treated any differently than e.g. a SCSI disk with major number 8. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems ... the ravenous bugblatter beast of traal (a mind-bogglingly stupid animal, it assumes that if you can't see it, it can't see you -- daft as a bush, but very very ravenous); -- douglas adams, the hitchhiker's guide to the galaxy digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#526615: fails to install to RAID across virtual (kvm/virtio) disks
Am Dienstag, den 04.08.2009, 14:40 +0200 schrieb martin f krafft: also sprach Felix Zielcke fziel...@z-51.de [2009.07.24.1410 +0200]: We currently use in grub-setup ioctl (GET_ARRAY_INFO) and ioctl (GET_DISK_INFO) and unfortunately they return the major and minor of the device and not the name of the device file. But you have to somehow map that to the device file later, right? mdadm-lab:~# ls -la /dev/vda brw-rw 1 root disk 254, 0 2009-08-04 13:53 /dev/vda /dev/vda is a regular device like any other, except that it uses the 'experimental' major number 254. I don't understand why that should be treated any differently than e.g. a SCSI disk with major number 8. The problem is that we currently create the filename of the device by using the major and minor Like this: if (major == SCSI_DISK0_MAJOR) sprintf (name, /dev/sd%c, 'a' + minor / 16); This just doestn't work if the major is for local use according to the kernel docs. We could make 254 map to /dev/vda but maybe it's wrong then for someone else. Unfortunately I don't know why we have 2 different methods of dealing with RAID disks. The ioctl method in grub-setup and the method to just read the md superblock on all disks and add them to a list in grub-probe. -- Felix Zielcke Proud Debian Maintainer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526615: fails to install to RAID across virtual (kvm/virtio) disks
also sprach Felix Zielcke fziel...@z-51.de [2009.08.04.1456 +0200]: The problem is that we currently create the filename of the device by using the major and minor Like this: if (major == SCSI_DISK0_MAJOR) sprintf (name, /dev/sd%c, 'a' + minor / 16); This just doestn't work if the major is for local use according to the kernel docs. We could make 254 map to /dev/vda but maybe it's wrong then for someone else. Unfortunately I don't know why we have 2 different methods of dealing with RAID disks. The ioctl method in grub-setup and the method to just read the md superblock on all disks and add them to a list in grub-probe. Thanks for the explanation. This is indeed a bit ugly. ;) -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems first get your facts; then you can distort them at your leisure. -- mark twain digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#526615: fails to install to RAID across virtual (kvm/virtio) disks
Am Sonntag, den 03.05.2009, 10:12 +0200 schrieb martin f krafft: also sprach martin f krafft madd...@debian.org [2009.05.02.1107 +0200]: However, trying to install to a system with RAID1 across two virtual disks, I run into two errors, depending on which approach I take: Those two errors are separate issues, thus the clone. Let's pull them apart: mdadm-test:/boot/grub# grub-install /dev/md0 grub-setup: error: Unknown device number: 254, 0 This is the current bug #526615: grub tries to be smart and analyses /dev/md0 to find the component devices, but then does not know how to handle device major number 254 (kernel reserved for local/experimental), runs into the corner and puts on the stubborn face. Instead, I think it would make sense if grub would simply treat the block device as a plain block device and resist trying to be smart about it. For safety, maybe this could be done with a flag, --unknown-as-block, or more explicit e.g. grub-setup --block-devices=/dev/vda,/dev/vdb. I think this would also address #525879. We currently use in grub-setup ioctl (GET_ARRAY_INFO) and ioctl (GET_DISK_INFO) and unfortunately they return the major and minor of the device and not the name of the device file. See util/raid.c for the grub2 code. If you need to specify the devices of which md0 consists, then you could just use grub-install /dev/sda etc. -- Felix Zielcke -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526615: fails to install to RAID across virtual (kvm/virtio) disks
clone 526615 -1 retitle -1 improved error message if grub cannot be embedded severity -1 wishlist retitle 526615 should treat unknown block devices as plain block devices severity 526615 wishlist thanks also sprach martin f krafft madd...@debian.org [2009.05.02.1107 +0200]: However, trying to install to a system with RAID1 across two virtual disks, I run into two errors, depending on which approach I take: Those two errors are separate issues, thus the clone. Let's pull them apart: mdadm-test:/boot/grub# grub-install /dev/md0 grub-setup: error: Unknown device number: 254, 0 This is the current bug #526615: grub tries to be smart and analyses /dev/md0 to find the component devices, but then does not know how to handle device major number 254 (kernel reserved for local/experimental), runs into the corner and puts on the stubborn face. Instead, I think it would make sense if grub would simply treat the block device as a plain block device and resist trying to be smart about it. For safety, maybe this could be done with a flag, --unknown-as-block, or more explicit e.g. grub-setup --block-devices=/dev/vda,/dev/vdb. I think this would also address #525879. Now, for the second issue: mdadm-test:/boot/grub# grub-install '(hd0)' grub-setup: error: Core image is too big for embedding, but this is required when the root device is on a RAID array or LVM volume. The problem here was found by Robert Millan, who spotted that I didn't have partitions and thus deprived grub2 of the 32k it has to embed itself. It works when I use /dev/vda directly, because Grub then uses blocklists (ugh!), but that does not work for RAID. I converted the device into a partitioned device and put the RAID1 onto /dev/vd[ab]1 and it worked. Maybe the error message could be a litte more explicit and mention the need for a partition table? While on the topic of messages, maybe Grub could print a fat warning when it falls back to using blocklists? I also found it confusing that this message comes from grub-setup, while I used a core.img file that didn't include any references to raid. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#526615: fails to install to RAID across virtual (kvm/virtio) disks
Package: grub-pc
Version: 1.96+20080724-16
Severity: normal
I have kvm configured to make disks available as virtio-blk devices,
and now I am trying to install grub2 onto them.
This works on plain VMs:
vera:~# ls -l /dev/vda
brw-rw 1 root disk 254, 0 May 2 11:01 /dev/vda
vera:~# grub-install /dev/vda
Installation finished. No error reported.
This is the contents of the device map /boot/grub/device.map.
Check if this is correct or not. If any of the lines is incorrect,
fix it and re-run the script `grub-install'.
(hd0) /dev/vda
However, trying to install to a system with RAID1 across two virtual
disks, I run into two errors, depending on which approach I take:
mdadm-test:/boot/grub# ls -l /dev/{md0,vd[ab]}
brw-rw 1 root disk 9, 0 May 2 10:07 /dev/md0
brw-rw 1 root disk 254, 0 May 2 10:07 /dev/vda
brw-rw 1 root disk 254, 16 May 2 10:07 /dev/vdb
mdadm-test:/boot/grub# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 vda[0] vdb[1]
1572800 blocks [2/2] [UU]
unused devices: none
mdadm-test:/boot/grub# grub-install /dev/md0
grub-setup: error: Unknown device number: 254, 0
mdadm-test:/boot/grub# grub-install '(hd0)'
grub-setup: error: Core image is too big for embedding, but this is required
when
the root device is on a RAID array or LVM volume.
mdadm-test:/boot/grub# cat device.map
(hd0) /dev/vda
(hd1) /dev/vdb
(hd2) /dev/vdc
(hd3) /dev/vdd
(hd4) /dev/vde
(hd5) /dev/vdf
(hd6) /dev/vdg
It does not matter if I do it manually with grub-mkimage/grub-setup
or let grub-install do it, the result is the same. But since
grub-install does not offer verbose output, here's the manual
rundown with verbose output, in case it helps:
mdadm-test:/boot/grub# grub-mkimage -v -o core.img biosdisk raid ext2
grub-mkimage: info: getting the size of /usr/lib/grub/i386-pc/kernel.img
grub-mkimage: info: getting the size of /usr/lib/grub/i386-pc/biosdisk.mod
grub-mkimage: info: getting the size of /usr/lib/grub/i386-pc/raid.mod
grub-mkimage: info: getting the size of /usr/lib/grub/i386-pc/fshelp.mod
grub-mkimage: info: getting the size of /usr/lib/grub/i386-pc/ext2.mod
grub-mkimage: info: the total module size is 0x4410
grub-mkimage: info: reading /usr/lib/grub/i386-pc/kernel.img
grub-mkimage: info: getting the size of /usr/lib/grub/i386-pc/kernel.img
grub-mkimage: info: getting the size of /usr/lib/grub/i386-pc/biosdisk.mod
grub-mkimage: info: reading /usr/lib/grub/i386-pc/biosdisk.mod
grub-mkimage: info: getting the size of /usr/lib/grub/i386-pc/biosdisk.mod
grub-mkimage: info: getting the size of /usr/lib/grub/i386-pc/raid.mod
grub-mkimage: info: reading /usr/lib/grub/i386-pc/raid.mod
grub-mkimage: info: getting the size of /usr/lib/grub/i386-pc/raid.mod
grub-mkimage: info: getting the size of /usr/lib/grub/i386-pc/fshelp.mod
grub-mkimage: info: reading /usr/lib/grub/i386-pc/fshelp.mod
grub-mkimage: info: getting the size of /usr/lib/grub/i386-pc/fshelp.mod
grub-mkimage: info: getting the size of /usr/lib/grub/i386-pc/ext2.mod
grub-mkimage: info: reading /usr/lib/grub/i386-pc/ext2.mod
grub-mkimage: info: getting the size of /usr/lib/grub/i386-pc/ext2.mod
grub-mkimage: info: kernel_img=0x23c3a90, kernel_size=0xbd14
grub-mkimage: info: the core size is 0x6016
grub-mkimage: info: getting the size of /usr/lib/grub/i386-pc/diskboot.img
grub-mkimage: info: reading /usr/lib/grub/i386-pc/diskboot.img
grub-mkimage: info: getting the size of /usr/lib/grub/i386-pc/diskboot.img
grub-mkimage: info: writing 0x200 bytes
grub-mkimage: info: the first module address is 0xfb04
grub-mkimage: info: writing 0x6016 bytes
mdadm-test:/boot/grub# grub-setup -v /dev/md0
grub-setup: info: the size of hd0 is 3145728
grub-setup: info: opening the device `/dev/vda'
grub-setup: info: the size of hd0 is 3145728
grub-setup: info: the size of hd0 is 3145728
grub-setup: info: opening the device `/dev/vda'
grub-setup: info: the size of hd1 is 3145728
grub-setup: info: opening the device `/dev/vdb'
grub-setup: info: the size of hd1 is 3145728
grub-setup: info: the size of hd1 is 3145728
grub-setup: info: opening the device `/dev/vdb'
grub-setup: info: the size of hd2 is 1048576
grub-setup: info: opening the device `/dev/vdc'
grub-setup: info: the size of hd2 is 1048576
grub-setup: info: opening the device `/dev/vdc'
grub-setup: info: the size of hd3 is 262144
grub-setup: info: opening the device `/dev/vdd'
grub-setup: info: the size of hd3 is 262144
grub-setup: info: opening the device `/dev/vdd'
grub-setup: info: the size of hd4 is 262144
grub-setup: info: opening the device `/dev/vde'
grub-setup: info: the size of hd4 is 262144
grub-setup: info: opening the device `/dev/vde'
grub-setup: info: the size of hd5 is 262144
grub-setup: info: opening the device `/dev/vdf'
grub-setup: info: the size of hd5 is 262144
grub-setup: info:
