Система, жившая до того на семействе /dev/sda2..8, спокойно перенесла виртуальный переезд на /dev/sdb2..6, поэтому я даже не сразу сообразил, как такое могло произойти, и как уберечься от подобных фокусов в дальнейшем.

Отгадка, как обычно, крылась в манах (UsingUUID):

Linux now prefers to use UUID (Universally Unique Identifier), LABEL, or symlinks to identify media storage devices on a system. Directly using /dev/hd*# or /dev/sd*# is no longer preferred since these device assignments can change between system boots:

• all filesystems should be specified by UUID= or LABEL= for each partition.
• all physical devices should be specified by a symlink, like /dev/cdrom for a cd drive and /dev/disk/by-id/... for each physical hard drive.

The files for which UUID is most critical:

• /boot/grub/menu.lst
• /etc/fstab
• /etc/initramfs-tools/conf.d/resume

Просмотр /etc/fstab подтвердил догадку. Системные ext3 разделы были смонтированы через UUID, в то время как ntfs-разделы монтировались по старинке через имена вида /dev/sd*.

Таким образом, решение проблемы заключается в монтировании ntfs-разделов по UUID.

Узнать UUID для конкретного раздела можно так:

$ sudo vol_id -u /dev/sdb1
7CF803F6A8035E22
 

Размонтируем все ntfs-разделы, меняем записи в /etc/fstab, и заново монтируем раздел.

Было:

/dev/sda1 /mnt/sda1 ntfs  rw,noexec,utf8  0 0

Стало:

UUID=7CF803F6A8035E22 /mnt/sda1 ntfs  rw,noexec,utf8  0 0

Теперь при подключении новых устройств запись прежний порядок монтирования сохранится.

UPD: Харитон пишет:

мне было известно 4 способа определения uuid'а, теперь знаю пятый))
- с помощью утилиты blkid (входит в пакет e2fsprogs)
sudo blkid /dev/sda1
- "...существуют и другие способы получить UUID например для ext2 используя dumpe2fs..."
dumpe2fs -h /dev/sda6
- или так:
ls -al /dev/disk/by-uuid/
- или так:
sudo tune2fs -l /dev/sda1 | grep UUID

самый примечательный из них третий, т.к. можно обойтись без sudo и дает список uuid'ов всех устройств