Linux, в моей сборке работает, на BtrFS, раньше собирал на ReiserFS, пробовал Ext4  и c флэшками все ок !
При сохранении сис-изменений на флэшку пагубно отразятся на здоровье носителя и быстрее убьют флешку незавершенные операции, которых при работе с флэшкой хватает и без журналирования.
А  журналирование это все те же сис-изменения, которые надо сохранять.
У себя развел сервисы на выключение, все что примонтировано на флэшку штатно отмонтируется.
И ни одна флэшка за два года не "умерла"
В МагОС уже пилят сохранение сис-изменений непосредственно из UIRD минуя операционку.

Только FAT32 надо использовать только для хранения образов. Скрипты,  использование меток исключаются.
А может и еще что то. Сильно не вникал.

Не знаю почему, но сохранение изменений   в файл.img я что то сразу не возлюбил. Даже ни разу не запускал и мало чем могу помочь.
Может конечно зря ?
Так  мне сохранения в xzm-модуль  более чем достаточно.

vdi, сохранение в vdi интересно как вариант.
С uird возни много, а надо чтобы скрипт запустить и сам создался.

Uird собирается также как дракут, запуском скрипта. А для упрощения надо просто доделать rpm. Прототип уже есть.

alex_q_2000, почему compton из Федоры?

Размер уменьшается/увеличивается? Ускоряется/замедляется?

betcher, понял, я подумал вам надо внести изменения в пакет с именем rpm, а вы о пакете rpm с именем uird.

Согласен.

По поводу ускорения не думаю, что будет быстрее. Скорее наоборот.
Из плюсов возможность грузить как на реальном железе так и в виртуалке один и тот же  vdi. Потом кроме vdi есть и другие образы, которые поддерживает qemu-nbd, вроде есть что-то со сжатием, не проверял. Ну и возможность иметь ось из трех файлов - vmlinuz, uird, OS.vdi

Ребят, заранее скажу, что уважаю труд каждого из Вас, поэтому прошу отнестись с пониманием к написанному ниже. Я не преследую цель кого-то критиковать, наставлять, чему-то поучать и т.д. Просто излагаю свою точку зрения, которую считаю объективной...

Принцип бритвы Оккама: "Из множества решений, истинно верным является самое простое из них"

Господа, основная фишка всего нашего "болген-билдерства" состоит в создании сисмодуля и флешечного, специфичного загрузчика. В моём случае выбрана FAT32 из соображений:
---
а) Совместимость с Windows, Важность = 50% (Этот вопрос наиглавнейший, линуксоидам он безразличен и это понятно)
б) Отсутствие журналирования, скорость, повсеместное использование, Важность = 25%
в) Поддержка UEFI, Важность = 25% (дробить флешку на разделы не нужно)

Настоятельно предлагаю зафиксировать то, что уже работает в обеих ОС (Win/Lin) и принцип этот пока не трогать, тем более, что AlexL подтвердил его законность - это тоже важно. Изготовление разношерстных загрузчиков, множественное дробление флешек на разделы, другие ФС + UEFI - это уже за рамками выбранной концепции.

Мне непонятно, зачем рассматривать бедную флешку, как жесткий диск? Пожалейте ваши деньги и время. Пожалейте начинающих линуксоидов. Не морочьте им голову разделами, MBR, GPT, GParted и прочей "ерундой". Как вы думаете, будут они корёжить флешку ради сомнительного удовольствия загрузить систему из ультрамодного VDI? Конечно нет. Пройдут мимо и загрузят себе Ubuntu или ещё что. Это факт, будьте реалистами.

Хочу напомнить, что для MgaRemix-6 были созданы в том числе и графические инсталляторы на флешку с учетом всех файловых систем. Нужность сего мероприятия - нулевая. Не-ну-жно это: для начинающих - непонятно, а более-менее опытный ознакомится с системой на виртуалке и поставит её из сети.

ingvaro, betcher
Ребят, честно, я ничего против UIRD не имею. Даже после того, как он мне чуть BIOS не взорвал. )) betcher, с ingvaro у нас и так полный контакт, взаимопонимание и сотрудничество. Не пойму я никак, в чём состоит объединение, если мы и так тут, как "бычки в томате"? )))

Игорь изначально нашёл для себя более удобным править скрипты от МагОС и создавать сисмодуль из пакетов, опять же через МагОС-овские утилиты. Если я что-то путаю, прошу не обижаться, поскольку досконально его технология мне неизвестна. Ещё мне видится не совсем рациональным следить за каждым изменением в МагОС и немедленно увязывать их с Магией. Вся эта возня с выгрузкой каких-то скриптов в систему - ловля волшебных хуков. Зачем скрещивать UIRD с системой так тесно? Котлеты должны быть отдельно. И потом... Это уже обсуждалось конечно... Выгрузка результатов работы из памяти на носитель (в модуль, в образ, в папку - неважно) по факту shutdown-а? Ну это как то, даже не знаю, как сказать?!? Пожалуй, этот момент лучше обсудить с сисадминами, которые однажды сделают бэкап в память, а потом у них отключат питание. Подарите XliN-у такую флешку, чтобы расширить лексикон матерных и других высокохудожественных классификаций. ))

