https://www.opennet.ru/opennews/art.shtml?num=53428

дёрнул меня чёрт создать тред на опеннете, чтоб прорекламировать booty. ну что корректор «подкорректировал» я опущу момент.

начни с того, какой профит по сравнению с dd if=.iso of=/dev/usb, с unetbootin, с ventoy и т.д.

АААААААААААА!!!! АААА!!!!

нет, вы посмотрите. они сравнивают программу для создания загрузочных bios/uefi образов с системой внутри с программами для простейшего копирования.

Посмотрел на первую строчку первого попавшегося файла:

#! /usr/bin/env sh

Дальше смотреть явно смысла нет.

эти люди хоть одну строчку кода, портируемого, написали?

при этом лезут, *****, с умным видом, всё то они ***** знают, школьники *****. ***** не знают и везде лезут со своим мнением.

скачать исошку с официального сайта или париться, делая самому

какой однако сложный выбор

да, качай давай, убунточку или манжару там, установил и пользуешься, чё мне эти загрузочные образы делать. для ботанов-задротов каких-то. да? ДАААААА?!

ОН:

не работает нифига

не работает даже ввод в консоли.

5.6.19-2-MANJARO

написал вот каммент и только потом дошло - откуда ваш скрипт вообще берет модули при создании initrd ?

походу оно без модулей ядра у меня получилось (initrd) вот и не грузится.

Я:

подготовить ядро это ваша задача, в пятый раз в этом треде пишу: make defconfig

ОН

иди кашки манной себе приготовь, клоун.

мне еще чего-то готовить нужно что бы твой скрипт заработал, ты совсем что ли белены объелся?

эти люди заслуживают всего того, что с ними происходит.

Всё как вы любите: Twitter, Go, мысли влезающие в 140^W 288 байт...

https://github.com/prologic/twtxt

twtxt — это децентрализованный микроблог а-ля Twitter написанный на Go, по желанию можно поднять собственный инстанс, включив регистрацию, а можно зарегистироваться где-нибудь, например, на инстансе автора: https://twtxt.net/

Всё сообщения инстансов публикуются в текстовом файлике, например https://prologic.github.io/twtxt.txt, который вы можете разместить где угодно, например на Github, даже в локальном файле на флешке, ага, и получать обновления с него для своего инстанса. Ну идея конечно хороша, когда можно использовать любой Github в качестве хостинга для твитов. Создаёте репу, публикуете текстовый файлик и теперь ваши твиты тоже читают...

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

Как и с другими проектами, прежде чем браться за дело, создаю тред. Планирую начать разработку системы оркестрации на POSIX shell, система будет представлять собой сборочный цех дистрибутивов в готовые для загрузки образы raw, initramfs, iso и так далее. Образы будут создаваться из build-файлов, что-то вроде пакетного менеджера, только для дистрибутивов.

Зарубежные партнёры заприметившие проект booty даром выделили сервер (4 ядра 4 гига) для развития http://www.voglea.com/crux/crux_gnulinux/, где в качестве эксперимента я запустил ежедневную автосборку дистрибутивов CRUX из последних версий портов, т.е. сейчас там представлена версия CRUX 3.6 которая в стадии глубокого тестирования, но неофициально образ можно стянуть у меня. :}

Говоря о данной автосборке, выполняются два build-сценария, — staging, собирающий _только_ пакетную базу дистрибутива в iso образ, оно же stage3, и build-сценарий os, собирающий непосредственно готовый к загрузке и установке iso-образ дистрибутива. Образы доступны по ссылке выше.

Скрипты сборки пока-что представлены как шаблоны, тут и тут:

https://github.com/sp00f1ng/booty/blob/master/templates/crux_gnulinux-staging...

https://github.com/sp00f1ng/booty/blob/master/templates/crux_gnulinux-os/crux...

Для сборки систем будут использованы все мои другие проекты: booty + newkernel + cruxstrap.

Я хочу предложить «тупой» метод оркестрации, который в отличии от Ansible не приводит работающую систему к заданному виду из плейбука, а по-мужицки так kexec'ает initrd-образ с собранным в нём дистрибутивом. Тобишь, вы локально пишете сценарий (или плейбук) сборки, включая все необходимые настройки, затем запуском одной команды дистрибутив собирается в raw, initrd, iso и так далее, после чего загружается аки прошивка на удалённый хост и kexec'ается, выполняется перезагрузка системы в новое состояние.

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

Ну дополнительно прикручу синхронизацию локального корня системы с её удалённой версией, т.е. чтобы ради пары файлов не перезагружать всё целиком, а например залить обновление сайта. Просто помещаете файлы в локальный каталог system/rootfs-changes, и корень директории будет синхронизирован с удалённой версией. Вот.

Идеи, предложения?

Сложилась ситуация, что есть разные железки, да виртуалки под разные задачи, — если виртуалки ещё более-менее унифицированы, то для каждого железа хотелось бы иметь своё ядро по-отдельности. Просто чтоб нинужные фичи были отключены. Некоторые пакетные менеджеры позволяют собирать ядра с разными конфигами, чтобы из одного билд-скрипта получались разные пакеты. Но такое доступно не везде и не всех может устраивать.

Задумка в том, чтобы такой пакетный менеджер не был просто установщиком бинарных файлов, а можно было самому «на коленке» написать портянку текста для сборки ядра. Сценарий, который запускается, и ядро собирается.

Мой новый проект newkernel: https://github.com/sp00f1ng/newkernel

Он умеет скачивать ядро. Вот. Всё. :)

Ладно, не всё так просто. Для того, чтобы скачать сорцы ядра нужно выполнить одну простую команду:

cd `newkernel`

Да, вот так вот просто. newkernel скачает, распакует сорцы и вернёт директорию для команды cd чтобы туда зайти. После чего можно приступать к сборке.

Скрипт умный, и если долгое выполнение команды cd (пока ядро скачивается в фоне) отменить нажатием Ctrl + C, то повторным запуском загрузка будет продолжена с того момента, где остановилась.

