Форум проекта PuppyRus Linux
Дистрибутивы проекта PuppyRus Linux => Сборки Linux от пользователей => MiniOS - модульный debian RU frugal => Тема начата: sfs от 04 Август 2022, 15:44:51
-
Ознакомился с initrd slax-minios.
Очень не понравился
1. Даже noload load нет
2. Модули ядра грузятся по списку, без udev. Т.е. загружается куча лишнего для вашего железа
В доке
perch Активировать функцию постоянных изменений (https://github.com/minios-linux/minios-live/wiki/Параметры-командной-строки-(чит-коды)).
Видимо гуглом перевели. Пока не прочитал
perch Activate Persistent Changes feature
не понял что это сохраненка :)
https://www.slax.org/starting.php
При запуске с носителя только для чтения, такого как CD/DVD, Slax сохраняет все системные изменения только в памяти, и вы теряете их при перезагрузке. Если вы запускаете Slax с носителя с возможностью записи, например, с USB-накопителя, то все изменения, внесенные вами в саму операционную систему, сохраняются и восстанавливаются при следующей загрузке. Если ваше устройство использует файловую систему FAT, которая чаще всего встречается на USB-накопителях, то все файловые изменения самого Slax сохраняются в специальный файл changes.dat, который создается на вашем загрузочном устройстве в каталоге /slax/changes/ и автоматически увеличивается в размере до 4 ГБ.
Если ваше загрузочное устройство использует собственную файловую систему Linux, например ext4, то измененные файлы сохраняются в директорию /slax/changes/ без промежуточного файла changes.dat.
Если вам по какой-либо причине не нравятся постоянные изменения, просто выберите другую опцию в меню загрузки, и ваш Slax начнет использовать "свежую" конфигурацию по умолчанию и не будет сохранять никаких изменений. Это может быть полезно в случаях, когда вы хотите протестировать что-то в масштабах всей системы, поскольку вы всегда можете вернуться к состоянию по умолчанию простой перезагрузкой (если что-то пойдет не так).
Т.е. сохраненки в модуль нет и вообще никакую сохраненку не сделать ReadOnly ? Т.е. неубиваемости нет :'(
Юзер пересобрать его как-то может ? например под другое ядро? Т.е. есть система пересборки?
Чем он Вас привлек? Самый не функциональный из тех, что я видел. Хуже только в puppy-woof
Не думали поменять?
-
1. Даже noload нет
В обычном slax 9 есть noload.
А minios разве нет ?
-
noload load
перепутал
-
Юзер пересобрать его как-то может ? например под другое ядро? Т.е. есть система пересборки?
Чем он Вас привлек? Самый не функциональный из тех, что я видел. Хуже только в puppy-woof
Не думали поменять?
Это уже обсудили в телеге. Менять будем, но нескоро, так как надо в новый initrd дописывать текущий функционал миниоси, такой как включение/отключение служб systemd, изменение пароля пользователя и рута, выбор под кем грузить систему (пользователь или рут), установку ключа ssh...
-
так как надо в новый initrd дописывать текущий функционал миниоси
UIRD - Unified Init Ram Disk system (https://github.com/neobht/uird#uird---unified-init-ram-disk-system)
Вот не понятно, что все так избегают готовых решений, тем более это русскоязычные авторы, написавшие продукт с нуля, можно сказать импортозамещение. :)
Что sfs предпочел писать свой initrd-raf2, что другие. А потом все удивляются, что нет никакой унификации - куча линукс-дистрибутивов, еще больше приложений выполняющих одни и те же функции... )
-
включение/отключение служб systemd, изменение пароля пользователя и рута, выбор под кем грузить систему (пользователь или рут), установку ключа ssh...
А разве это не сделать уже в загружаемой системе, т.е. после инитрд?
Как минимум дебажить будет проще и можно юзать любой инитрд.
Менять будем
В спорах с Дядей Шуриком мне не удалось пропихнуть систему сборки инитрд и юдев. Из за его упрямости, а не весомых аргументов. В МиниОс разрабы адекватнее
Рассматривали варианты :
liveboot - родной для дебиана. Есть persistence. Нужно добавить только многомодульность (а может и это есть - давно не юзал.)
dracut - по опыту нашего форума уже несколько раз выручал, когда rootaufs и porteus не вывозили
Есть во всех линуксах
UIRD - когда я озадачился идеей заморозки ФУЛЛ - его и хотел применить. Там это уже было. Но тогда не было примеров и сам не разобрался, а авторы мне долго не отвечали. Мне не терпелось - в итоге rootaufs2
Можно пока перейти на UIRD (что я и сделал в своем варианте LF-minios)
А вообще я до сих пор считаю UIRD сложным и перегруженным. Без конкретных предъяв. Просто личные ощущения.
А совсем уж хорошо - как у меня в ПРАР - несколько инитрд - выбирай что хочешь. UIRD естественно присутствует с конфигами от соавтора
-
Вот не понятно, что все так избегают готовых решений, тем более это русскоязычные авторы, написавшие продукт с нуля, можно сказать импортозамещение.
Любое готовое решение плохо тем, что оно неготовое)) Я не готов отказаться от того функционала, что уже есть в миниоси, так как использую его в работе (удобно же, когда система грузится в ОЗУ с учётными данными, отличными от стандартных).
-
А разве это не сделать уже в загружаемой системе, т.е. после инитрд?
Как установить сервисы, которые должны выполняться на самом старте системы, в системе, которая уже грузится вовсю? Я пока не нашёл способ для этого. В любом случае, настройка системы из initrd намного надёжнее, чем вешать сервис, который может внезапно не отработать. Но я подумаю, как можно это реализовать.
-
Как установить сервисы, которые должны выполняться на самом старте системы, в системе, которая уже грузится вовсю?
Задача инитрд - собрать из модулей корень / и запустить в нем systemd. Все остальное делать сервисами системд. Такое дебажится стандартными средствами. Если это в инитрд - надо писать какиме-то свои логи и т.п.В любом случае, настройка системы из initrd намного надёжнее, чем вешать сервис, который может внезапно не отработать
Если скрипт кривой - одинаково криво отработает везде и наоборотМодули собирались относительно 04-gui-base, что позволяет их использовать без модулей с xfce.
и собрать модули других ДЕ, не сломав зависимости модули софта
-
Задача инитрд - собрать из модулей корень / и запустить в нем systemd. Все остальное делать сервисами системд. Такое дебажится стандартными средствами. Если это в инитрд - надо писать какиме-то свои логи и т.п.
Не только. initrd выполняет подготовку перед переключением корня. В случае миниоси, невозможно без дополнительного кода в initrd указать, какие сервисы systemd должны стартовать в системе, которая грузится в чистом режиме или в ОЗУ. Со старыми подсистемами инициализации было проще, можно было встроить подобный функционал непосредственно в главный скрипт загрузки системы. Помимо этого, в миниоси issue.net динамический. Зависит от того, что скрипт читает в файле конфигурации и настроек, указанных в конфиге на флешке, либо в /proc/cmdline. Теоретически, можно этот функционал переложить на начальные стадии загрузки, но вот указания на запуск определённых сервисов в другом сервисе указать не получится, либо это потребует редакции оригинальных сервисов, что трудоёмко и сломается при обновлении пакетов.
-
Сложность uird это цена за универсальность. По этому лоад, нолоад это не прибитые гвоздями имена папок, а фильтры. По этому все, что монтируется может быть источником для поиска слоев, по этому слой это не конкретно сквош, а также как с источниками - все что монтируется.У нас нет управления сервисами системд, но есть обработка ини, где можно делать вообще что угодно до старта системд.
Такой подход позвлляет с уирд делать вещи, которые не были запланированы просто играя параметрами. Так я впервые загрузил уирдом обычную установленную на диск росу, просто параметры подобрал и все. Вчера с Ильфатом занимались PXE загрузкой, записал в uird.from источник с nfs и все. Ничего больше не нужно.
Уирд дает сразу несколько способов сохранений, вообще без дополнительного кода в системе. В том числе toxzm где можно хоть для каждого файла указать нужно ли его сохранять и в какой модуль.
Как все это можно сделать просто? Впрочем.юзеру ОС знать этого не нужно. При сборке уирд записываете туда нужный конфиг и ваша ось грузится вообще без параметров в cmdline ядра.
-
невозможно без дополнительного кода в initrd указать, какие сервисы systemd должны стартовать в системе
Написать скрипт, который читает /proc/cmdline и обрабатывает параметры из него и делает systemctl enable\disable. Запускать его в самом начале системд
сломается при обновлении пакетов
Для подобного у меня есть модуль исправлений 089, выше которого только сохраненкаПри сборке уирд записываете туда нужный конфиг и ваша ось грузится вообще без параметров в cmdline ядра.
Что хорошо продемотнстрировано вашими прменами в исо прар. Причем если не нравится систаксис параметров - есть даже алиасы. Т.е. можно сделать упрощенную обвязку с имитацией привычного юзерам параметров загрузки
-
Написать скрипт, который читает /proc/cmdline и обрабатывает параметры из него и делает systemctl enable\disable. Запускать его в самом начале системд
Теория или практика? У меня на практике такое провернуть не вышло, не запускаются сервисы, назначенные в автозагрузку в процессе загрузки.
-
У меня на практике такое провернуть не вышло, не запускаются сервисы, назначенные в автозагрузку в процессе загрузки.
Может быть нужно добавить вызов systemctl daemon-reload ?
-
Не пробовал в ини для UIRD писать юниты. В магос скрипты с юнитами лежат в 88-magos.xzm и только запускаются UIRD.
Hо по идее что-то вроде такого должно работать независимо от ОС:
[/usr/lib/systemd/system/my.service]
+[Unit]
+Description=my service
+[Service]
+Type=OneShot
+ExecStart=/usr/bin/my-daemon
[/tmp/systemd.sh]a+x [chroot . ]
#!/bin/bash
systemctl enable my.service
Если не сработает с systemctl, то ссылку создать точно можно.
-
добавить вызов systemctl daemon-reload ?
Посмотрел в prar - у меня самодельного daemon-reload нет в systemd