Сохранение в vdi? А быстродействие? А компрессия после раздутия? Вы же понимаете, что забить нулями свободное пространство в контексте vdi недостаточно, поскольку после этого его придётся дополнительно сжимать извне в размонтированном виде (VBoxManage)? Таким образом ОБСЛУЖИВАНИЕ VDI превратиться в брачный ритуал, при котором на завершение работы в системе тратится времени больше, чем на создание флешки. Как Вы уже заметили, img отщипнул себе кусок в любой фс и всегда одинаковой длины: скорость работы приличная, дефрагментация на уровне файловой системы. Никаких там компрессий/декомпрессий, подключения экзотических модулей для монтирования, т.е. прямая работа чтение/запись. А заполнение в реальном времени покажет маленький индикатор в системе. Вот собственно и всё: простота, скорость, надёжность. Сохранение результатов работы в памяти, читай в воздухе - это абсолютное зло. Вы получаете быстродействие в ущерб надёжности и простоты. Вы усложняете конструкцию, создавая видимость быстрой работы, а теперь мучаетесь вопросом "как бы всё это побыстрее ужать и сохранить". Господа, чудес не бывает и Вам придётся выбирать: либо надёжность и простота img, либо скорость и красивая обёртка VDI с тяжелым пост-обслуживанием. Скоростей на флешке за 100 рублей вы не получите ни с DVI ни с IMG. USB3 решит проблему скоростей, но не решит проблему обслуживания VDI.

Предлагаете использовать UIRD вместо initrd, а значит создавать тот же initrd для UIRD? Уже было, я Вам адрес давал для ознакомления (к betcher). Всё прекрасно работает до Mageia-5. Увы, но сага об универсальности не актуальна, это уже обсуждалось. Да, UIRD вполне самостоятельная и в чём-то универсальная вещь, в чём-то. И да, он гибок, привносит массу удобств и т.д. Спору нет. Начинающий будет этим заниматься? Ответ Вам известен.

Повторюсь, мне было важно чем-то финализировать сделанное. Поэтому, субъективно, выработал этот вариант. Будет ли он расширяем/изменяем/заменяем? Конечно да и здесь полная свобода действий для всех и каждого желающего. Это же линукс.

Повторю ещё раз этот замечательный постулат: "Из множества решений, истинно верным является самое простое из них."

XliN-у (абстрактно) 99% не нужно, ему нужно 100% и чтобы не париться. Поэтому он возьмёт любой Mageia-ISO и поставит образ на флешку. С XliN-ом на админском поприще шутки плохи. ))

Я хотел бы ещё добавить насчёт размера нашего "абстрактного" файла для сохранения и что именно мы собираемся хранить...

Мы уже приняли тот факт, что пользователь сам себе готовит флешку с нужным набором софта. Вот он по-максимуму поставил всё, что ему может понадобиться, оформил как надо и сжал в sqfs. Сделал себе MgaRemix на обычной флешке, грузится и работает БЕЗ сохранения. Приспичило ему клип скачать из сети. Отлично! Создаёт на флешке папку и накачивает туда до тех пор, пока флешка не лопнет. Потом он поработал в редакторе, создал файл и то же его в эту папку на флешке сохранил. Отредактировал фотку, тоже туда. Всё его добро мирно себе лежит в папке, которая находится за пределами системы, как таковой. Всё из этой папки прекрасно открывается, редактируется, сохраняется - проверено. Повторюсь, в данном случае мы будем использовать флешку по-максимуму, пока она физически не забьётся. Я к тому, что сохранение в IMG на флешке следует рассматривать в контексте НАСТРОЕК СИСТЕМЫ или если требуется что-то доустановить или нужны атрибуты. Это мизер, поскольку, возвращаясь к первому эпизоду пользователь сам себе, предварительно создал нужный образ с системой и необходимым набором софта. Максимальный размер для системных изменений (save.img) у FAT32 = 4Gb. В 4 гига, с учетом вышеперечисленного, можно чёрта лысого уписать. ))

Вывод: чем больше вещей будет учтено на этапе сборки сисмодуля, тем меньше необходимость в использовании сохранения вообще. Следует учитывать основное пространство флешки, а не ограничиваться размерами IMG, модулей или ещё чего-либо. Систему для того и запихиваем в автономный контейнер (sqfs), чтобы иметь в распоряжении всё доступное пространство самой флешки.

В UIRD например необязательно на флэшке хранить.
Зайти с опциями  uird.mode=changes uird.changes=/dev/sda7
И на разделе диска /dev/sda7 будут храниться изменения.
На счет initrd и файл.img мне трудно судить. Т к особо  не работал

Можно ведь динамический файл.img сделать. По мере заполнения у него будет расти и размер
Но смысл то. Все равно все пишется в save.img и больше размера флэшки не запишешь.
Вот если бы все куда то в облако писать. Инет сейчас дешевый.

Речь не о том, чтобы заменить технологию, её продолжить развивать, а сделать ещё один вариант посерьёзнее. Для этого нужна именно линуксовая fs, сохранение в папку без сжатия или в сжатый расширяемый образ.
4 гига это ни о чём, только для мелочёвки.
Я согласен, что сага про универсальность uird всего лишь сага, на деле универсальности нет, но betcher сделает версию uird для Магеи, надеюсь, будет и впредь её поддерживать, потому что никому не нужно отсутствие поддержки от разработчиков. А в таком случае имеет смысл сделать такую сборку. И uird улучшится, и у ingvaro улучшится. Всем только польза.
Телодвижения с твоей стороны минимальны. Образ vdi уже есть, только плюхнуть uird, который обещают упростить. И считай ещё одна сборка готова именно линуксовая. Под винду годится та, что есть, но под линукс добавить ещё одну версию на uird и lxde.
И не надо бояться, что окажется не очень с vdi, улучшим, попробуем, заценим.
Только в конкуренции сборок рождается лучшая. Поэтому, вперёд и с песней.