кусок системы в контейнере

Никак. Надо в chroot создавать новый корневой раздел. Можно скопипастить существующую систему...

Создать снимок в btrfs, установить gnome, откатиться при необходимости

Собери модуль поддержки aufs, далее создаёшь где-нибудь файловую систему, например на LVM томе, которая будет монтироваться посредством aufs в качестве контейнера для внесения изменений. В initramfs помещаешь модуль aufs и пишешь скрипт, который смонтирует твой корень, прочие файловые системы, затем смонтирует файловую систему - контейнер для сохранения изменений в неё куда-нибудь. Лучше, конечно, создать для каждой файловой системы отдельную файловую систему-контейнер.

Монтируешь вот такой командой:

usr     /usr    aufs     udba=reval,br:/mnt/usr/rw:/mnt/usr/ro  0 0

Вот команды для перемещения смонтированной файловой системы:

  mkdir -p /mnt/root/${i}
  mount -n --move /${i} /mnt/root/${i}

В итоге у тебя должно получиться следующее:
- Сценарий в initramfs монтирует файловые системы - контейнеры для сохранения изменений;
- далее посредством каскадного монтирования средствами aufs монтирует целевые файловые системы с указанием сохранения изменений на ранее смонтированные файловые системы;
- перемещаешь точки монтирования файловых системы;
- делаешь смену корня и загружаешь в системы;
- так же придётся отредактировать /etc/fstab, ну либо написать его генерацию всё в том же init сценарии, в любом случае изменённый /etc/fstab будет помещаться на aufs.

Удачи.

они смешивались

wtf, что за гсмные домыслы

С ZFS это можно сделать так:

1) снапшот;
2) клон от этого снапшота;
4) монтируем клон в отдельную директорию, чрутимся туда;
5) ставим GNOME;
6) отмонтируем клон, указываем его в качестве новой корневой ФС в загрузчике;
7) reboot.

Если понравится - promote клона до полноценной ФС, удаление старой ФС(которая теперь стала клоном) и снапшота. Если не понравилось - меняем корневую ФС обратно, reboot, удаляем снапшот и клон.

Я, когда ставил пятые кеды, 4-е положил в бинарные пакеты. Потом, когда откатывался, откатывался из бинарных пакетов. Получается быстро.

Если честно, мне тогда не очень понравился результат (уже и не помню почему), так что я себе запомнил использовать это средство с осторожностью. Но, как вариант. Особенно в твоем случае, когда в крайней можно всегда пересобрать с другими флагами.

прйти на сайт гнома и скачать live-cd, погонять и потом создать хейт-тред на ЛОРе против KDE или GNOME

Да

Чем btrfs не подходит?

При всем уважении к ZFS, долбиться с ней только ради этого считаю оверхедом времени и усилий.

за это, в том числе, мне и не нравится zfs - много лишних движений

Создай снапшот текущей системы, смонтируй его в корень (если без ребута это сделать реально, то размонтировать текущий корень не забудь, btrfs вроде как может монтировать снапшоты в одну точку), попраавь юзы, накати пакеты. Если понравится — снесёшь старый снапшот, если нет — новый; поправишь fstab, и всё.

Буду рад узнать если в Btrfs это делается быстрее - будет еще один повод взглянуть на неё

На деле там всё так же. Но от выхлопа 'btrfs --help' начинает рябить в глазах, где блок и фс смешаны в кучу, за счёт чего как раз и появляются лишние движения в виде уточнений для команды btrfs.

На деле там всё так же

лол, нет

1) делаешь снапшот

2) чрутишься в него

3) проводишь нужные манипуляции с emerge

4) правишь конфиги (загрузчик, fstab)

5) загружаешь том снапшота

чем мне нравится btrfs - в ней нет этих идиотских заморочек с клонами, нсапшотами и полноценными ФС, там одна сущность - том (subvolume), с которой обращаешься, почти как с обычным каталогом

лол, да
разница в том, что не надо создавать клон, но в zfs не надо править fstab. так что все твои потуги тщетны.

в zfs не надо править fstab

чего это?

все твои потуги тщетны

какие потуги?

чего это?

того это. вот и всплывает твой «опыт» использования

# cat /etc/fstab
/dev/mapper/vg_leevike-lv_root /                       ext4    defaults,noatime        1 1
UUID=a817447d-5f15-4152-83ef-ea6bc2b298c9 /boot                   ext4    defaults        1 2
/dev/mapper/vg_leevike-lv_swap swap                    swap    defaults        0 0
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
# zfs list
NAME                    USED  AVAIL  REFER  MOUNTPOINT
data               6,04T  1,78T  3,95T  /mnt/data
data/charging      1,53T  1,78T  1,53T  /mnt/data/charging
data/dhcp           107M  1,78T   107M  /mnt/data/dhcp
data/dsl-dhcp-log    30K  1,78T    30K  /mnt/data/dsl-dhcp-log
data/srv-csc-adal    30K  1,78T    30K  /mnt/data/srv-csc-adal
data/tbms          42,3G  1,78T  42,3G  /mnt/data/tbms