Допустим, мы хотим ядро определённой версии. Не вопрос! Это по-умолчанию без параметров скачивается последнее ядро, а можно указать

cd `newkernel 5.7.0`

и получить определённую версию ядра.

Если ядро уже скачано и распаковано, то скрипт не будет его повторно скачивать, а просто выполнит make mrproper, после чего уже зайдёт в директорию с чистеньким ядром. Однако можно принудительно попросить скачать ядро ещё раз, если мы совсем параноики, для этого есть опция -f. press F to pay respect o7

cd `newkernel -f 5.4.3`

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

cd `newkernel -s /tmp`

Так вот после выполнения этой команды, вы оказываетесь в директории с сорцами ядра. Выполняете все необходимые настройки, ну там make defconfig, make.

После чего ядро нужно установить или получить архив со всеми файлами. Для этого есть команда welldone, она тоже возвращает просто путь, куда будет установлено ядро.

Например, чтобы запаковать полученное ядро в архив, просто выполните:

tar -cJvf ~/linux-latest.tar.xz -C `welldone` .

~/linux-latest.tar.xz с вашим ядром и модулями готов к распаковке в чрут или корень!

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

cp -a `welldone`/* /

Вот так всё просто. :)

Т.е. суть очень проста, вы используете cd `newkernel` чтобы скачать нужное ядро и зайти в директорию, затем выполняете команды, и в конце получаете `welldone` директорию со всеми установленными файлами и модулями ядра!

Для примера небольшой скрипт, который просто запускаете и он всё делает:

cd `newkernel`
make defconfig

# Sound
scripts/config -e SND_HDA_INPUT_BEEP
scripts/config -e SND_HDA_PATCH_LOADER
scripts/config -e SND_HDA_CODEC_REALTEK
scripts/config -e SND_HDA_CODEC_HDMI
scripts/config -e SND_USB_AUDIO
# AMD GPU
scripts/config -m DRM_AMDGPU
scripts/config -e DRM_AMD_ACP
# nVidia GPU
scripts/config -m DRM_NOUVEAU

make olddefconfig
make

cp -a `welldone`/* /

Как всё просто. :)

Перемещено Zhbert из linux-install

Как вы решаете проблему высокой задержки сети и медленного
отклика при удалённом администрировании серверов?

Уж не говорю про какой-нибудь RDP, хотя бы текстовый ssh,
дак ведь элементарная правка конфигов и набор команд
превращается в пошаговую стратегию.

Здесь нужен другой подход, как мне кажется. Например,
локальная настройка с последующей загрузкой на удалённый
хост. Так? Что-то вроде Ansible должно решить проблему? Или
ещё круче, создавать некую прошику, образ с системой
локально, а затем просто загружать его целиком удалённо. Не?

Сап ЛОР, суть такова. Есть два кхм, способа загрузки init (initramfs), как с busybox, так и без него. В случае если busybox есть, то запускается mdev для создания блочных устройств, если busybox нету, тогда мы создаём эти устройства сами, руками (спасибо Nastishka).

	if test "$BUSYBOX" = "yes"; then
		mdev -s
		if test -f "/proc/sys/kernel/hotplug"; then
			echo "$(which mdev)" > /proc/sys/kernel/hotplug
		fi
	fi
	if test "$BUSYBOX" = ""; then
		for nod in "/sys/block/"*; do
			dev="${nod##*/}"
			block=""
			major=""
			minor=""
			read block < "$nod/dev"
			major="${block%:*}"
			minor="${block#*:}"
			mknod "/dev/$dev" "b" "$major" "$minor" 2>/dev/null
		done
		unset nod dev block major minor
	fi

Мы загружаемся с USB-накопителя, и даже не смотря на то, что мы уже находимся на стадии initramfs и выполняем код из /init с самой флешки(sic!), не все блочные устройства успевают определиться ядром, в том числе сама флешка, с которой происходит загрузка.

Вот мы загрузились в initramfs, но основная система находится на флешке. Нужно из /init эту флешку найти, смонтировать, и использовать образы с системой в дальнейшем. Мы всё это делаем. За исключением того, что флешки пока ещё не видно.

Проблема в том, что ядро элементарно не успевает создавать блочные устройства /sys/block/sr0 /sys/block/sda /sys/block/sdb и так далее. В тот самый момент, когда запускается mdev или мы руками создаём mknod, этих устройств пока ещё нет, а появятся они буквально в следующие два-три мгновения (в зависимости от нагрузки, конечно же, как подсказал Difrex что sleep не панацея, хотя и вероятность такого исхода КРАЙНЕ МАЛА).

До этого я грешил на mdev, дескать он завершает работу, а устройства появляются уже потом, но скрипт продолжает выполнение и поэтому ничего не находит. sleep 5 решил эту проблему. Но как оказалось проблема в самом /sys/block, что там нечего находить. Ядро ничего не создало, пока ещё.

Таким образом именно перед этими двумя блоками кода необходимо реализовать какую-нибудь задержку, желательно без sleep, чтобы дождаться появление /sys/block/sda, а затем уже продолжить работу. Или не дождаться, потому что их вовсе может и не быть.

Чем такое можно реализовать?

Мы думаем сделать подобие диффов директории, чтобы несколько итераций циклом прогнять проверку и продолжить выполнение. Как лучше поступить? За что тут можно зацепиться?

И да, тащить целый бинарник sleep крайне не желательно.

Идеи? Предложения? :)

Установил Proxmox, где планирую развернуться. Встал вопрос об отказоустойчивости, и если я ещё поверю, что команду shutdown скрипты отработают как надо и выключат виртуалки корректно, то вот уже внезапное отключение света боюсь сломает всё: и ZFS/RAID на самом Proxmox, и ФС в самих виртуалках. Соответственно к машине с Proxmox обязательно нужен ИБП.

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

В ИБП тоже используются аккумуляторы. Есть кто использует их дома? Как часто приходится оставлять это без присмотра? Можно ли как-то обезопасить себя от несчастного случая? Может в какой-нибудь короб металлический дополнительно запихать весь ИБП с минимальным притоком воздуха, чтоб только провода торчали?

