wiki/Btrfs

[Pilot6]

для каждой системы свой раздел со своей ФС. Я субтома не заказываю при установке, но они есть и неудобство с тем, что груб не видит тоже есть.

Буду иметь ввиду. У меня правда по одной системе на каждом компе. А что винду тоже не увидит? Дуалбут не поучается?

[thunderamur]

Pilot6, Винду увидит, как и другой Линукс, /boot которого не на Btrfs. Проблема только в том, что груб не находит соседние системы на Btrfs.

[Sly_tom_cat]

У GRUB-а довольно кривой драйвер btrfs.

Я пробовал драйвер для UEFI применить для загрузки ядра с BTRFS прямо из Boot Manager UEFI - так драйвер тупит со страшной силой и банально подвешивает UEFI Shell или саму UEFI... Я так и не смог с ним этот вариант загрузки настроить. А драйвера для UEFI - они на основе драйверов GRUB-а собраны.

С драйвером EXT2-4 все работает нормально.

[Sly_tom_cat]

Поставил себе на 18.04 пятое ядро и попробовал сделать своп на btrfs.

С первого раза не получилось. Вылезли некоторые, не совсем очевидные на первый взгляд, нюансы.

1. если пустой файл создавать через touch, то права на нем выставляются 644 (-rw-r--r--), а swapon требует для файла свопа прав 600 (-rw-------). Так что после touch надо еще chmod go-r <file> выполнить.

2. создавать файл с заданным размером для последующего mkswap надо не командой truncate, а через dd if=/dev/zero ... . Т.к. truncate создает sparse file и, хотя mkswap отрабатывает на нем без ошибок, swapon ругается на файл, что в нем дырки.

Внес в статью соответствующие правки.

А так пока пробую как этот своп работает. Пока никаких глюков не выявил, но продолжаю наблюдать.

[ALiEN]

не командой truncate

fallocate же

[Sly_tom_cat]

Да с fallocate покороче команда получатся и работает быстрее. Спасибо за уточнение - я просто не знал про fallocate.

ЗЫ век живи, век учись, и все равно дураком помирать

[Anuta]

В арч-вики вычитал, что опцию проверки fsck для btrfs в fstab нужно выставлять в 0 (не проверять) - насколько это верная информация (после установки стояли 1 и 2 для корня и /home соответственно)?

[The Green Side]

это верная информация, т.к. в btrfs своя команда проверки, проверка при монтировании ровным счётом ничего не даст и не покажет

[Sly_tom_cat]

Собственно в btrfs самые базовые проверки производятся в процессе монтирования. А все остальные утилиты это уже  восстановление после тех проблем которые уже и смонтироваться не дадут.

А fsck.btrfs проверяет только наличие раздела с fs, но в самой fs совсем ничего не проверят.

[AnrDaemon]

нужно выставлять

Эта опция имеет эффект только для ext2 и ещё парочки FS.
Для других она ровным счётом ничего не даёт и даже не обрабатывается.
Так что "нужно" это немного не то слово.

[Anuta]

Спасибо за пояснения по fsck.

Возник еще вопрос - по поводу восстановления из снимка.
Суть (команды по памяти, в данном случае это не критично):
1. Создан снимок корня через

Код: [Выделить]

btrfs sub snapshot / /home/root_bck2. Снимок отправлен на внешнее устройство, с другой ФС (NTFS), в виде файла:

Код: [Выделить]

btrfs sent -f /home/root_bck /mnt/ext_hdd4/root_bck, затем удалён через

Код: [Выделить]

btrfs sub delete /home/root_bck3. В корневую систему внесены изменения (установка софта)
4. Хочется вернуться к состоянию "до установки", первое действие:

Код: [Выделить]

btrfs receive -f /mnt/ext_hdd4/root_bck /home/root_bck - снимок появляется в списке подтомов (выполнение

Код: [Выделить]

btrfs sub list / выводит, в т.ч., и его).
А вот дальше - неясно. Попытки применить рецепт из вики (раздел "Использование снимков для создании точки отката") не приводят к успеху - загрузка с LiveCD, замена через

Код: [Выделить]

mv /mnt/home/root_bck /mnt/@ ни к чему не приводят (команда отрабатывает, система после перезагрузки в исходное состояние не возвращается). Попытки использовать

Код: [Выделить]

btrfs sub set-default ID /mnt для назначения

Код: [Выделить]

/mnt/home/root_bck в загрузку по умолчанию, проделанные с LiveCD, - тоже не помогают (он назначается, но состояние системы не меняется).
Неясно - на каком этапе и что делается не так? Куда копать?

[The Green Side]

UPD: неправильно понял проблему, поэтому мои размышления на тему (ниже) не актуальны

Хороший вопрос, мне тоже интересен ответ, столкнулся с этим какое-то время назад.
Я для себя сделал такой вывод - конфигурация с системой, расположенной в корне, некорректна.
Система и бэкапы должны быть расположены в разных подтомах.
В принципе, wiki это подтверждает

Решение без переустановки точно уже не помню, на свой страх и риск выполняйте, может перестать загружаться система
1) Сделать снимок рабочей системы в отдельном подтоме, например /@
2) Перенастроить grub в корне диска на загрузку системы с /@ (информация есть в wiki)
3) Пофиксить fstab в подтоме /@ с учётом переноса системы
4) Перезагрузиться, удостовериться, что вы загрузились в подтом /@

Протестировать, спустя какое-то время переименовать все папки в / кроме /boot, а затем и удалить.
Для этого можно просто смонтировать / куда угодно, например в /mnt/sda1-device/
Получается, конфиг GRUB будет в /boot, а система в /@
Возможно, переустановка лучше, чем такой "франкенштейн"
Как переместить конфиг GRUB в подтом @ и не сломать систему - я не выяснял, будет интересно узнать.

[ALiEN]

Anuta, в установленной системе как в fstab прописано?

Покажите

Код: [Выделить]

egrep -v '^$|^#' /etc/fstab
sudo btrfs subvolume list /

[The Green Side]

Получается, конфиг GRUB будет в /boot, а система в /@
Возможно, переустановка лучше, чем такой "франкенштейн"
Как переместить конфиг GRUB в подтом @ и не сломать систему - я не выяснял, будет интересно узнать.

Сам спросил, сам отвечаю 
1) переустановить GRUB на устройство, например, для BIOS и /dev/sda:

Код: [Выделить]

sudo grub-install --target=i386-pc /dev/sda2) обновить конфиг GRUB в подтоме /@
проверить, строка загрузки ядра должна содержать:

Код: [Выделить]

linux /@/boot/.... root=UUID=.... rootflags=subvol=@
3) перезагрузиться, переименовать старую папку в корне - /boot, перезагрузиться ещё раз, удалить её.

[Anuta]

в установленной системе как в fstab прописано?

Код: [Выделить]

UUID=B845-4CCC                            /boot/efi      vfat    umask=0077 0 2
UUID=cb7e85e0-f33d-4e9b-be6e-2f61ef786140 /              btrfs   subvol=@,defaults,ssd,noatime,space_cache,autodefrag 0 0
UUID=cb7e85e0-f33d-4e9b-be6e-2f61ef786140 /home          btrfs   subvol=@home,defaults,ssd,noatime,space_cache,autodefrag 0 0

Код: [Выделить]

ID 256 gen 55557 top level 5 path @
ID 258 gen 55557 top level 5 path @home
ID 324 gen 53933 top level 258 path @home/rootFSbackuprootFSbackup - это мой снимок, распакованный из файла с внешнего диска через btrfs receive -f. Возможно, проблема в том, что у rootFSbackup id родителя не 5?