Created attachment 8345 [details] Скриншот установщика на этапе "Подготовка диска" Сабж приводит к тому, что невозможно назначить точку монтирования существующей загрузочной EFI партиции. Сделать ее таковой можно только через создание файловой системы, что приводит к потере альтернативных EFI загрузчиков (Windows и т.п.) Поведение на sisyphus/p9/p8 одинаковое. Не уверен, что бага по адресу, может быть дело в libevms, но пока так.
Created attachment 8346 [details] Коллаж разного поведения alterator-vm для определенной и неопределенной ФС
У меня не получилось воспроизвести. С помощью чего создавался EFI раздел?
Просто установить систему по умолчанию, потом на машину с уже установленной системой запустить еще раз инсталлятор.
В общем, мне наконец удалось воспроизвести что-то подобное. Проявляется это только если таблица разделов на диске - mbr (dos). Также инсталлятор ведет себя очень странно при работе с диском с mbr. Например, невозможно задать файловые системы FAT32/FAT16/NTFS при создании партиции. Их просто нет в списке. Зато если на этапе создания ФС нажать "Отмена", а затем снова открыть окно создания ФС (кликнув на раздел и нажав "Make Filesystem" в правом углу) - все эти файловые системы появятся в списке. Чудеса. Для gpt мне такого повторить не удалось. В общем, проверь, пожалуйста, что за таблица разделов на диске mmcblk0 Можно как-то так fdisk -l | grep /dev/mmcblk0: -A7
(В ответ на комментарий №4) > В общем, проверь, пожалуйста, что за таблица разделов на диске mmcblk0 > Можно как-то так fdisk -l | grep /dev/mmcblk0: -A7 disklabel type: gpt
Наконец разобрался, в чем проблема. Виноваты libevms и fatresize. evms по каким-то причинам теряет букву p у mmcblk устройств. То есть - было, например, /dev/mmcblk0p3 стало - /dev/evms/mmcblk03 В fatresize есть функция get_devname, которая пытается получить устройство-родитель: http://git.altlinux.org/srpms/f/fatresize.git?p=fatresize.git;a=blob;f=fatresize/fatresize.c;h=c85bef2615b458498d6e3fb13572542ad2b1b600;hb=HEAD#l139 Работает она так: снача отбрасывается "evms/", при наличии, из пути (было /dev/evms/mmcblk03 стало /dev/mmcblk03). Затем в цикле отбрасываются все цифры с конца. В итоге мы получаем /dev/mmcblk, которого не существует. Что интересно, для пути /dev/mmcblk0p3 (будет /dev/mmcblk0p) оно тоже отработает неверно, но в апстриме fatresize это исправлено: https://github.com/ya-mouse/fatresize/commit/cf12400b5231e8a2eafc18c81428da618f741bb6 Баг также проявляется на ssd (nvme0n1p* - раздел, nvme0n1 - родитель) да и скорее всего в любом другом случае, где название раздела отличается от названия родителя-устройства не только порядковым номером. На скриншоте, кстати, видны потерянные буквы p в названиях :)
task #242568
Раздел с vfat теперь отображается как fat32. Раздел NTFS, зашифрованный Bitlocker, раньше отображался как NTFS. Теперь он отображается как пустой раз. Т.е. можно затереть раздел с данными не подозревая этого. Правильно будет вернуть обозначение раздела как NTFS или обозначать его как undefined.
Тогда уж unknown а не undefined.
(В ответ на комментарий №9) > Тогда уж unknown а не undefined. mount на этот "BitLocker" ругается как "unknown filesystem type", поэтому, да: или "unknown" или "unsupported"
Но если мы можем его распознать, то лучше так и сделать.
Вернуть надпись NTFS будет неправильным в любом случае. Это ведь не просто надпись, это знак того, что раздел распознался как NTFS и что с ним будет работать NTFS плагин evms. А работать с BitLocker'ом он не умеет. Можно попробовать ставить unknown на все неизвестные разделы. Только это, конечно, затронет не только разделы с BitLocker'ом, а вообще все разделы, на которых не отработал ни один evms плагин.
Или, чтобы распознавать BitLocker разделы, можно сделать плагин в evms. Правда, это будет его весь функционал, потому что утилит для работы с BitLocker'ом практически нет. Есть dislocker - но на этапе разметки дисков он бесполезен, т.к. не умеет шифровать диски.
(В ответ на комментарий №12) > Можно попробовать ставить unknown на все неизвестные разделы. Только это, > конечно, затронет не только разделы с BitLocker'ом, а вообще все разделы, на > которых не отработал ни один evms плагин. Мне кажется, не страшно пометить все неизвестное как unknown. Главное, чтобы пользователь знал, что на этих партициях что-то есть. Еще важно определиться, активировать для таких партиций в alterator-vm опцию изменения точки монтирования или нет. Т.е. давать ли пользователю возможность добавлять такие партиции в fstab на этапе установки...
(В ответ на комментарий №14) > (В ответ на комментарий №12) > > > Можно попробовать ставить unknown на все неизвестные разделы. Только это, > > конечно, затронет не только разделы с BitLocker'ом, а вообще все разделы, на > > которых не отработал ни один evms плагин. > > Мне кажется, не страшно пометить все неизвестное как unknown. Главное, чтобы > пользователь знал, что на этих партициях что-то есть. > Еще важно определиться, активировать для таких партиций в alterator-vm опцию > изменения точки монтирования или нет. Т.е. давать ли пользователю возможность > добавлять такие партиции в fstab на этапе установки... Насчет опции изменения точки монтирования - я не знаю. С одной стороны - пользователь сам может добавить нераспознанные партиции в fstab после установки. Вообще, evms умеет в самые распространенные типы ФС, и вряд ли среднестатистический пользователь в вакууме будет использовать что-то помимо них. С другой стороны именно по этой же причине можно и активировать опцию. Потому что вряд ли кто-то будет задавать точку монтирования, при этом совершенно не понимая, что оно делает. Ну а если и будет - то также бездумно можно и efi раздел снести и вообще что угодно. Никакое отключение опций не спасет.
+ task #242864