Вариант с арендой сервера и/или KVM я не рассматриваю, потому как, зашёл по noVNC на виртуалку, а там tty залогиненый висит и команда ip a выполнена кем-то, лол! Портить репутацию провайдеру не буду, но осадочек остался. Теперь все эти сервера будут использоваться только как обратные прокси для туннелирования трафика.

Есть два варианта загрузки ОС Линукс, засунуть её целиком в initramfs образ и загрузить систему из него, тогда проблем нет кроме ограничения на размер initrd на некоторых системах (на AM4, более специфичных подробностей не знаю, хотя память позволяет, гугл ничего не сказал про максимальный размер initrd, на FM2+, 1151 всё тоже самое загружается успешно).

И другой вариант, когда initrd должен переключиться в систему которая находится на другом накопителе, будь то HDD, USB-флешка и так далее. Но для этого надо создать соответствующие блочные устройства в /dev, приходится тянуть целый бинарник busybox по сути ради одного mdev, вместо пrавославного использования утилит из хост-системы.

https://github.com/sp00f1ng/boobstrap/blob/master/init.in#L176-L182

Так вот, можно ли как-то самостоятельно почекать содержимое /sys баш-скриптом и самому создать блочные устройства? Чтобы избавиться от busybox/mdev. Такое возможно?

./configure может подхватывать нежеланные зависимости автоматически, и затем если пакет установить на чистую систему, бинарник не запустится, ругаясь на отсутствие какой-нибудь библиотеки (ldd), а надо чтобы бинарный пакет был собран только с нужными зависимостями, и не более.

Разворачивать chroot для каждого пакета и начинать сборку «от и до» с нуля? Как?

Довольно странно что Enter не работает как Enter на цифровом блоке клавиш, пробовал запускать FVWM без IgnoreModifiers, не помогло.

С включённым Num Lock тоже никаких изменений.

Запускаю терминал клавишами Alt + Enter, и просто было бы удобно, держа руку на мышке, когда собираешься перенести руки на клавиатуру, большим пальцем левой руки зажать Alt, а большим пальцем правой руки жмякнуть на Enter на NumPad, дабы тем временем пока открывался терминал, ты как раз перенёс руки на клавитуру. )

Здравствуйте, мои маленькие любители авиационного спирта!

Сегодня я вам расскажу на примере Gentoo GNU/Linux как создать загрузочную USB-флешку или любой другой накопитель, HDD, SSD, и расскажу как сделать откат неудачных конфигураций. Прям как в NixOS, но главное отличие и преимущество, что это не NixOS, а это может быть вообще любой дистрибутив на ваш выбор. Так!

Скачиваем генту.

# wget https://bouncer.gentoo.org/fetch/root/all/releases/amd64/autobuilds/20200624T214505Z/stage3-amd64-20200624T214505Z.tar.xz
# mkdir gentoo/
# tar xf stage3-* -C gentoo/

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

# chroot gentoo/ /bin/bash <<EOF
echo -e "toor\ntoor" | (passwd root)
EOF

Всё, на этом этапе у нас есть директория gentoo/, это может быть вообще любой дистрибутив, значения не имеет.

Теперь для создания загрузочной USB-флешки вам понадобится:

✅ USB-флешка
✅ Ядрышко, можно ванильное (/boot/vmlinuz-* подойдёт).
✅ initrd-образ (создадим сами).

Не забудьте USB-накопитель подключить к компьютеру.

Подключив, USB-накопитель появится по адресу, например, /dev/sdb.

Создадим initrd-образ:

# mkinitramfs `mktemp -d` > initrd

А теперь создаём загрузочный USB-накопитель:

# mkbootable /dev/sdb      \    # <- это флешка
    --kernel /boot/vmlinuz \    # <- это ядро linux
    --initrd ./initrd      \    # <- это initrd
    --overlay gentoo/      \    # <- это папка с дистрибутивом linux
    --squashfs-xz               # <- это способ сжатия папки с дистрибутивом linux

⚠⚠⚠ Все данные на /dev/sdb будут уничтожены!!! ⚠⚠⚠

Всё готово, вы великолепны! Теперь вы можете загрузиться с данного USB-накопителя в свою Gentoo!

А вся красота данного метода заключается в том, что вы можете продолжать пользоваться своим USB-накопителем как USB-накопителем! И к тому же установленной системой на ней!

USB-флешка загружается и на BIOS, и на UEFI-системах!

Структура накопителя следующая:

/dev/sdb                         # <- ваша флешка
/dev/sdb1                        # <- BIOS раздел 1мб
/dev/sdb2                        # <- UEFI раздел 50мб
  /EFI/BOOT/BOOTX64.EFI
/dev/sdb3                        # <- ваш линукс и ваши данные
  /boot/grub
  /boot/vmlinuz
  /boot/initrd
  /system/10-gentoo.squashfs     # <- гента!1!
  /ANIME
  /MLP NEW SERIES                # <- другие важные данные на флешке

Создание BIOS / UEFI загрузочной USB-флешки всего одной командой!!!!1

И эта флешка ещё может продолжать использоваться как флешка!11

Загрузившись с использованием опции boobs.use-overlayfs, или выбрав в меню загрузчика grub пункт: «Boot using Overlay FS», ваша условная Gentoo GNU/Linux будет работать как read-only оверлей.

Все изменения которые вы сделаете в системе сохраняются отдельной в папке /mnt/overlays/roofs-changes.

Что мы делаем теперь? А теперь мы можем все эти изменения сохранить и положить сюда же, на USB-накопитель! Это может быть SquashFS-образ, cpio-архив или просто директория, да.

Из загруженой системы монтируем флешку в /mnt/storage:

# mount /dev/sdb3 /mnt/storage

После обновления «мира», добавления новых пакетов сохраняем все изменения как SquasFS-образ:

# mksquashfs /mnt/overlays/rootfs-changes /mnt/storage/system/rootfs-changes.squashfs

Все наши /home-данные можно просто скопировать как обычную директорию на флешку:

