Asgard RC1 на том же старом ноуте

Первый псто темы и ридми на гитхабе читал? Установщика нет и пока не предвидится. Загрузка - исключительно с флэшки или сидюка. Если на флэшку - то да, через dd. На хард не рекомендую вообще (по крайней мере, persistent storage, как в хромоси, будет, но не скоро, так что сейчас установка на хард бесполезна в принципе).

А знаешь, Ш действительно не Г.

Радугу очень отчетливо видно. Да и ШГ есть.

Увеличиваешь скриншот в 50 раз? А я просто пользуюсь и мне нормально.

В один раз увеличиваешь и всё видно.

А я просто пользуюсь и мне нормально.

Ну ок.

Добавил байтбит-плеер (классический: выражения на чистом си, переменная t, выход Unsigned 8 bit 8Khz PCM). :bb <формула> играет, :bb без параметров останавливает. Понятно, это уже не RC1, но кто будет из гита собирать - можете заценить.

Зы. Кто-нибудь что-нибудь потестил уже?

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

Наконец-то попытался собрать. А зачем было полностью переделывать конфиги syslinux, выкидывая из них x86_64 как класс? В итоге, x86_64 образ (собранный «как есть») не бутится.

К слову, перемонтирование корневой ФС из ~/.bash_profile выглядит как неимоверный хак. Настраивать звук лучше из .xinitrc, а запускать иксы таким образом просто некорректно, т. к. TTY не обязана существовать при исполнении этого скрипта. Из ~/.bashrc немного лучше, но всё равно — например, это будет глючить при логине по SSH.

Почему бы не запускать иксы из systemd, благо в 1.16 это можно делать без вспомогательных бинарников, прямо из юнита? Я сейчас запилю proof-of-concept.

Правильно, поэтому не вижу смысла в твоем комменте.

И ещё: ты не скопировал в дерево archiso-специфичные хуки initcpio. Как результат, используются хуки из установленной на сборочной системе archiso, и при несовпадении версий (а оно в настоящий момент имеет место быть) сгенерированный образ получается в принципе неработоспособным.

Адын. Хуки я вообще хочу почти все выпилить к чертям. Всякие PXE и NFS конкретно здесь не нужны.

а запускать иксы таким образом просто некорректно, т. к. TTY не обязана существовать при исполнении этого скрипта

Всегда существовала, а теперь вдруг перестанет?

Из ~/.bashrc немного лучше, но всё равно — например, это будет глючить при логине по SSH.

Напоминаю, что речь о лайве, какой SSH? Там даже SSH-сервера нету.

А зачем было полностью переделывать конфиги syslinux, выкидывая из них x86_64 как класс?

Чтобы бутить обычный x86 без какой-либо задержки и левых меню.

Всегда существовала, а теперь вдруг перестанет?

Ты, как и многие, путаешь bash_profile и bashrc. Первый подтягивается только при входе в систему, в т. ч. из дисплейного менеджера (через Xsession). Второй — только при запуске интерактивных оболочек (в т. ч. уже после логина, например, при запуске эмулятора терминала или вложенного шелла).

Напоминаю, что речь о лайве, какой SSH? Там даже SSH-сервера нету.

Когда (если) добавишь, будет глючить.

Чтобы бутить обычный x86 без какой-либо задержки и левых меню.

TIMEOUT 0?

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

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

Когда (если) добавишь, будет глючить.

Опять же, не будет его там в принципе.

TIMEOUT 0?

И что загрузится при TIMEOUT 0? DEFAULT, я так понял, на мультизагрузке указывать нельзя?

Второй — только при запуске интерактивных оболочек (в т. ч. уже после логина, например, при запуске эмулятора терминала или вложенного шелла).

Вот именно поэтому я и не использую bashrc. Поскольку уже в загруженной системе можно сделать :run xterm или что-то, что его использует.

Конечно, смотрел. Тем не менее, это костыль (хоть и работающий), и человек, который захочет форкнуть асгард и добавить в форк какие-то фичи из вышеперечисленных, будет вынужден его выпилить и сделать по-нормальному.

Естественно, как хочешь — просто я сторонник нормальных решений (забивания гвоздей молотком и вкручивания шурупов отвёрткой, а не наоборот).

Первый пункт из списка, но что такое «мультизагрузка» и почему там нельзя указывать DEFAULT, я не понял...