того это

да, я забыл, что у zfs свои костыли для монтирования, но в Линуксе использовать их - моветон (впрочем, как и саму zfs)

потуги доказать, что управление zfs сложнее, чем btrfs

только при чём тут концепция объектов ФС к способам их монтирования? аргументация как у девочки

так-то для создания rw-снапшота в zfs реально требуется больше движений

поведение zfs точно соответствует определению snapshot, в отличии от. это у тебя аргументация на уровне ребёнка - надо же ещё клон со снапшота сделать, что бы его изменять, лишнюю команду набрать. вот и приходтся под тебя подстраиваться.

это у тебя аргументация на уровне ребёнка - надо же ещё клон со снапшота сделать, что бы его изменять, лишнюю команду набрать

чот я не понял твоего фонтана в этой теме

создание rw-снапшотов в zfs требует больше движений? как видно - да

концепция объектов ФС в zfs более сложная, чем в btrfs? опять же, да

с чем ты споришь тут? такое ощущение, что тебе просто АБЫДНА, что я фыркнул в сторону твоей священной zfs

а потом zfs-фанбои с пеной у рта уверяют, что они не фанбои -))

поведение zfs точно соответствует определению snapshot

снапшот это снимок состояния ФС, не больше, не меньше, и где в его определении значится, что rw-снапшоты непременно нужно делать с ro-снапшотов? а нигде, лол, это просто авторы zfs немного неадекваты

создание rw-снапшотов в zfs требует больше движений? как видно - да

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

концепция объектов ФС в zfs более сложная, чем в btrfs? опять же, да

ещё раз, для тех, кто совсем не владеет концепциями хранения данных, снапшот - это консистентный срез состояния файловой системы для бэкапа или создания клона, если ты хочешь проводить над ним манипуляции.

с чем ты споришь тут? такое ощущение, что тебе просто АБЫДНА, что я фыркнул в сторону твоей священной zfs

да мне насрать, в общем-то, на мнение таких знатоков, а вот другие могут и повестись на ваши бредни.

там то на то и выходит

в zfs для создания rw-тома нужно сделать снапшот и клон с него, в btrfs - просто снапшот

где тут «то на то и выходит»? счёт до десяти проходят в садике, если что

снапшот - это консистентный срез состояния файловой системы для бэкапа или создания клона, если ты хочешь проводить над ним манипуляции

чего это ты тут феерической отсебятины нагородил? определение снапшота вот: «In computer systems, a snapshot is the state of a system at a particular point in time». И всё.

да мне насрать

да я вижу, как zfs-фанбоям насрать - бегают по всем btrfs-тредам и заводят свои феерические проповеди, лол

не говоря уж о том, что проповеди фанбоев из zfs-вселенной как раз и выглядят как лживые, донельзя передёрнутые бредни

в btrfs - просто снапшот

не забудь поправить fstab

особенно если снапшот не нужно монтировать

особенно на фоне вот этого веселья:

promote клона до полноценной ФС, удаление старой ФС(которая теперь стала клоном) и снапшота

уахаха, гениальная ФС!

создание rw-снапшотов в zfs требует больше движений? как видно - да

Снапшот от снапшота в btrfs создать можно?

сколько угодно

Тогда действительно удобно.

Мне и в ZFS устраивает вся логика, она позволяет чётко разделять сущности, что в продакшене бывает необходимо. Но на десктопе для экспериментов хочется держать скрипты покомпактнее, хотя по большому счету это мой извращенный перфекционизм - двумя строчками больше, двумя меньше - какая разница?

она позволяет чётко разделять сущности

непонятен смысл этого разделения

приведи какой-нибудь пример из продакшена?

С продакшена сейчас выжимку сделать не могу, там хитрая конструкция, вот тебе мой домашний пример.

Том с свежераспакованным stage3+набор утилит разработчика->снапшот->куча клонов от этого снапшота, в каждом установлен определенный набор ПО(в одном gtk,в другом qt,в третьем - boost и т.д.)->по снапшоту на каждый клон, чтоб было куда его откатывать

В результате имеем снапшот основного тома(например с датой), от которой наследуем клонов. Как только обновляем основной том, можно делать новый снапшот с датой и начинать делать клоны уже от него. Как только последний клон переедет на новый снапшот - старый удаляем.

конечно так можно делать, но зачем это делать обязательным, как в zfs?

я, например, делаю так: rw-снапшот от текущего корня, его обновление, перезагрузка на него в качестве корня, и мне снапшоты в принципе не нужны, но zfs вынуждает их почему-то делать

f то, как ты описал, можно делать в btrfs точно так же

концепция объектов ФС в zfs более сложная, чем в btrfs? опять же, да

Ну если ты тут вещаешь про rw-снапшоты в бтрфс, то, стало быть, есть и ro-снапшоты? Получается, что принципиальной разницы-то и нет. А за каким хером надо было вместо устоявшейся терминологии придумывать новую? NIH-синдром? Или попытка от потенциальных преследований нетапа подстраховаться в духе «что вы, что вы, у нас никаких ваших патентованных снапшотов и клонов нет, у нас одни только субвольюмы и ничего больше»?