# cp -a /home /mnt/storage/system/home-data

Каждое обновление системы можно сохранять отдельным SquashFS-образом.

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

Шах и мат, NixOS!

Скачать: https://github.com/sp00f1ng/boobstrap

Скриншот

Спустя несколько дней активной разработки состоялся релиз boobstrap v1.1 — набор POSIX shell скриптов для создания загрузочных носителей с ОС GNU/Linux.

Что нового в этой версии?

• Добавлена поддержка busybox, оно не обязательно, но если оно установлено в вашей системе, — оно будет использовано при создании initrd образов. Если нет, то по прежнему весь необходимый набор утилит будет скопирован с вашей системы.
• Оверлеи (образы систем) теперь можно хранить на любых устройствах хранения данных. В версии 1.0 при создании загрузочного образ система с дистрибутивом линукса «вшивалась» прямо в initrd, в результате чего initrd мог получиться больших размеров и не на всех системах загружаться, но теперь благодаря busybox стало возможным хранить образы на любых накопителях информации. Оверлеи можно хранить на том же ISO образе или на других накопителях отдельно.
• Добавлена отдельная утилита mkoverlayfs для создания оверлеев, а именно это могут быть директории, cpio-архивы, squashfs-образы. Это удобно для ручного создания оверлеев с последующим их перемещением на initd-образ или создаваемый загрузочный ISO-образ.
• Утилита mkbootisofs теперь поддерживает все те же опции что и mkinitramfs, так например при создании оверлеев через mkbootisofs `mktemp -d` --overlay rootfs-system/ --overlay rootfs-changes/ --squashfs > boot.iso перечисленные оверлеи будут добавлены на сам ISO-образ. Больше нет необходимости создавать и загружать initrd огромных размеров.
• Создаваемый initrd теперь может работать сам по себе mkinitramfs `mktemp -d` > initrd.img без необходимости переключаться в какую-либо систему. initrd будет сам пытаться найти систему из оверлеев на всех доступных накопителях и переключаться в неё. Для работы этой функции потребуется наличие busybox.
• Обеспечена полная обратная совместимость, таким образом, что не имеет значение, откуда и как вы загружаетесь и какими инструментами пользуетесь. Больше нет обязательных к установке программ-зависимостей (кроме как для создания ISO). Загружаемый initrd прекрасно работает при использовании нативных утилит из вашей хост-системы, либо же при использовании busybox. Так же без разницы, где итоговая система будет распологаться, на самом initrd или на отдельном устройстве накопителе информации (ISO, USB, HDD/SSD, CD-ROM...). initrd загрузится в любом случае, если найдёт куда.
• Добавлена возможность загружать систему в SHMFS (tmpfs, ramfs) и переключаться в чистое окружение tmpfs без использования OVERLAY_FS. Таким образом обеспечена работа с ванильным ядром, просто make defconfig && make и у вас всё будет работать. Стоит при этом учесть, что система может занимать много места в оперативной памяти, подробнее уточняйте у вашего du -csh your-gentoo-chroot/. Так же, теперь использование SHMFS это поводение загрузчика initrd по-умолчанию, и если вы хотите продолжить использование оверлеев, необходимо принудительно их включить.
• Добавлены следующие опции для передачи ядру Linux при загрузке.
  • boobs.use-shmfs — при использовании данной опции данные со всех оверлеев будут скопированы в одну tmpfs папку, после чего система будет полностью загружена и работать прямиком из чистого tmpfs. Используйте данную опцию с осторожностью. Так например, если ваша система распологается внутри initrd-образа, к примеру, хранится как rootfs.cpio-архив, и размер данного архива 1ГБ, то прежде чем система будет окончательно загружена, она должна быть распакована из архива, а для этого потребуется ещё 1ГБ памяти помимо уже загруженого initrd, и плюс ещё немножко на запущенные программы. И только после того как система будет окончательно загужена, первичный rootfs.cpio-архив будет удалён из памяти и 1ГБ памяти будет освобождён. Учитывайте такие нюансы. Если же система в rootfs.cpio-архиве хранится на каком-либо носителе, например ISO на USB, то тогда потребуется всего 1ГБ памяти для распаковки системы в память. Так же учитывайте, что это поведение по-умолчанию, поскольку SHMFS поддерживается ванильным ядром «из коробки», а CONFIG_OVERLAY_FS нужно включать, что может быть не дружелюбно к пользователю, как женщины не дружелюбны ко мне.
  • boobs.use-overlayfs — опция, при которой будет использована файловая система Overlay FS для монтирования, загрузки и дальнейшей работы всех образов с оверлеями. Например, SquashFS-образ с системой будет смонтирован в папку, после чего система будет загружена и работать из данного SquashFS-образа с использованием Overlay FS. При использовании оверлеев так же добавлена возможность сохранения всех изменений сделанных в системе. Вся история изменений сохраняется в папке /mnt/overlays/rootfs-changes. Например, когда вы загрузились в свою систему, запускаются различные демоны, которые вносят свои данные в корень файловой системы, или например вы создаёте файлы, и так далее и тому подобное. Все эти изменения, внесённые в систему, доступны через папку /mnt/overlays/rootfs-changes. Вы можете её архировать и сохранять с последующей загрузкой как оверлей.
  • boobs.copy-to-ram — опция позволяет скопировать образы с оверлеями в память, прежде чем система будет с ними работать. Например, когда вы загрузились с USB-флешки, все образы соответственно будут смонтированы с данной USB-флешки и система будет загружена и работать с неё. Однако, указав данную опцию, все образы с оверлеями будут предварительно скопированы с USB-флешки в память, и только затем подключены, и система будет окончательно загружена, после чего USB-флешку можно отключить от вашего устройства.
  • boobs.search-rootfs — по-умолчанию все созданные оверлеи сохраняются в папке /system/overlays, но вы можете указать любую свою папку на выбор или даже просто файл, где следует искать и откуда загружать оверлеи с вашей системой. Так например, указав опцию для ядра boobs.search-rootfs=/filesystem.squashfs, и далее создав утилитой mkoverlayfs свой оверлей с системой, положив его в корень любого вашего накопителя информации, будь то диск, флешка... initrd будет искать данный образ в корне каждого накопителя информации, и в случае успеха оверлей с системой будет загружен. Опять же, если вы хотите загрузить несколько оверлеев наложенных друг поверх друга, то укажите, внезапно, директорию!
