Bug 28020 - grub. LVM. UUID корневого раздела
: grub. LVM. UUID корневого раздела
Status: CLOSED NOTABUG
: Sisyphus
(All bugs in Sisyphus/grub2-pc)
: unstable
: all Linux
: P3 normal
Assigned To:
:
:
:
: 28136
: 27685
  Show dependency tree
 
Reported: 2012-11-21 14:22 by
Modified: 2014-02-16 15:58 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2012-11-21 14:22:17
Если корень будущей системы находится на LVM, то при генерации grub.cfg пишется
запись типа "linux root=/path/to/device ...", а хотелось бы "linux
root=UUID=<uuid> ..."
------- Comment #1 From 2012-11-21 14:25:37 -------
Нашёл строчку в 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.

Может в этом проблема?
------- Comment #2 From 2012-11-21 16:43:32 -------
Блокер 27685
На grub2
------- Comment #3 From 2012-11-21 19:52:16 -------
Точнее, на grub2-pc.

2 vsu: не подскажешь часом, как лучше быть?
------- Comment #4 From 2012-11-21 19:55:47 -------
Да, чуть не забыл -- вот этот тестовый коммит же именно про эту багу был, так?

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

Да
------- Comment #6 From 2012-11-21 21:41:19 -------
Похоже, неиспользование 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 обычно помечается в
начальных секторах диска).
------- Comment #7 From 2012-11-22 10:07:32 -------
(В ответ на комментарий №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
------- Comment #8 From 2012-11-23 19:53:22 -------
(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)
------- Comment #9 From 2012-11-23 21:15:39 -------
Очевидно, evms устанавливает имена для устройств dm не так, как это делает
настоящий lvm, поэтому его устройства и не определяются как LVM. Значит, без
отказа от evms (или очередной кучи ALT-specific патчей) установка с /boot на
LVM проходить не будет; возможно, окажутся сломанными и ещё какие-нибудь
конфигурации.
------- Comment #10 From 2012-11-23 21:40:15 -------
(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* отсутствуют).
------- Comment #11 From 2012-11-23 22:22:56 -------
(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.
------- Comment #12 From 2012-11-24 05:45:31 -------
Этот баг -- регрессия?
------- Comment #13 From 2012-11-25 21:37:56 -------
Кстати, возможно, в 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
------- Comment #14 From 2012-11-28 01:03:06 -------
(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 апстрим наверняка посмотрит большими
синими глазами...
------- Comment #15 From 2012-12-04 01:39:57 -------
(In reply to comment #12)
> Этот баг -- регрессия?
(проверил наконец) Да, СПТ встал на lvm root без проблем.

А я завяз с попыткой забрать lvm у evms (evms_deactivate == dmsetup remove_all)
_и_ затем поднять их заново.
------- Comment #16 From 2012-12-04 22:05:29 -------
См. bug #28181.
------- Comment #17 From 2012-12-07 22:33:12 -------
PS: ещё можно оторвать от guile-evms устаревшую проверку насчёт /boot на LVM,
хотя в качестве рекомендации нынешнее сообщение об ошибке может быть уместно
(только тогда s/be resided/reside/).  Стоит ли это отдельной баги?..