Bug 28020

Нашёл строчку в grub-mkconfig.in:
GRUB_DEVICE_UUID="`${grub_probe} --device ${GRUB_DEVICE} --target=fs_uuid 2> /dev/null`"

Пытаюсь выполнить:
# grub-probe --device /dev/mapper/lvm1-root --target=fs_uuid
...
grub-probe: error: cannot find a GRUB device /dev/mapper/lvm1-root. Check your device.map.

Может в этом проблема?

Блокер 27685
На grub2

Точнее, на grub2-pc.

2 vsu: не подскажешь часом, как лучше быть?

Да, чуть не забыл -- вот этот тестовый коммит же именно про эту багу был, так?

http://git.altlinux.org/people/timonbl4/packages/?p=grub2-pc.git;a=commitdiff;h=6cebde14a00f5275e8e2b45203646358aa04d23d

(В ответ на комментарий №4)
> Да, чуть не забыл -- вот этот тестовый коммит же именно про эту багу был, так?
> 
> http://git.altlinux.org/people/timonbl4/packages/?p=grub2-pc.git;a=commitdiff;h=6cebde14a00f5275e8e2b45203646358aa04d23d

Да

Похоже, неиспользование UUID для LVM было сделано специально:

http://bzr.savannah.gnu.org/lh/grub/trunk/grub/revision/2496
http://bzr.savannah.gnu.org/lh/grub/trunk/grub/revision/2503

(поэтому и тот тестовый коммит на самом деле не должен работать).

В принципе для такого решения есть основания — имя тома LVM не менее стабильно, чем LABEL=... для ФС на обычном разделе (проблемы могут возникнуть только из-за неуникальности имён при подключении чужих дисков). Как минимум в CentOS 6 после установки на LVM в параметры ядра добавляется root=/dev/$VG/$LV (плюс ещё параметры для их initramfs: rd_LVM_LV=$swap_vg/$swap_lv rd_LVM_LV=$root_vg/$root_lv), а в fstab для томов LVM записываются не UUID, а имена устройств в виде /dev/mapper/$VG-$LV (почему-то именно в таком варианте, а не /dev/$VG/$LV).

Хотя ошибка grub-probe выглядит подозрительно в том плане, что может не работать размещение /boot на LVM (что вроде бы должно поддерживаться благодаря наличию в GRUB соответствующих модулей и тому, что core.img обычно помечается в начальных секторах диска).

(В ответ на комментарий №6)
> В принципе для такого решения есть основания — имя тома LVM не менее стабильно,
> чем LABEL=... для ФС на обычном разделе (проблемы могут возникнуть только из-за
> неуникальности имён при подключении чужих дисков). Как минимум в CentOS 6 после
> установки на LVM в параметры ядра добавляется root=/dev/$VG/$LV (плюс ещё
> параметры для их initramfs: rd_LVM_LV=$swap_vg/$swap_lv
> rd_LVM_LV=$root_vg/$root_lv), а в fstab для томов LVM записываются не UUID, а
> имена устройств в виде /dev/mapper/$VG-$LV (почему-то именно в таком варианте,
> а не /dev/$VG/$LV).

Чем в данной ситуации /dev/mapper/$VG-$LV лучше, нежели UUID ФС?

> Хотя ошибка grub-probe выглядит подозрительно в том плане, что может не
> работать размещение /boot на LVM (что вроде бы должно поддерживаться благодаря
> наличию в GRUB соответствующих модулей и тому, что core.img обычно помечается в
> начальных секторах диска).

Да, grub не ставится, если /boot находится на lvm