• Ну и, конечно же, обновлена документация, за что отдельное спасибо камраду Difrex за перевод файла README в формат Markdown.

Так же, товарищем @swine с IRC-канала #lor @ freenode поступил запрос загружать оверлей не с initrd, не с iso-образа, а именно с жёсткого диска. В качестве примера рассмотрю эту ситацию и опишу как это делается.

Прежде всего, у вас должна быть подготовлена ваша система в отдельной директории, разверните какой-нибудь чрут, да хоть ту же Gentoo скачайте и распакуйте в директорию (шутки кончились, да, теперь всё сульёзна!). Допустим, в gentoo/.

Далее создадим оверлей как SquashFS-образ. И сохраним образ в корень любого вашего накопителя, текущего жёсткого диска, в качестве примера.

# mkoverlayfs gentoo/ --squashfs-xz --output /gentoo.squashfs

Теперь создадим «фирменный» initrd-образ, обычный, без ничего.

# mkinitramfs `mktemp -d` > /boot/initrd

Для загрузки осталось лишь обновить загрузчик и указать загрузку ядра со следеующими опциями:

linux /boot/vmlinuz boobs.use-overlayfs boobs.search-rootfs=/gentoo.squashfs
initrd /boot/initrd

Всё, перезагружаем компьютер, выбираем в загрузчике наши опции и получаем на выходе работающий /gentoo.squashfs через Overlay FS, сохраняющий все изменения в памяти (tmpfs).

При желании можете добавить опцию boobs.copy-to-ram и отнести жёсткий диск на свалку истории, личная рекомендация от Спуфаря.

Делюсь кодом для раскраски сообщений выводимых через echo, который использую в своём проекте.

Использовать так:

. colours.sh
echo Bla bla bla | msg -2 --foreground "Light Red" --highlight

Где -1 это STDOUT, соответственно -2 для STDERR.

Можно указать --foreground, --background, --highlight и --bold.

Коды цветов связаны напрямую с mIRC, т.е. условно скажем, если в линуксовой консоли 0 (нулевой) это чёрный, 1 (первый) это красный, то в mIRC порядок немножечко другой, и красный там это 4 цвет. Если вы хоть раз в жизни пользовались IRC клиентом, то знаете, о чём речь. Порядок цветов именно такой, какой используется в IRC, просто мне так удобнее потому что в отличии от линуксовой консоли цвета mIRC я помню наизусть )) Но можете изменить порядок цветов как вам надо. Цвета можно использовать указывая их номер или их полное название, описание цветов в IRC тут: https://www.mirc.com/colors.html

echo "Bla Bla Bla" | msg -1 --foreground 9 --background 1

9 это зелный текст, 1 это чёрный фон.

Надеюсь это кому-нибудь окажется полезным.

#! /bin/sh -

msg() {
	STDOUT=""
	STDERR=""
	fore=""
	back=""
	ctrl=""
	sgr0=""
	while test "$1"; do
		case "$1" in
			"-1")		STDOUT="yes" ;;
			"-2")		STDERR="yes" ;;
			"--foreground")	fore="$2" ; shift ; ;;
			"--background")	back="$2" ; shift ; ;;
			"--highlight")	ctrl="$ctrl$SWITCH_HIGHLIGHT" ; ;;
			"--bold")	ctrl="$ctrl$SWITCH_BOLD" ; ;;
		esac
		shift
	done
	case "$fore" in
		"00"|"0"|"White")	fore="$FOREGROUND_00" ;;
		"01"|"1"|"Black")	fore="$FOREGROUND_01" ;;
		"02"|"2"|"Blue")	fore="$FOREGROUND_02" ;;
		"03"|"3"|"Green")	fore="$FOREGROUND_03" ;;
		"04"|"4"|"Light Red")	fore="$FOREGROUND_04" ;;
		"05"|"5"|"Brown")	fore="$FOREGROUND_05" ;;
		"06"|"6"|"Purple")	fore="$FOREGROUND_06" ;;
		"07"|"7"|"Orange")	fore="$FOREGROUND_07" ;;
		"08"|"8"|"Yellow")	fore="$FOREGROUND_08" ;;
		"09"|"9"|"Light Green")	fore="$FOREGROUND_09" ;;
		"10"|"Cyan")		fore="$FOREGROUND_10" ;;
		"11"|"Light Cyan")	fore="$FOREGROUND_11" ;;
		"12"|"Light Blue")	fore="$FOREGROUND_12" ;;
		"13"|"Pink")		fore="$FOREGROUND_13" ;;
		"14"|"Grey")		fore="$FOREGROUND_14" ;;
		"15"|"Light Grey")	fore="$FOREGROUND_15" ;;
		*)			fore="$FOREGROUND_DEFAULT" ;;
	esac
	case "$back" in
		"00"|"0"|"White")	back="$BACKGROUND_00" ;;
		"01"|"1"|"Black")	back="$BACKGROUND_01" ;;
		"02"|"2"|"Blue")	back="$BACKGROUND_02" ;;
		"03"|"3"|"Green")	back="$BACKGROUND_03" ;;
		"04"|"4"|"Light Red")	back="$BACKGROUND_04" ;;
		"05"|"5"|"Brown")	back="$BACKGROUND_05" ;;
		"06"|"6"|"Purple")	back="$BACKGROUND_06" ;;
		"07"|"7"|"Orange")	back="$BACKGROUND_07" ;;
		"08"|"8"|"Yellow")	back="$BACKGROUND_08" ;;
		"09"|"9"|"Light Green")	back="$BACKGROUND_09" ;;
		"10"|"Cyan")		back="$BACKGROUND_10" ;;
		"11"|"Light Cyan")	back="$BACKGROUND_11" ;;
		"12"|"Light Blue")	back="$BACKGROUND_12" ;;
		"13"|"Pink")		back="$BACKGROUND_13" ;;
		"14"|"Grey")		back="$BACKGROUND_14" ;;
		"15"|"Light Grey")	back="$BACKGROUND_15" ;;
		*)			back="$BACKGROUND_DEFAULT" ;;
	esac
	if test "$fore$back$ctrl"; then
		sgr0="$(tput sgr0)"
	fi
	if test "$STDOUT" = "yes"; then
		while read input; do
			echo "$fore$back$ctrl$input$sgr0" >&1
		done
	fi
	if test "$STDERR" = "yes"; then
		while read input; do
			echo "$fore$back$ctrl$input$sgr0" >&2
		done
	fi
}