Ну и если ты настаиваешь, что в бтрфс все просто, потому как кроме субвольюмы других концепций нет, то в ZFS тоже одни только датасеты, между которыми существуют разнообразные взаимоотношения.

создание rw-снапшотов в zfs требует больше движений? как видно - да

В ZFS, если уж на то пошло, никаких rw-снапшотов нет, так что посылка у тебя ложная. Если тебя так напрягает создание клонов в ZFS в два этапа - сначала zfs snapshot, потом zfs clone, - то никто тебе не мешает реализовать поддержку создания клона в одну команду. Можешь скрипт написать, можешь прям в коде поправить - opensource жеж.

promote клона до полноценной ФС, удаление старой ФС(которая теперь стала клоном) и снапшота

Клон ничуть не менее полноценен, чем любая другая файловая система или том. Операция promote меняет лишь характер отношения между клоном и его источником.

С ZFS это можно сделать так:

А с ZFS в соляре все еще проще делается - там для управления загрузочным средами команда beadm есть, так что ленивой Алисе не пришлось бы страдать от необходимости создания сначала снапшота, а потом клона

чего это ты тут феерической отсебятины нагородил? определение снапшота вот: «In computer systems, a snapshot is the state of a system at a particular point in time». И всё.

Таким образом, согласно этому определению, rw-снапшот в бтрфс никаким снапшотов не является. Гениально, что уж там!

Чего только люди не придумывают, лишь бы beadm не пользоваться :)

Получается, что принципиальной разницы-то и нет

есть: rw-снапшот в btrfs не требует ro-снапшот для создания

А за каким хером надо было вместо устоявшейся терминологии придумывать новую?

потому что терминология zfs нужна и работает только в zfs

в ZFS тоже одни только датасеты

а толку-то?

В ZFS, если уж на то пошло, никаких rw-снапшотов нет, так что посылка у тебя ложная

утибоземой, буквоедик

никто тебе не мешает реализовать поддержку создания клона в одну команду

я просто выбрал решение получше - btrfs

да не, является - в поеределении не сказано, что этот state должен оставаться неизменным

Тогда поведай нам, темным, на какой момент времени это состояние?

Получается, что принципиальной разницы-то и нет

есть: rw-снапшот в btrfs не требует ro-снапшот для создания

Кто о чем, а вшивый о бане. Речь-то про наличие или отсутствие определенного набора концепций, а не про то, сколько и каких команд требуется.

потому что терминология zfs нужна и работает только в zfs

Понедельник, конечно, день тяжелый. Но настолько...

я просто выбрал решение получше - btrfs

Ну так потрудись быть объективным и спокойно обсуждать достоинства и недостатки выбранного тобою решения. А то ведешь себя как маленькая Алиса :)

очевидно, что на момент создания снимка

Речь-то про наличие или отсутствие определенного набора концепций, а не про то, сколько и каких команд требуется.

речь заводил я и была она про странные отношения между этими вашими датасетами

Ну то есть стоит чуть измениться и это уже не снимок. Как-то тогда некрасиво с rw-snapshot'ами получается :)

речь заводил я и была она про странные отношения между этими вашими датасетами

Вот ты и начал спрыгивать. Отношения между этими нашими датасетами ничуть не страннее отношения между этими вашими субвольюмами.

Так что все твои претензии - это, по сути, вкусовщина, а на вкус и цвет, как известно, товарища нет.

почему не снимок? снимок, но уже на текущий момент времени

можно назвать это статическими и динамическими снапшотами

Отношения между этими нашими датасетами ничуть не страннее отношения между этими вашими субвольюмами.

видишь ли, между томами btrfs отношения анархические - дерево снимков может строиться как угодно, в zfs же выбрана одна модель с клонами и снапшотами

т.е. в btrfs можно делать как в zfs, а наоборот - не получится

почему не снимок? снимок, но уже на текущий момент времени

Какая ты гуттаперчевая, Алиса! А куда делся тот, изначальный, который был в предыдущий момент времени? Как к нему обратиться? Этак получается что у тебя и FAT12 снапшоты поддерживает :)

А куда делся тот, изначальный, который был в предыдущий момент времени? Как к нему обратиться?

если тебе нужен неизменный снимок - делай его с ключом -r

видишь ли, между томами btrfs отношения анархические - дерево снимков может строиться как угодно, в zfs же выбрана одна модель с клонами и снапшотами

При всей анархичности отношения между ними вполне определенные, и разницы принципиальной нет. Есть разница в синтаксическом сахаре. Тебе больше нравится всегда создавать клоны (rw-снапшоты странноватой терминологии бтрфс), но это до тех пор, пока тебе не понадобится send/receive, и тут резко выяснится что для него - сюрприз!!! - нужно, чтобы снапшот был readonly :)

если тебе нужен неизменный снимок - делай его с ключом -r

получается, что без ключа -r это никакой не снимок :)