Comment # 4 on bug 907457 from Michael Chang

During install, the usb disk was assigned sda while the installation was to sdb

  '/dev/disk/by-id/scsi-1PHISON_USB3' => '/dev/sda',
  '/dev/disk/by-id/ata-SanDisk_SDSSDRC032G_125216400243' => '/dev/sdb'
  '/dev/disk/by-id/ata-ST2000DM001-1CH164_Z1E524FW' => '/dev/sdc'

The initial device.map

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

Until the USB got removed, the sdb becomes sda and the problem happened. 

2014-11-25 19:43:10 <1> pbl-yaml-3915.1 Library::DefineUdevMapping.428: udevmap
= 
  '/dev/disk/by-id/ata-ST2000DM001-1CH164_Z1E524FW' => '/dev/sdb'
  '/dev/disk/by-id/ata-SanDisk_SDSSDRC032G_125216400243' => '/dev/sda'

and above device.map translated it to (hd1) ...

And since sdb had no partition, it's not listed in "partitions" output in the
first place and therefore got ignored. 

The trouble was caused by using kernel device name in device.map because it is
floating by nature. The installation seems not affected as it's referring to
/etc/grub_installdevice which uses by-id device name. But if you tried other
options in yast2 bootloader, for ex, reinstall mbr boot code would not work as
long as the hd0 device is now missing or wrong in device.map.

My question is how legacy-grub handles such kernel device name changes and how
can device.map react to it .. ? Steffen do you know ?