В любом случае достаточно выпилить из archiso_head.cfg визуальщину (заменив vesamenu на menu и убрав сплэш), дописать туда TIMEOUT 0 и опционально выпилить весь archiso_tail.cfg.

Ну, смотри. Я указал дефолтом 32-битную версию. Толку от 64-битных пунктов в таком случае? Может, я не доконца въехал в доку сислинукса и не понял всей сермяжной правды, но выпил ненужных пунктов показался самым логичным решением.

Кстати,

Хуки я вообще хочу почти все выпилить к чертям.

Все не выпилишь. Так что тебе придётся либо таскать их с собой, либо перепилить под archiso-17.

А зачем ты указал её дефолтом? В оригинальном archiso всё было правильно сделано: если бутимся на 32-битном процессоре, то инклюдим только 32-битные пункты. В ином случае — инклюдим сначала 64-битные, затем 32-битные.

Если туда впиливать дисплейный менеджер, всё равно придется переносить в сессию этого менеджера всё, связанное с автозапуском.

Ну вот в эту логику я, значит, не въехал. Перепилю.

А, да, там есть пункты с UEFI, загрузчик для которого в моём build.sh не собирается, ибо он жестко зависит от x64.

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

Если человек форкнул асгард, чтоб впилить туда DM и sshd, то он как минимум неверно выбрал базу для форка. Это как переделывать роутер в игровую консоль. То, что считается "по-нормальному" в дистрибутивах общего назначения, совершенно не обязательно будет нормальным на узкоспециальных вещах. Ну, вот ты можешь себе представить SLIM в хромоси? Лично я - нет (там, конечно, логин есть, но это вход в гуглослужбы, который к линуксовому логину отношения не имеет: системный юзер там, как и в асгарде, всегда один, если не считать рута).

А эта схема автовхода была проверена и на обычном арче, и на минимальных дебобунтах, и на одном вообще лютом самопале, почившем во мраке прошлого (нет, не LFS, суровей)... и нигде она сбоя не давала. Если есть предложения, как можно ускорить загрузку (например, с помощью того же системд) - я готов их выслушать. Но ради "академической правильности" стараться не готов.

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

Штеудач, ты не в курсе, netctl как-то можно заставить юзать встроенный в systemd dhcp-клиент, или это только слухи, что он там есть? И ты там ещё говорил насчет какого-то PoC быстрой загрузки иксов из системд, тоже интересно.

• он там есть, но нельзя, systemd-networkd пока что не умеет перенастраиваться на лету
• чё-то не было времени особо допилить, иксы я вроде запустил, но без приложений (xinitrc) — надо подумать, как поэлегантнее их запускать.

Можно поподробнее? // кода перед глазами нет, но почему бы просто точечно не выпилить EFI-специфичные вещи?

А, ну, это лазить по тому же сислинуксу (64-битной части) вслепую, тестить-то, опять же, не на чем. Короче, это всё будет на выходных уже.

А с чего ты решил собрать 64-битную версию вообще?

Ну, нет желания скачивать >9000 пакетов другой архитектуры.

Более того, нет ни места (SSD — все разделы вполне себе под расчёт), ни пропускной способности (жопорез форте, т. е. 3G).

Ну я ж говорю, я перестраховался насчет сислинукса, т.к. технически возможности тестировать 64-битную хурму у меня нет. А вот с хуками... напомни ещё раз, что там с хуками не так? Что именно таскать надо?

pacman -Qql archiso | grep '^/usr/lib/initcpio', и соответственно поправить пути в build.sh.

Там приходится щас много чего править. Это же надо было в только вышедшей версии archiso ТАК поломать обратную совместимость! /me негодуэ, но как только отлажу, сразу пушну на гитхаб.

Норм. Там обратной совместимости в принципе не предусмотрено — какая вообще может быть обратная совместимость относительно внесения исправлений в код? =)

Зато обновились e2fsprogs, косяк с размерами образов >2048 мег исчез.

А там не только исправления в код. У меня оверлей лежал в каталоге root-image, откуда я мог знать, что после обновления он должен уже лежать в airootfs?! Они это поменяли, название .sfs-образа поменяли, ну и в коде везде root_image на airootfs поменяли. И вот настал великий перепил.

Короче, под новый арчисо перепилил, собрал - УМВР наконец-то. Пушнул.

PS. Ну они могли оверлей не трогать? Ну они могли вообще название каталога с оверлеем не хардить в 100500 мест? Трындец.

На ЛОРе есть реклама? Не знал;-)