Устройства из рейда BTRFS отображаюстя как отдельные тома в Nautilus

Добрый день!
Столкнулся с одной досадной неприятностью: у меня на ноутбуке 2 ssd, которые я объединяю в рейд btrfs. Так как Calamares не дает создать подобную конфигурацию дисков при установке, я провожу установку на один диск, а после установки добавляю к тому btrfs второй диск.
И после этого в разделе “Другие места” Nautilus второй диск начианает отображаться как независимый том.
На данный момент я решил проблему через скрытие тома правилом udev, просто обратил внимание на то, что диски из состава рейда “вылазят” как отдельные устройства не везде, например в Arch и Fedora я такой “фишки” не наблюдал - добавленный к тому btrfs диск не отображался в Nautilus, но зато аналогичное поведение наблюдается помимо Endeavouros, в Manjaro и Garuda - пока из общего между ними только одно - установщик Calamares.
Сталкивался ли еще кто-то с подобной проблемой?

Translation:
(Перевод:)

Good afternoon!
I ran into one annoying trouble: I have 2 ssd on my laptop, which I combine in a raid btrfs. Since Calamares doesn’t let me create this kind of disk configuration during the installation, I do the installation on one disk, and after the installation I add the second disk to that btrfs.
And after that in the “Other places” section of Nautilus the second disk starts to show up as an independent volume.
At the moment I decided the problem by hiding the volume as a udev rule, just noticed that the drives from the raid “appear” as separate devices not everywhere, for example in Arch and Fedora, I have not seen such a “thing” - the disk added to the btrfs volume not visible in Nautilus, but the same behavior is observed in addition to Endeavouros, in Manjaro and Garuda - so far from the common between them only one - the installer Calamares.
Has anyone else encountered this problem?

Install arch linux on btrfs raid1

(Установка arch linux на btrfs raid1)

Итак, я разобрался в проблеме: всему виной, как я и преполагал, оказался Calamares.
И да, я забыл упомянуть о том, что я испольую шифрование luks, причем не полное (нешифрованный /boot) - опять же исключительно для красоты - ну вот не навиться мне лицезезреть черную консольку при вводе пароля, да и plymouth позволяет вывести приглашение для ввода пароля на внешние мониторы, что опять же удобно, когда ноутбук большую часть времени используется ка системный блок :wink:
А теперь подробнее:
Суть проблемы в том, что для тогго чтобы убрать устройство из списка “Другие места” нужно это устройство либо скрыть либо куда-то смонтировать. В противном случае оно будет висеть как внешнее устройство, доступное для монтирования.
Поэтому у нас есть 2 пути решения проблемы:

  1. Скрыть данное устройство правилом udev.

Создаем файл правил, например /etc/udev/rules.d/99-hide-disks.rules со следующим содержимым:

ENV{ID_FS_UUID}=="<UUID>",ENV{UDISKS_IGNORE}="1"
#UUID берем из вывода blkid 

далее выполняем

sudo udevadm control --reload-rules
sudo udevadm trigger

И устройство пропадает из списка доступных к монтированию.
Добавляем записи в этот файл по мере добавления устройств в рейд.

  1. Смонтировать данный том.

И это в свою очередь делиться еще на 2 варианта:
Простой - смонтировать “куда-нибудь, где никто не найдет”: добавляем в /etc/fstab строчку
UUID=<UUID> /tmp/noexist

Правильный - выправить косяки Calamares:
Дело в том, что поумолчанию Сalamares, в случае использования шифрования luks, создает записи в /etc/fstab в формате /dev/mapper/luks-<cryptolvid>
С одной стороны это обосновано - id криптоконтейнера уже не поменяется в процессе работы ОС, поэтому можно прописать точку монтирования используя соотвествующий файл блочного устройства, вместо UUID, но в этом и заключается наша проблема.
Кога мы добавляем устройство в рейд btrfs не нем создается том btrfs с тем же UUID, что и “изначальный” том, тем самым, если если устанановщик правильно формирует fstab и grub.conf, то мы не наблюдаем подобной проблемы, так как если точки монтирования в fstab прописаны с использованием UUID, то все наши тома из состава рейда (а UUID у них одинаковый) - формально уже смонтированны в одну точку (именно поэтому я и не наблюдал данной проблемы в Arch и Fedora).
Ну а теперь как это исправить:
Первым делом определяем UUID тома в контейнере luks (опять же blkid нам в этом поможет).
Далее редактируем /etc/fstab, заменяя упоминание болчных устройств /dev/mapper/luks-* на UUID. В итогедолжно получиться что-то наподобие:

#/dev/mapper/luks-44e4532a-8c05-4f2e-bee3-8676a5253713
UUID=a94f751b-70b2-4064-b9d3-8cdeabc5714d  /              btrfs   subvol=/@,defaults,noatime,compress=zstd 0 0

И такую манипуляцию проводим для записи каждого btrfs subvolume.
Но это еще не все, нам потребуется отредактировать /etc/default/grub
Изменив следующие параметры:

GRUB_CMDLINE_LINUX="cryptdevice=UUID=<UUID>:luks-<cryptolvid> rootfstype=btrfs"

Если у вас параметр cryptdevice= прописан в строке GRUB_CMDLINE_LINUX_DEFAULT, то можно поменять прямо там. Выносить в отдельную строку не обязательно.
UUID=<UUID> - меняем на UUID вашего зашифрованного тома, а
luks-<cryptolvid> на id вашего контрейнера luks (был указан в fstab)

И раскомментируем еще одну строчку, включив загрузку с зашифрованных устройств:

# Uncomment to enable booting from LUKS encrypted devices
GRUB_ENABLE_CRYPTODISK=y

Ну а далее не забываем обновить конфиг grub grub-mkconfig -o /boot/grub/grub.cfg
и можем перезагружаться.
Если все сделали правильно, то “лишние” устройства из состава рейда btrfs пропадут из “Другие места”.
Было бы неплохо “научить” Сalamares сразу генерировать “правильные” конфиги, но это случиться, по всей видимости, не скоро… А до тех пор можно пользоваться данным гайдом. :blush:

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.