Bug 37358

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