У меня Магея7 betta1 работает. Может флэшка ? Если флэшка чудит, то задержки.
С режимом uird.home=home.img с моими компами и флэшками вообще беда. Тянет, потянет да вытянуть не может.
Так что флэшки у меня только для установки модулей при загрузке и для конфигов.
Можно ведь попробовать установку сборки на диск. Там флэшки нет. А в чистом режиме пробовали ?
А как вы ее готовили ? Я работаю на btrfs и разметка флэшки gpt
MGAREMIX это просто обновление LiveDVD от Магеи. Для полного функционирования uird+"magos-утилиты" нужны доп пакеты.
Какие мне сказать трудно.  Собрал на базе сборки Михаила и все работает.

Без kmod-devel uird  в Магее не собирается
Уж третий раз пишу об одном и том же

Которая сборка мне для экспериментов без разницы, если бы все они были на одном ядре можно было бы выкладывать ремиксы с уирд без сквоша, метров 100 наверное всего будет.

Uird собирается под конкретное ядро, так как в нем модули ядра. Загрузится или нет с другим ядром зависит от того,  что вкомпилено в ядро, более всего это касается дров фс.
А если сборки lxde, lxqt и т.д. на одном ядре делать, то можно менять только сам сквош, а не всю сборку. И выкладывать свои uird переделки я тоже могу без сквоша. После распаковки кладете любой сквош и все.
P.S. Сквош - 00-distrib-lzma.sqfs

Я не про сборки я про ядро. Если вы в ближайшее время все сборки будете делать на 4.20.6-3, то не нужно будет под каждую сборку менять ядро, уирд и инитрд. Менять надо будет только сквош. Для экспериментов так удобнее конечно.
Но если хотите остановиться вообще на одной сборке, то вопрос снят.

Да все норм.

На других двух стационарниках у меня тоже все ОК. Флешка нормальная. Это не задержки, это отвал клавы.

В чистом и работал. С сохранением тупит, но это с qcow2. img так и не проверил.

Профессионально За это не переживайте, с подготовкой все нормально.

В MgaRemix магос-утилиты не предусмотрены и для работы уирда ничего более не требуется. Для сборки да.

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

Ви-Фи пока не на чем проверить.
За то проверил с сохранением в img на родном initrd. Заргружается и выключается намного быстрее чем с qcow2, но все еще медленно. Я бы предпочел с сохранением в модуль.
Кстати, говоря, uird бы дал эту возможность, а также избавил от нежелательного отмонтирования флешки через проводник и решил проблему с отмонтированием при выключении.
И вопрос, как на родном initrd загрузиться в режим без сохранения, если в корне флешки лежит файл save.img?

Урра! Заработало!

Как говорится, на вкус и цвет товарищей нет... ))

Мне видится, что Lock можно поставить на лоток ЦД, т.е. игнорировать физическое нажатие на кнопку опять же ЦД. А здесь, по логике, нужно флешку прятать в проводнике, но тогда пользователь потеряет ориентир, на каком устройстве он находится. Честно говоря не вижу в этом проблемы, поскольку раз пользователь сделал себе флешку и видит её метку в проводнике, то зачем пилить сук на котором он сидит? Хотя, человеческий фактор непредсказуем. Человек может взять и случайно сделать rm -rf /. ))

По поводу отмонтирования флешки при выключении, кстати, мы с Вами так и не обсудили...
Без сохранения флешка отмонтируется чисто, т.е. костыль /usr/lib/systemd/system-shutdown/remount-run-exec.sh торчит в нужном месте и в теории делает своё дело. В теории - потому, что если в этот скрипт запихать проверочный код (скажем, вывод сообщения с ожиданием нажатия на батон) с целью убедиться в том, что при шотдауне он выполняется, мы либо не успеем это увидеть, либо удостоверимся в том, что он не исполняется. О том, что флешка отмонтируется без сохранения нормально, я сужу по тому, что мне не приходится выполнять её проверку по запросу в винде. ))