mirc_colours_schema() {
	FOREGROUND_00="$(tput setaf 7)$(tput bold)"
	FOREGROUND_01="$(tput setaf 0)"
	FOREGROUND_02="$(tput setaf 4)"
	FOREGROUND_03="$(tput setaf 2)"
	FOREGROUND_04="$(tput setaf 1)$(tput bold)"
	FOREGROUND_05="$(tput setaf 1)"
	FOREGROUND_06="$(tput setaf 5)"
	FOREGROUND_07="$(tput setaf 3)"
	FOREGROUND_08="$(tput setaf 3)$(tput bold)"
	FOREGROUND_09="$(tput setaf 2)$(tput bold)"
	FOREGROUND_10="$(tput setaf 6)"
	FOREGROUND_11="$(tput setaf 6)$(tput bold)"
	FOREGROUND_12="$(tput setaf 4)$(tput bold)"
	FOREGROUND_13="$(tput setaf 5)$(tput bold)"
	FOREGROUND_14="$(tput setaf 0)$(tput bold)"
	FOREGROUND_15="$(tput setaf 7)"
	FOREGROUND_DEFAULT=""

	BACKGROUND_00="$(tput setab 7)$(tput bold)"
	BACKGROUND_01="$(tput setab 0)"
	BACKGROUND_02="$(tput setab 4)"
	BACKGROUND_03="$(tput setab 2)"
	BACKGROUND_04="$(tput setab 1)$(tput bold)"
	BACKGROUND_05="$(tput setab 1)"
	BACKGROUND_06="$(tput setab 5)"
	BACKGROUND_07="$(tput setab 3)"
	BACKGROUND_08="$(tput setab 3)$(tput bold)"
	BACKGROUND_09="$(tput setab 2)$(tput bold)"
	BACKGROUND_10="$(tput setab 6)"
	BACKGROUND_11="$(tput setab 6)$(tput bold)"
	BACKGROUND_12="$(tput setab 4)$(tput bold)"
	BACKGROUND_13="$(tput setab 5)$(tput bold)"
	BACKGROUND_14="$(tput setab 0)$(tput bold)"
	BACKGROUND_15="$(tput setab 7)"
	BACKGROUND_DEFAULT=""

	SWITCH_OFF="$(tput sgr0)"
	SWITCH_BOLD="$(tput bold)"
	SWITCH_UNDERLINE_ON="$(tput smul)"
	SWITCH_UNDERLINE_OFF="$(tput rmul)"
	SWITCH_HIGHLIGHT="$(tput blink)"
	SWITCH_REVERSE="$(tput rev)"
	SWITCH_DEFAULT=""
}

mirc_colours_schema

Есть такой сборочный скрипт (CRUX Pkgbuild), который включает сжатие модулей посредством XZ и другие настройки ядра скриптом scripts/config, который поставляется вместе с исходниками ядра. Нет необходимости тащить за собой весь .config, рано или поздно позабыв чем он отличается от ванильки (inb4 scripts/diffconfig), а так всё «на виду», тем более что, надо-то всего несколько опций включать.

Так вот, при загрузке ОС выполняются правила iptables -t nat, а iptable_nat подхватывается как модуль (значение в ядре по-умолчанию), а поскольку модуль имеет .ko.xz формат, ядро ругается, что такого модуля нет. Сделав unxz модуль успешно загрузился вручную через modprobe.

ЧЯДНТ? Как сделать чтобы сжатые XZ модули подгружались ядром? В других дистрибутивах это работает!