(In reply to comment #7)
> Чем в данной ситуации /dev/mapper/$VG-$LV лучше, нежели UUID ФС?
Менее опосредован как минимум?

На https://wiki.archlinux.org/index.php/GRUB2#LVM тоже рекомендуют по vg-lv.


(In reply to comment #1)
> Пытаюсь выполнить:
Воспроизводится при ручном запуске параллельно с alterator-grub:

> # chroot /mnt/destination update-grub
[...]
> Found initrd image: /boot/initrd.img
> The name "lvm2|main|root" should be mangled but it contains blacklisted characters.
> _deps: task run failed for (254:1)
[...эти две строки ещё надцать раз...]
> /usr/sbin/grub-probe: error: cannot find a GRUB drive for /dev/mapper/main-root. Check your device.map.

Локализовать источник этого mangling пока не удалось; похоже, это сам EVMS:
> tests/suite/Tests/lvm2/test3:   @output = dm_info("lvm2|" . $container_name . "|" . $name);

А вот в lvm2 (libdm) имена стали проверять придирчивей (_is_whitelisted_char):
http://git.altlinux.org/gears/l/lvm2.git?p=lvm2.git;a=blobdiff;f=libdm/libdm-common.c;h=16053244c2ed398fc8df51e44b8323c1f19b1af8;hp=8d0fea343e0c3d99e1c81809b97326818d09c3c9;hb=55761e14af4c167f79e9d7d4f6cfa28bb84be51d;hpb=c64d7cd38121772f3f62c7c08bedb3289f3a1ecd

Добавил "|" в этот whitelist, порадовался упоминанию blacklist в диагностике, проехал чуть дальше:

> # chroot /mnt/destination grub-probe /boot/grub
> device-mapper: table ioctl on  failed: No such device or address
> device-mapper: table ioctl on  failed: No such device or address
> device-mapper: table ioctl on  failed: No such device or address
> device-mapper: table ioctl on main-root failed: No such device or address
> device-mapper: table ioctl on  failed: No such device or address
> device-mapper: table ioctl on  failed: No such device or address
> device-mapper: table ioctl on main-root failed: No such device or address
> device-mapper: table ioctl on  failed: No such device or address
> device-mapper: table ioctl on  failed: No such device or address
> device-mapper: table ioctl on main-root failed: No such device or address
> grub-probe: error: cannot find a GRUB device for /dev/mapper/main-root. Check your device.map.
> # chroot /mnt/destination dmsetup ls
> sda1    (254:0)
> lvm2|main|root  (254:1)

Очевидно, evms устанавливает имена для устройств dm не так, как это делает настоящий lvm, поэтому его устройства и не определяются как LVM. Значит, без отказа от evms (или очередной кучи ALT-specific патчей) установка с /boot на LVM проходить не будет; возможно, окажутся сломанными и ещё какие-нибудь конфигурации.

(In reply to comment #7)
> Чем в данной ситуации /dev/mapper/$VG-$LV лучше, нежели UUID ФС?
Подумал ещё, оторвал grub-2.00-evms-crap-alt.patch (т.к. мухлевать с именами девайсов под /dev/evms/ теперь вроде как и не надо, добавилась и задействована поддержка libdevmapper).

grub-install отработал, но первая стадия не нашла корень по UUID (с каковым он и прописан).

Более внимательное рассмотрение показало, что в grub-install отрабатывает только определение fs ("ext2" в моём случае), но _не_ partmap и abstraction: http://git.altlinux.org/gears/g/grub2.git?p=grub2.git;a=blob;f=grub2/util/grub-install.in;h=e19f1cd943be0613077581842a5c0209c42417ab;hb=HEAD#l572 -- т.е. соответствующие два grub-probe, будучи вызваны руками с grub_device=/dev/evms/lvm2/main/root, возвращают пустую строку.

Если приколотить недостающее гвоздями в свежеустановленный grub-install:
http://git.altlinux.org/gears/g/grub2.git?p=grub2.git;a=blob;f=grub2/util/grub-install.in;h=e19f1cd943be0613077581842a5c0209c42417ab;hb=HEAD#l613
> -modules="$modules $fs_module $partmap_module $devabstraction_module"
> +modules="$modules $fs_module part_msdos $partmap_module lvm $devabstraction_module"
-- то установка grub и загрузка им ядра/initrd происходит нормально, затык происходит уже в initrd (/dev/sda* есть, в /dev/mapper/ только control, /dev/dm* отсутствуют).

(In reply to comment #10)
> затык происходит уже в initrd 
При неустановленном make-initrd-lvm неудивительно.  С ним, однако, затык вида
initrd: udev: Running lvm handler ...
вследствие получения ядром root=/dev/evms/lvm2/main/root; если поправить вручную в grub.cfg или в рантайме на /dev/mapper/main-root (который в initramfs доступен), загрузка проходит нормально.

Понимаю, что к 7.0 с EVMS спрыгнуть не получится; похоже, придётся переработать grub-2.00-evms-crap-alt.patch и что-то делать с evms/lvm2.

Этот баг -- регрессия?

Кстати, возможно, в evms-crap-alt.patch ещё некорректно обрабатываются символы '-' в именах VG/LV — в lvm они при формировании имени dm-устройства удваиваются (/dev/vg-foo/lv-bar превращается в /dev/mapper/vg--foo-lv--bar), а вот evms, похоже, этого не делает:

http://git.altlinux.org/people/timonbl4/packages/?p=evms.git;a=blob;f=plugins/lvm2/regions.c;h=3c2f641e4d8f4d3d6de8085eddff11632661d6f5;hb=HEAD#l265

(In reply to comment #12)
> Этот баг -- регрессия?
Насколько понимаю http://wiki.gentoo.org/wiki/GRUB2, нет: "Upgrading to GRUB 2 might be necessary as it allows: [...] booting from directly logical volume management such as LVM2 support" (для чего требуется включенная поддержка device-mapper, как утверждается далее по тексту, т.е. оставить старые костыли как есть не получается -- одним из тупиков меньше).

(In reply to comment #13)
> Кстати, возможно, в evms-crap-alt.patch ещё некорректно обрабатываются символы
Об это не спотыкался.  В качестве варианта сейчас обдумываю выкидывание максимума костылей из grub-probe и около с переносом минимально необходимого их объёма в alterator-grub в виде постобработки grub.cfg -- попытка с разбегу прикрутить понимание /dev/evms/lvm2/ как тоже lvm abstraction не прошла, надо копать глубже, а на патчи в пользу evms апстрим наверняка посмотрит большими синими глазами...

(In reply to comment #12)
> Этот баг -- регрессия?
(проверил наконец) Да, СПТ встал на lvm root без проблем.

А я завяз с попыткой забрать lvm у evms (evms_deactivate == dmsetup remove_all) _и_ затем поднять их заново.

См. bug #28181.

PS: ещё можно оторвать от guile-evms устаревшую проверку насчёт /boot на LVM, хотя в качестве рекомендации нынешнее сообщение об ошибке может быть уместно (только тогда s/be resided/reside/).  Стоит ли это отдельной баги?..