А вот грабли начинаются именно при использовании режима с сохранением. Монтирование save.img происходит на этапе начальной загрузки, т.е. в "поле деятельности" того ядра, которое находится на флешке в /boot. save.img монтируется как loop1. Перезагружаясь, если в системе присутствует файл /run/initramfs/.need_shutdown (а он присутствует в Live), выполняется /usr/lib/dracut-initramfs-restore, происходит распаковка СИСТЕМНОГО ядра (не того, что на флешке) и выполняется /usr/lib/dracut/modules.d/99shutdown. Вот в нём можно поставить ещё один костыль на ремонтирование loop1 в ридОнли. Но не в коня корм. Весь секс данной проблемы в том, что костылей быть не должно. Т.е. вообще не нужны эти костыли. Т.е. абсолютно. systemd должен сам корректно отмонтировать всё, что прикручено. Сейчас Вы возмущенно скажете: "Как же так. Так не бывает. Нужны записи в fstab. Нужно хотя бы сделать, как в EduMandriva mount -n -o ro,remount /dev/loop1 /live/tmpfs". А вот и нет. Перечитав кучу статей о процессе шотдауна пришёл к выводу, что всем занимается система и "помогать" ей что-то отмонтировать не нужно. Нужны аргументы? Справедливо. Берём Mageia-5 и без всяких костылей делаем initrd, а затем флешку с сохранением. Смотрим и видим, что всё монтируется/размонтируется, а проверку fsck перед монтированием save.img можно выкинуть вообще, ибо ext4.

В общем и целом пришёл к выводу, что этой проблемой должны заниматься специалисты из Магии, поскольку мне не хватает мозгов лезть в дебри того, как именно это работает сегодня и что именно изменится (а меняется постоянно) завтра. На сегодняшний день устоявшегося решения с отмонтированием лично у меня нет. Надеюсь, что Магия-6/7 вернёт стабильность размонтирования, которая была в Magea-5. Иными словами, я выбрал такую позицию: пока они не закроют заявленный ранее баг с размонтированием в целом, я не буду ничего костылить от себя. Костылить на данном этапе означает привнесение в уже существующую, бажную систему отмонтирования ещё и своих "грязных" нюансов. В результате общая картина может оказаться смазанной до неузнаваемости. С другой стороны, не приходится компостировать мозги ни себе ни людям, мужественно преодолевая неизведанные преграды из костылей, которые напихали другие, более продвинутые люди. В любом деле важна чистота эксперимента.

p.s. В порядке/смысле размонтирования/ре-монтирования могу ошибаться, поскольку дело было давно, половину уже и не помню. В реальном времени, по горячим следам со специалистами из Магии мне поработать не довелось (время реакции = полгода), да и других дел оказалось в достатке. Ведь это не главное в жизни. ))

Зажигалка "Zippo": есть бензин/нет бензина. Обычный пользователь не станет заморачиваться мифами о "непотопляемости" системы, ибо всё крутится вокруг надёжности чипа флешки: потрите флешку о штаны с начёсом и прикоснитесь к разъёму - чистый режим уже не работает. )) Возможность оперативно грузиться в чистом режиме или режиме с сохранением скорее тешит самолюбие разработчика, нежели имеет практическую ценность. Хотя, вот ingvaro например использует флешку с тем, чтобы на ней напортачить и потом ничего не переустанавливать (Игорь, это шутка). )) В ремиксе всё проще, намного проще.

Это вопрос то больше к AlexL.
В МагОС есть конфиг MagOS.ini
Там выбираешь время  какое надо. Оно и устанавливается при загрузке. Все  проще.
Поэтому я стараюсь uird запускать на стандартном конфиге MagOS  и на флэшке папки MagOS и MagOS-Data
Иначе придется большую часть скриптов переделывать.
Да и если  что то не стандартное, то кто  поможет с проблемами ?

Надо переходить на uird, там есть ini.
С vdi динамическим смотрели кто?

А какие проявления. На своей сборке тестирую виндовые компы, дома захожу и винда молчит.

Я досконально не разбирался с  тем как это сиситемд делает. Могу только свои предположения озвучить.
Системд ничего не знает о том, что у нас корень с ауфс и как он собран. Чтоб размонтировать носитель на котором лежат сквоши, нужно отключить сквоши, но у нас ауфс и некоторые из сквошей размонтировать нельзя потому что файлы из этих сквошей использует система, баш например или сам системд, раз сквоши не отключаются то и ауфс нельзя отключить. Максимум что можно сделать в этом случае перемонтировать в ro, у Михаила в магос вроде так и сделано.
Другое дело  /run/initramfs/shutdown, при наличии этого файла (и еще некоторых условиях) сиситемд чрутится в /run/initramfs таким образом освобождая старый root. Тут уже можно размонтировать все. Но. Этот скрипт создается модулем shutdown дракута, и он, как мне показалось, размонтирует больше чем системд, но тоже не все. В uird  в дополнение к нему создается еще один скрипт, который уже последовательно разбирает всю ауфс конструкцию созданную uird, в итоге размотируется все кроме /dev. То есть хук конкретно для Uird и перенести его как есть куда-то еще не получится. Если только делать по аналогии.