28020 2012-11-21 14:22:17 +0400 grub. LVM. UUID корневого раздела 2020-08-07 06:12:03 +0300 1 1 4 Development Sisyphus grub2-pc unstable all Linux CLOSED NOTABUG https://bugzilla.altlinux.org/show_bug.cgi?id=38789 P3 normal --- 28136 27685 1 timonbl4 mike aen boyarsh jackie.rosen sbolshakov shaba vitty vsu qa-sisyphus oldest_to_newest 135103 0 timonbl4 2012-11-21 14:22:17 +0400 Если корень будущей системы находится на LVM, то при генерации grub.cfg пишется запись типа "linux root=/path/to/device ...", а хотелось бы "linux root=UUID=<uuid> ..." 135105 1 timonbl4 2012-11-21 14:25:37 +0400 Нашёл строчку в 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. Может в этом проблема? 135219 2 aen 2012-11-21 16:43:32 +0400 Блокер 27685 На grub2 135237 3 mike 2012-11-21 19:52:16 +0400 Точнее, на grub2-pc. 2 vsu: не подскажешь часом, как лучше быть? 135238 4 mike 2012-11-21 19:55:47 +0400 Да, чуть не забыл -- вот этот тестовый коммит же именно про эту багу был, так? http://git.altlinux.org/people/timonbl4/packages/?p=grub2-pc.git;a=commitdiff;h=6cebde14a00f5275e8e2b45203646358aa04d23d 135239 5 timonbl4 2012-11-21 19:58:09 +0400 (В ответ на комментарий №4) > Да, чуть не забыл -- вот этот тестовый коммит же именно про эту багу был, так? > > http://git.altlinux.org/people/timonbl4/packages/?p=grub2-pc.git;a=commitdiff;h=6cebde14a00f5275e8e2b45203646358aa04d23d Да 135249 6 vsu 2012-11-21 21:41:19 +0400 Похоже, неиспользование 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 обычно помечается в начальных секторах диска). 135257 7 timonbl4 2012-11-22 10:07:32 +0400 (В ответ на комментарий №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 135390 8 mike 2012-11-23 19:53:22 +0400 (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) 135392 9 vsu 2012-11-23 21:15:39 +0400 Очевидно, evms устанавливает имена для устройств dm не так, как это делает настоящий lvm, поэтому его устройства и не определяются как LVM. Значит, без отказа от evms (или очередной кучи ALT-specific патчей) установка с /boot на LVM проходить не будет; возможно, окажутся сломанными и ещё какие-нибудь конфигурации. 135393 10 mike 2012-11-23 21:40:15 +0400 (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* отсутствуют). 135394 11 mike 2012-11-23 22:22:56 +0400 (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. 135396 12 aen 2012-11-24 05:45:31 +0400 Этот баг -- регрессия? 135415 13 vsu 2012-11-25 21:37:56 +0400 Кстати, возможно, в 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 135512 14 mike 2012-11-28 01:03:06 +0400 (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 апстрим наверняка посмотрит большими синими глазами... 135719 15 mike 2012-12-04 01:39:57 +0400 (In reply to comment #12) > Этот баг -- регрессия? (проверил наконец) Да, СПТ встал на lvm root без проблем. А я завяз с попыткой забрать lvm у evms (evms_deactivate == dmsetup remove_all) _и_ затем поднять их заново. 135766 16 mike 2012-12-04 22:05:29 +0400 См. bug #28181. 135922 17 mike 2012-12-07 22:33:12 +0400 PS: ещё можно оторвать от guile-evms устаревшую проверку насчёт /boot на LVM, хотя в качестве рекомендации нынешнее сообщение об ошибке может быть уместно (только тогда s/be resided/reside/). Стоит ли это отдельной баги?..