PuppyRus + MagOS (сотрудничество)

[sfs]

Ближе к теме сотрудничества:
Я понял у Вас нет функционала склейки\расклейки squashfs. Т.е pfs-util интересен?
По initrd какие у Вас тенденции? Есть что-то готовое посмотреть?

[betcher]

Про арч я спрашивал именно применительно к FULL, а про FULL прочитал в вики. Показалось не нужной сущностью по этому и спросил.
Теперь к pfsutils, мне кажется, что у вас сделано функциональнее и аккуратнее. Но говорить за всех не могу, интересно мнение МихаилаZ в этом вопросе, а он уже дня три не появлялся нна форуме.
Разработка у нас ведется на гитхабе, что-то по поводу дракут там есть, но лично я не вникал.
https://github.com/magos-linux/magos-linux
По инитрд я участвовал только в работе над спящи режимом и quickshell.

[sfs]

Про арч я спрашивал именно применительно к FULL, а про FULL прочитал в вики. Показалось не нужной сущностью по этому и спросил.

Я согласен с Вами http://wiki.puppyrus.org/users_os/af/af#full
Но у нас на форуме есть большие любители фулл

Общие утилиты должны делать по описанной мной схеме сжатые образы через chroot и опцией предлагать urpmi, apt-get, yum и тд. Это позволит сделать универсально эту часть.

В chroot по новой монтируются все модули дистра? Если структура дистров разная - универсальности не получится
Получается нужен одинаковый initrd и структура модулей

[neobht]

В chroot по новой монтируются все модули дистра? Если структура дистров разная - универсальности не получится
Получается нужен одинаковый initrd и структура модулей

Да. Все тоже самое что при старте, но только временно. От структуры это уже не зависит для самих скриптов. Просто структура будет разная, но это не будет влиять на итог.
chroot делается уже в точку монтирования на aufs.

[neobht]

По initrd какие у Вас тенденции?

По инитрд у нас сейчас функционал портеуса+расширенные параметры относительно сетевой загрузки.

Но сделано это сейчас на linux-live.

Надо делать, я считаю, на dracut. Это будет намного гибче. Можно будет использовать кучу фишек: шифрование различными методами, набор файловых систем шире, поддержка рейдов, LVM и прочие тонкости, которые в dracut уже разными дистрами написаны.

Я приводил тему. Хочется сделать больше чем уже есть и наиболее гибко.

[sfs]

По инитрд у нас сейчас функционал портеуса+расширенные параметры относительно сетевой загрузки.

Посмотрел и почитал Вашу доку. Да. Отличие от porteus - модули ядра в инитрд. В этом есть какая-то засада? Или просто не заморачивались?

Надо делать, я считаю, на dracut. Это будет намного гибче. Можно будет использовать кучу фишек: шифрование различными методами, набор файловых систем шире, поддержка рейдов, LVM и прочие тонкости, которые в dracut уже разными дистрами написаны.

Надо ли это все домашнему юзеру фругала... Чтобы получить то что уже имеете в dracut придется самим пописать и потрудиться. А на выходе получите в лучшем случае то, что уже имеете...
Возможно, я что-то не догоняю по dracut. В частности по udev. Но, пока яснее не стало...

[neobht]

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

У нас модули в инитрд начального уровня : сетевые драйвера и файловые системы. Остальное потом подключается из базового дистра.

[sfs]

У нас модули в инитрд начального уровня : сетевые драйвера и файловые системы. Остальное потом подключается из базового дистра.

Может спионерить в Porteus их метод "сразу из базового дистра" ?

[neobht]

если сразу из базового, тогда слишком много придется скачивать по размеру по tftp или http.

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

В практике так весьма удобно.

[sfs]

Если заморачиваться бездисковыми станциями - все равно базу придется копировать по сети в память. Или Вы монтируете?
Кстати в porteus есть сетевая загрузка. Размер initrd < 1мб. У вас 9
А если база локально - зачем вообще сетевая загрузка

[neobht]

Монтируем.

Если размеры сравнивать, то по хорошему и размер ядра. Потому как модули внутри него будут давать размер.
Но это все условно и зависит от количества сетевух и их моделей. Мы иногда добавляем модули, как только на практике натыкаемся.

[Pro]

Хорошим вариантом для начала будет создание initrd удовлетворяющего потребности обоих систем:
- минимальный размер
- максимальная скорость работы
- поддержка нахождения модулей системы на сетевых дисках
- поддержка определения raid и шифрованных дисков (хотя уверен что ядро уже и само умеет raid находить)
- руссификация сообщений выдаваемых на консоль, либо минимизация данных сообщений.

Имеющиеся варианты в виде Dracut и porteus должны подойти, но насчет Dracut все еще есть сомнения, прошу осмыслить аргументы приведенные http://forum.puppyrus.org/index.php/topic,14436.msg78777.html#msg78777

[sfs]

Распаковал MagOS-initrd. Удивило :
1. наличие в нем 2х squashfs модулей (drivers.xzm и usr.xzm) ...
А почему их обычным способом не монтировать?
2. busybox 2Мб. Все это надо или не заморачивались перекомпиляцией?
3. Попыток русификации не нашел

[Pro]

2. busybox 2Мб. Все это надо или не заморачивались перекомпиляцией?
3. Попыток русификации не нашел

ну так если возьмем его в качестве базового - прикрутим все как надо и сделаем красиво.
коллеги возможно не заморачивались еще такими плюшками как мы: уменьшение размеров ядра и модулей, спец сборка busybox для initrd, руссификация в init это вобще редко кто заморачивается.

[betcher]

Посмотрите mkinitrd лучше, большая часть утилит копируется в инитрд из системы, то есть сейчас из РОСА.