Graham Bleach wrote: I've just run into the same error, when trying to bring my Debian Lenny-based VM up to date, i.e. just applying the updates via aptitude, which wanted to install linux-image-2.6.26-2-xen-686 (2.6.26-15lenny2). In my case, the error message is /boot/grub$ sudo update-grub Searching for GRUB installation directory ... found: /boot/grub warning: grub-probe can't find drive for /dev/sda1. grub-probe: error: Cannot find a GRUB drive for /dev/sda1. Check your device.map. /boot/grub/device.map was initially empty. I tried changing it to (hd0) /dev/sda and also (hd0,0) /dev/sda1 but neither made any difference. 'mount' says: $ mount /dev/sda1 on / type ext3 (rw,noatime,nodiratime) tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) udev on /dev type tmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) Can anyone suggest what should be in device.map? cheers Chris -- Chris Dennis email: chris(a)fbcs.co.uk Fordingbridge Computer Services web: http://www.fbcs.co.uk Phone: (01425) 658265 Mobile: 07814 239534

http://lists.bitfolk.com/lurker/message/20080529.142153.954fedf4.en.html On Thu, May 28, 2009 at 4:06 PM, Andy Smith <andy(a)bitfolk.com> wrote:

Hi Chris, On Thu, May 28, 2009 at 06:59:28PM +0100, Chris Dennis wrote: A bit of history: Obviously your virtual machine requires some block devices, and in the earlier days since Linux tended to expect everything to be a SCSI block device (even IDE devices by this point). So it seemed sensible to just present them as /dev/sd* even though they were really Xen paravirtual block devices. When the various virtualisation techniques were making some progress on being integrated into the upstream kernel, it was decided that since there was going to be a/some paravirtual block device drivers there then they really should have their own devices. That's why the name changed to /dev/xvd*. Functionally there is no difference, and it is best if you refer to filesystems by UUID or label so that the block devices can be renamed and you don't have to care. Which name of block device you have is set in your Xen domain's config in BitFolk's dom0 servers so you can't just change it (but you don't need to). It seems you will need to create /dev/sda to make update-grub happy. You would do it like this: # cd /dev && mknod sda b 8 0 # chown root:disk /dev/sda # chmod 660 /dev/sda In this instance the major/minor numbers don't matter, in fact sda (or xvda) will never be used as it doesn't exist, this is purely to make update-grub and other scripts happy. In future I am looking at exporting a disk device instead which is partitioned. It makes access in dom0 a little more tricky but it's what the VM's kernel expects to see so will reduce confusion there. I just need to make sure I can still do things like take snapshots and grow filesystems. Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting Q. How many mathematicians does it take to change a light bulb? A. Only one - who gives it to six Californians, thereby reducing the problem to an earlier joke.

Graham Bleach wrote: I've just run into the same error, when trying to bring my Debian Lenny-based VM up to date, i.e. just applying the updates via aptitude, which wanted to install linux-image-2.6.26-2-xen-686 (2.6.26-15lenny2). In my case, the error message is /boot/grub$ sudo update-grub Searching for GRUB installation directory ... found: /boot/grub warning: grub-probe can't find drive for /dev/sda1. grub-probe: error: Cannot find a GRUB drive for /dev/sda1. Check your device.map. /boot/grub/device.map was initially empty. I tried changing it to (hd0) /dev/sda and also (hd0,0) /dev/sda1 but neither made any difference. 'mount' says: $ mount /dev/sda1 on / type ext3 (rw,noatime,nodiratime) tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) udev on /dev type tmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) Can anyone suggest what should be in device.map? cheers Chris