name=linux
version=5.7.2
release=1
source=(https://cdn.kernel.org/pub/linux/kernel/v5.x/$name-$version.tar.xz)

build() {
        cd $name-$version
        make defconfig
        make kvmconfig

        # KO (Kernel Objects)
        scripts/config -e MODULE_COMPRESS
        scripts/config -e MODULE_COMPRESS_XZ

        # Virtualization
        scripts/config -m KVM
        scripts/config -m KVM_INTEL
        scripts/config -m KVM_AMD

        # SquashFS + OverlayFS
        scripts/config -e OVERLAY_FS

        scripts/config -e SQUASHFS
        scripts/config -e SQUASHFS_XZ

        # Sound
        scripts/config -e SND_HDA_INPUT_BEEP
        scripts/config -e SND_HDA_PATCH_LOADER
        scripts/config -e SND_HDA_CODEC_REALTEK
        scripts/config -e SND_HDA_CODEC_HDMI
        scripts/config -e SND_USB_AUDIO

        # AMD GPU
        scripts/config -m DRM_AMDGPU
        scripts/config -e DRM_AMD_ACP

        # nVidia GPU
        scripts/config -m DRM_NOUVEAU

        # "GIGABYTE X470 AORUS ULTRA GAMING" ethernet
        scripts/config -m CONFIG_IGB
        scripts/config -m CONFIG_IGBVF

        make olddefconfig
        make
        install -D -m 0644 "$(make -s image_name)" $PKG/lib/modules/$version/vmlinuz
        make INSTALL_MOD_PATH="$PKG" modules_install
        rm $PKG/lib/modules/$version/{source,build}
}

И чтобы не плодить треды сразу вопрос про distcc.

1. Чтобы distcc работало корректно на каждой «ноде» должна быть абсолютная точная конфигурация системы, включая все пакеты, все заголовочные файлы и прочая? Или нет? Просто на любом хосте, на любом дистрибутиве, может быть даже на любой архитектуре ставишь distcc и он творит такую магию, возвращая корретные скомпилированные бинарники?

2. Если происходит второй вариант с «магией», то может быть я создам загрузочный ISO с дистрибутивом, чтобы каждый желающий, кто хочет поделиться вычислительными ресурсами, просто загружал этот ISO в своей виртуалке/железке, становясь частью «улья», сообщая «матке» свой IP, куда далее все кому нужна быстрая сборка через distcc, «вступают и компилируют»?

3. Из второго варианта вытекает третий, если это может быть небезопасно, что вместо корректного бинарника тебе отправят условный майнер, может внедрить систему подписей или вроде того, как у пакетов дистрибутивов? Вообще, если пользователи линукс доверяют бинарным дистрибутивам в принципе, то не вижу оснований не доверять удалённым distcc нодам, которые собирают те же самые бинарники.

Где я ошибся? Заранее спасибо.

Поставил Manjaro / Arch Linux чтобы закрыть несколько багов в проекте связанных со спецификой дистрибутивов, думал сейчас быстренько разберусь со всем и свалю обратно. Дак нет же, вместо того, чтобы в user-friendly дистрибутиве просто сделать git clone и начать щёлкать Issues как орешки, мне пришлось бодаться с запуском QEMU из под root! Мдя...

Почему во времена всеобщей виртуализации, контейнеризации и одноразовых нод, — запустил, поработал, удалил, всё ещё существуют рекомендации «не запускать ничего с правами root». И ладно бы, дело ограничивалось одними лишь предупреждениями, — программы вовсе отказываются запускаться.

Мне удобно работать из под root, т.к. это не накладывает никаких ограничений на работу с системой, на тот-же mount. Удобно, когда перед тобой все возможности системы без ограничений, а значит без лишних движений на постоянные sudo/su. Система тоже одноразовая, каждый раз загружается заново по сети, например, или с флешки, или пусть даже я её установлю на диск, она всё ещё остаётся одноразовой поскольку служит одноразовой цели. Надёжность — это когда ты делаешь бэкапы, а не вводишь постоянно свой пароль. С чего ради все считают, что если ты устанавливают систему, значит всё, «и в радости и в горе, пока rm -rf / не разлучит вас». А значит надо всё запретить! Нипущать! Никого тебе удобства работы из под root!

Или Debian, установщик которого всё ещё считает, что / под всю систему это для «novice», а раздельные / /home /var это для «expert», ха! Если надо настроить специфичную конфигурацию, делаешь это в отдельном контейнере, виртуалке. Когда мало ресурсов или возможностей виртуалки, или даже тебе визуально легче представить это на реальном железе, то делаешь это соответственно на отдельной железке, одноразово, опять же, сохраняешь свою конфигурацию и пользуешься на века. К чему нужна вся эта суета вокруг выбора ФС? Сплошная экономия на спичках чтобы выиграть сущие проценты производительности.

Наступили времена одноразовых нод. Одноразовых железок, даже.

И хватит уже носиться с root как со священной коровой.

CRUX

# pkginfo -i | egrep '(pcre|grep)'
grep 3.4-2
libpcre 8.44-1
# ldd /sbin/switch_root | grep -o "/.* "
/lib/libc.so.6 
/lib/ld-linux-x86-64.so.2

Manjaro

# pacman -Q | egrep "(pcre|grep)"
grep 3.4-1
pcre 8.44-1
pcre2 10.35-1
# ldd /sbin/switch_root | grep -o "/.* "
/usr/lib/libc.so
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2

Вот и как писать после этого на POSIX shell. -_-

В итоге сделал так.

lddtree() {
	if test "$1" = ""; then
		return 0
	fi

	echo "$1"

	for dep in $(ldd "$1" | grep "=> /" | cut -d " " -f 3); do
		lddtree "$dep"
	done
}

Потому как предыдущий вариант, с grep -o "/.* ", радостно сообщал:

ldd: ./=>: Нет такого файла или каталога
      =>
        Failure []
      /lib64/ld-linux-x86-64.so.2
        Failure []
      /usr/bin/mv
        Failure []
      /usr/lib64/ld-linux-x86-64.so.2
        Failure []
      /usr/lib/ld-linux-x86-64.so.2
        Failure []
      /usr/lib/libacl.so.1
        Failure []
      /usr/lib/libattr.so.1
        Failure []
      /usr/lib/libc.so.6
        Failure []

Пишу утилиту, и надо бы написать документацию к ней.

Подскажите, в чём это можно делать «на лету», не отвлекаясь на нюансы вроде отступов, оформления в виде специальных тэгов и прочего. И чтобы конечно, потом это можно было конвертировать в обычный man, txt, html опционально.

Ubuntu.png

Будет полезно тем, кто хочет делать свои сборки на основе Ubuntu, добавив туда необходимый инструментарий хакера или сменить обои рабочего стола.

Возьмём за основу любой образ любой редакции Ubuntu.

# wget https://mirror.yandex.ru/ubuntu-releases/20.04/ubuntu-20.04-desktop-amd64.iso

Примонтируем.

# mkdir ubuntu-iso
# mount ubuntu-20.04-desktop-amd64.iso ubuntu-iso

И распакуем содержимое корневого раздела Live-образа.

# mkdir squashfs-root
# unsquashfs ubuntu-iso/casper/filesystem.squashfs squashfs-root/

Теперь можно выполнить chroot squashfs-root/ /bin/bash для настройки системы. echo nameserver 8.8.8.8 > /etc/resolv.conf, apt update && apt list --upgradable | less && apt upgrade, ну и так далее по списку.

После того, как вы закончите её настраивать, осталось выполнить две команды.

Делай раз.

# mkinitramfs `mktemp -d` --overlay squashfs-root --squashfs-xz --output initrd

Делай два.

# mkdir -p iso/boot
# cp squashfs-root/boot/vmlinuz-*-generic iso/boot/vmlinuz
# cp initrd iso/boot/initrd
# mkbootisofs iso/ > mybuntu.iso

Вы великолепны, mybuntu.iso можно записывать на флешку.

Скачать mkbootstrap / mkinitramfs / mkbootisofs ( https://github.com/sp00f1ng/boobstrap ).

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

В качестве «эталона» возьмём Gentoo. Скачиваем stage3 amd64, распаковываем, размер дистрибутива:

# du -sh gentoo/
1.1G	gentoo/
# du -s gentoo/
1104960	gentoo/

plain = 1.1G

Простейший initramfs, используя саму директорию Gentoo для создания образа.

Для работоспособности нужно только сделать симлинк ln -s sbin/init init.

Это просто cpio без всякого сжатия.

# mkinitramfs gentoo/ > initrd 
1938832 blocks
# du -sh initrd
947M	initrd
# du -s initrd
969420	initrd

cpio = 947M

В том же режиме «standalone» директории упакуем в gzip.

# mkinitramfs gentoo/ | gzip -c -9 -v > initrd.gz
1938832 blocks
 67.1%
# du -sh initrd.gz 
312M	initrd.gz
# du -s initrd.gz 
318628	initrd.gz

gzip = 312M

xz, самый распространённый из самых «сильных» форматов сжатия на данный момент.

# mkinitramfs gentoo/ | xz -c -C "crc32" -T 0 -9 -e -v > initrd.xz
1938832 blocks
  100 %       167.3 MiB / 946.7 MiB = 0.177   8.6 MiB/s       1:49             
# du -hs initrd.xz
168M	initrd.xz
# du -s initrd.xz
171308	initrd.xz

xz = 168M

Теперь взглянем на современный, инновационный, сногшибательный, духозахватывающий, неповторимый zstd!

# mkinitramfs gentoo/ | zstd -T0 --ultra -100500 -v - > initrd.zst
Note: 8 physical core(s) detected
Warning : compression level higher than max, reduced to 22 
(L22) Buffered : 932 MB - Consumed :   2 MB - Compressed :   0 MB => 33.15%   
# du -sh initrd.zst 
173M	initrd.zst
# du -s initrd.zst 
176432	initrd.zst

zstd = 173M

А разговоров то было.... Ну, справедливости ради стоит отметить, сильная его сторона вовсе не в возможностях сжатия, а в скорости распаковки. Условную планку «xz» по уровню сжатия пока ещё не преодолели.

Теперь давайте взглянем на альтернативный метод предоставления системы из initramfs, как «слой» с использованием SquashFS с сохранием данных в tmpfs.

# mkinitramfs `mktemp -d` --overlay gentoo --squashfs-xz --output $PWD/initrd.squashfs.xz
Parallel mksquashfs: Using 16 processors
Creating 4.0 filesystem on /tmp/tmp.scQzUt6MLO/overlays/10-gentoo, block size 1048576.
[============================================================] 53192/53192 100%
# du -sh initrd.squashfs.xz 
217M	initrd.squashfs.xz
# du -s initrd.squashfs.xz 
221292	initrd.squashfs.xz

squashfs.xz = 217M

Вот это да, initramfs с системой упакованной в squashfs + xz получился немногим больше чем просто initramfs + xz.

Какие из этого можно сделать выводы?

• Если вы ограничены в объёме RAM, но хотите работать в tmpfs, тогда используйте squashfs + xz или squashfs + zstd.

# mkinitramfs `mktemp -d` --overlay chroot --output $PWD/initrd --squashfs-xz

• Если выделить пару-тройку GB под систему не проблема, тогда используйте overlay без squashfs, и будет вам уютный tmpfs без глюков самого overlayfs.

# mkinitramfs `mktemp -d` --overlay chroot --output $PWD/initrd

Специальный приглашённый гость: mkinitramfs из пакета ( https://github.com/sp00f1ng/boobstrap ).

А всё это, как водится, реклама. А на сегодня всё. До новых встреч. :-) :-|

CRUX отличается своей стройностью, лёгкостью и лаконичным дизайном, ничего лишнего, в него входят только простые и проверенные решения, например start-stop-daemon из Debian для запуска демонов и signify из OpenBSD для валидации портов.

Репозиторий core полностью самодостаточен и при этом в нём нет ниодного лишнего пакета «просто чтоб было», т.е. имея установленный один только core можно во-первых, пересобирать систему (проще говоря @world) целиком хоть до посинения, во-вторых, отталкиваясь от одного core, собирать всю остальную систему целиком, а это X11, и далее по списку все остальные приложения. «просто чтоб было» уходит в opt репозиторий, то, что может пригодиться, например linux-firmware, ppp, wpa_supplicant и всё тому подобное, что необходимо введения дистрибутива в рабочее состояние на десктопах. Ну и xorg, сооветственно, для «рабочего стола». core, opt, xorg наше всё.

Единственное, что могло угрожать существованию этого упорядоченного мира, это смуззихлёбы, которые решают, что для сборки gcc теперь нужен python3, и этот день к сожалению настал. А если gcc без python3 невозможен, и нами не будут придуманы обходные пути наименьшего сопротивления, значит теперь python3 придётся включать в core. Не мы такие, жизнь такая.

Релиз CRUX 3.6 состоится, как он только будет готов (ц), но тем временем можно подготовиться и узнать, что же нас ждёт.

https://crux.nu/Wiki/TODO36

• gcc теперь требует python3 для сборки ( https://sourceware.org/legacy-ml/libc-announce/2019/msg00000.html ), а значит скорее всего, python3 включат в базовый состав дистрибутива, репозиторий core.

Если вам нет никакого дела до CRUX, вы подумайте, что тоже самое ждёт абсолютно все дистрибутивы, включая Linux From Scratch.

• zstd просто ещё один архиватор, как gzip, bzip2, lzma и другие. Пусть будет.
• Новая версия dhcpcd потребует отдельного пользователя для запуска демона, ну ок.
• libuv, которая не сделает погоды.

Такие дела.