LFS. Часть 7. LFS собран! Обе версии - systemd & sysVinit

АААА! Этот день будет вписан в историю великой страницей! Нуу, на самом деле не такой уж и великой, но у меня давно в жизни ничего великого не происходило, поэтому всё зависит от точки зрения, верно?

Обе версии LFS строятся одинаково примерно до середины, после чего разветвляются - на одну версию ставится systemd, на другую продолжаем ставить обычные пакеты и ближе к концу sysVinit. С самого начала я задумывался о том, что надо бы попробовать две версии и посмотреть, чем они отличаются. Но прям с нуля каждую это долго и никому не нужно. 5я глава для них общая, различия начинаются в середине шестой.

Перед установкой systemd я сохранил копию будущей системы, после чего поставил systemd, оставшиеся пакеты, и начал геморроиться с ядром. Которое не загружалось. Дык вот, вооружённый знаниями, прихожу с утра на работу и смотрю - все те модули, которые я говорил, у меня вкомпилены в ядро. Так хер ли ж оно не загружается? Проверяю ещё раз - загружается! Проверяю предыдущее - тоже загружается и так все варианты ядер, которые я собрал, включая самое первое ядро! (( Мистика, сука-блядь! В чём же было дело? Ну, я использовал как вспомогательный диск с Arch-linux, и у арчеводов принято делать метки на разделах диска и ссылаться на эти разделы через метки или через UUID. То есть, в grub.cfg они пишут так:

linux /vmlinuz-bla-bla-bla root=<b>LABEL=root</b> ro

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

linux /vmlinuz-bla-lba-bla root=<b>/dev/sda2</b> ro

Архаично? Ну, возможно, зато работает. В общем, все мои ядра загрузились с параметром /dev/sda загрузились только в путь. Как это объяснить. Ну, типа udev умеет распознавать LABEL & UUID, поэтому, если в initramfs есть udev, то это сработает, а если нет, то нет. Но я вчера напоследок загружался с initramfs, в котором только base, никакого udev, и неожиданно - оно распознало LABEL. В общем хуй знает, этот ебучий Линукс полон загадок.

Ободрённый успехом, что ядро загрузилось и LFS 8.1-systemd собран, я поднапрягся, докомпилил недостающие пакеты в версии sysVinit, создал новую виртуальную машину, захерачил всё туда, собрал ядро и запустил ещё один LFS! Второй раз всё происходило быстрее, понятное дело. Примечательно, что у ютуберов, собирающих LFS видео сборки тоже получается примерно в 7 частях.

На радостях я даже зарегился на их сайте и похвастал своим достижением!
Ура, товарищи!

@темы: Linux, LFS

---

Великий и ужасный LFS. Часть 6. Ненависть!

Ебаные красноглазики, сука-блядь, поубывав бы! Чо-то нахуевертят, напидорасят, блядь, своими руками ижжопы! Десять конфиругационных файлов, один ссылается на другой, якобы, чтобы было "удобно". Хочешь что-то изменить под себя и понимаешь что надо менять сразу в нескольких местах.

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

Но обо всём по порядку. Я откомпилировал всё это говнище, которое перечислено в их книжке-инструкции и даже немножко постиг дзэн ГНУ-Линукса. Казалось бы, всё! Ещё немного, и ты получишь результат, ради которого столько ебался. У меня впереди было два тихих выходных на работе. Один день я потратил, чтобы перенести эту хрень с каталога на виртуальный диск плюс ещё докомпилинг доп.пакетов. Ну, тут они ни при чём, с каталога на диск это моя инициатива - они в самом начале предупреждали, что нужен хотя бы отдельный раздел. Второй день я целиком посвятил ебле с ядром. Безрезультатной.

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

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

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

Во FreeBSD и вообще в *BSD такой хуйни нет, и ядро там - загружается. Зато в *BSD есть много другой хуйни, которая сводит на нет все преимущества, и о которой мы поговорим позднее. Может быть.


Дык вот, а не похуй ли нам? Ну загружается как-то там и ладно. Мне в общем тоже было похуй до того момента, когда в LFS наступил последний шаг - сборка ядра. Они там предлагают собрать ядро БЕЗ initramfs. Ядро собирается, стартует, но подцепить диск не может. Теоретически, если вкомпилить в ядро нужный модуль, точнее, несколько нужных, оно загрузится. Но только на этой машине, а если на другой машине стоит другой драйвер диска, то там оно снова споткнётся. Но это дело будущего, а сейчас надо хотя бы понять, какой драйвер подоткнуть и как.

И если в память загрузить в initramfs одинокий драйвер без ничего, догадается ли ядро его там найти или ему кто-то должен сообщить? Ядро при загрузке выдаёт какую-то малоинформативную хуйню вроде Dump stack: 0x100ff и дальше куча цифр. Можно ли это как-то использовать или нет, хз.

Вообще, я никогда до этого не конфиругил ядро в Линукс. Не было необходимости. А вот во FreeBSD - конфирурил, и оно загружалось! Как дело было во FreeBSD - ты открываешь текстовый файлик и правишь параметры. Там куча комментариев, в которых написано, что за параметр и в каких случаях его включать. В целом несложно. Выкидываешь то, что ненужно - поддержку всяких накопителей на магнитной ленте, перфокарт, перфолент и прочего, чего у тебя никогда не будет. Добавляешь то, что нужно - какой-нибудь там IPFW2, NAT и прочее, и потом компилишь.

В Линуксе перед тобой открывается шикарный псевдографический интерфейс с менюшкой с подменюшками. По нему можно лазить. А ещё есть графический тырфейс - аж целых два. Ух ты! - подумал я, почему же во FreeBSD до сих пор никто ничего такого не сделал? Потому что нихуя непонятно, что же ты на самом деле правишь. Ну или надо знать. Я скоро перешёл на текстовый файлик - так быстрее. В менюшке написано "Поддержка SCSI", ты включаешь, а что ты там включил - хер его знает. А в тырнете тебе пишут:
CONFIG_SCSI_MOD=y
CONFIG_SD_MOD=y
и именно это ты должен найти в файлике и включить. Нередко в разных местах.

Я нескоко раз пересобрал ядро с разными вариантами:
make menuconfig - запускает меню для конфигурации
make defconfig - стандартное ядро
make localmodconfig - собираем ядро со всеми модулями, которые есть на текущей машине
make localyesconfig - то же, что предыдущее, только модули вкомпилены в ядро
make nconfig - не помню, то такое тоже есть

Методом научного тыка и неистового гугления (вы же не думаете, что я бездумно собирал ядро?) я накопал, что у меня в VirtualBox используется
00:0d.0 SATA controller: Intel Corporation 82801HM/HEM (ICH8M/ICH8M-E) SATA Controller [AHCI mode] (rev 02)
Для него нужны чо-то там AHCI. Модули, которые я нашёл в /lib/modules на своей машине
ahci.ko
libahci.ko
libata.ko
ahci_platform.ko
libahci_platform.ko
В общем чо-то типа того. В Гугле рекомендовали включить CONFIG_SATA_AHCI, CONFIG_SCSI_SATA_AHCI и мож ещё парочку. В LFS-машине можно прочитать файлик /lib/modules/4.12-7/modules.builtin - модули, вкомпиленные в ядро. Я получил все, кроме libata.ko

К вечеру я заебался, спиздил ядро и initramfs из Арча и подсунул его на свой LFS-диск. Похуй, что в LFS версия ядра 4.12, а в Арче 4.13, моё ядро вместе с Арч-initramfs загрузилось, а вот ядро Арча без своей initramfs - нет.

В GRUB2 тоже есть модули - файлы с расширением .mod (а у ядра с расширением .ko). Они нигде толком не описаны, хотя нет, пижю, вот апесание
blog.fpmurphy.com/2010/06/grub2-modules.html
Как я понял, это не то же, что модули ядра, это скорее как команды загрузчика. Например boot, linux это отдельные модули. Впрочем, иногда несколько команд упаковывается в отдельный модуль. Эти модули могут помочь загрузчику в загрузке ядра, а вот могут ли они помочь ядру - хер знает.

Я ваще прочёл несколько серьёзных (или пытающихся казацца таковыми) книг по Линуксу и нигде не сказано, как именно ядро определяет из всех драйверов нужный. Вот "как-то там" определяет.

Почти весь следующий день убил на то, чтобы разобраться как же собрать без Initramfs. Нашёл на archwiki, как в Арче генерится файл initramfs и как управлять его конфигурацией. Делаем так:
cd /etc/mkinitcpio.d/
cp linux.preset linux-1.preset
vim linux-1.preset
В нём правим ('default') на ('normal'), initramfs-linux.img на initramfs-normal.img, default_image на normal_image
normal_options="-S udev,keyboard,filesystem,fsck,block,autodetect,modconf" #тут перечисляем, что нужно исключить из будущего initramfs. Через запятую. А взято оно из строчки HOOKS=(... в /etc/mkinitcpio.conf
Сразу скажу - исключить можно всё, кроме base. Hook "base" содержит процесс init, без которого всё загибается.
В /etc/mkinitcpio.conf надо в пункт MODULES=() включить те модули, которые нам нужны. Как узнать, какие? Эт я определил на своей виртуалке под Арчем с помощью modinfo & lsmod.
Запустить LFS надо на той же самой виртуалке = оборудование одинаковое. ??? PROFIT!
lsmod перечиляет загруженные модули, modinfo module_name|grep depend даёт строчку модулей, которые зависят от module_name. А значит, если ты загрузишь один из них, module_name подгрузится автоматически, как необходимый. Загружено было около 70 модулей, из них я отследил следующие связанные:
ahci, libahci, libata, ata_piix, ata_generic, pata_acpi, scsi_mod, sd_mod, sr_mod, cdrom
Вот про scsi_mod & sd_mod хер бы я когда догадался сам. Я-то всё задрачивал на *ahci* & *libata*.
Короче, в стоку в /etc/mkinitcpio.conf включаем следующее MODULES=(ext4 ahci sd_mod). Остальное всё подгрузится автоматически. В HOOKS там же можно включить HOOKS=(base) и тогда скомандовать mkinitcpio -p linux-1, после чего в /boot окажется компактный initramfs-normal.img.
Надеюсь, это всё вам очень пригодилось. Следующим пунктом исследований будет как вкомпилить всю эту хрень в ядро и загрузится ли ядро без initramfs в принципе? init-то у него не будет.

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

@темы: Linux, LFS

---

Хочу перевести с английского книжку по LFS

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

www.linuxfromscratch.org/lfs/downloads/stable-s...

И не знаю, как это делать, чтоб быстрее шло - открываешь два окна, в одном текст, в другое печатаешь, так, что ли?

@темы: Linux, LFS

---

Великий и ужасный LFS. Часть 5.

Короче, камрады, если кто будет собирать LFS, лучше собирайте на отдельном диске или разделе.

Но обо всём по порядку. В эти выходные у меня были наполеоновские планы закончить наконец это дрочево. Возможно, прямо в субботу. В субботу пришёл на работу и вперёд! Сначала доустановил проги, которые там рекомендовалось - lynx, openssl, openssh, dhcpcd, sudo, wget, gptfdisk & gparted. Начал с openssl. Оказывается, тесты для него надо выполнять не из-под root. А то будут траблы. Все эти проги входят в книжку BLFS. А для неё нету логов компиляции (наверное, до хрена места занимают) соответственно, если при сборке возникают ошибки, непонятно - это нормально или надо пересобирать.

Тесты openssl под root провалились, под nobody прошли. Дальше ставим openssh. Снова тесты под nobody. Вываливаются с сообщением чо-то там nobody HOME=/dev/null No such file or direcrory. Чо за фигня? Задумался. Оказывается, у nobody не определена домашняя папка. Делать нечего, создал полноценного пользователя user. С домашним каталогом и всеми делами. Там этот ssh создал ключи и тесты отхерачил. Собрал остальное. Там под каждый пакет есть минимум один дополнительный, который тоже надо поставить. Это уже заебало. Апофеозом был gptfdisk, которому нужен какой-то popt, чтобы собрать прогу sgdisk и ICU, чтобы метки писать в unicode. Не знаю, чо за sgdisk, но мож нужное чо-то, поэтому popt скачал и поставил, потому качаю ICU, начинаю собирать, оно медленно собирается, а я и думаю - вот нахер мне в unicode метки писать? Скоко раз я буду разбивать диск с помощью этой проги? Скорее всего 0, а если очень повезёт, то один. На каком языке я буду давать метку? На китайском штоле? Правильно! Скорее всего на английском. Потому что если написать на русском или турецком, в другой программе можно обрести геморрой. Поэтому метки дисков все и пишут на Энглише - не выёбываются. Прервал сборку этой ICU, грохнул исходник и собрал без неё. На всю эту хрень убил несколько часов - пока ошибки разберёшь, пока то-сё.

Теперь мне предстоял квест по переносу содержимого из папки на виртуальный диск. В прошлый раз я установил на виртуалку Арч, сегодня он успешно запустился, правда, не сразу. Я пробросил туда ssh, подцепил второй виртуальный диск и через scp поставил копироваться. Копируется минуту, другую, третью, какие-то файлы пошли двоичные с расширением s2ml. Чо за херня? - думаю. Посмотрел в тырнете - это ж Старкрафт! Оказалось, что в безопасном и защищённом Линуксе эта хрень каким-то образом через /home/lfs/lfs/var/run/media/... вылезла на соседний диск и всё оттуда перекачивает. Уже 12 Гб дерьма!

Прервал, думаю, как так? Вроде отмонтировал всё перед запуском, проверял специально. Проверяю ещё раз mountpoint var/run - является точкой монтирования. Отмонтировал - всё равно является. umount --force, ему пох. Перезагрузился. Всё равно. Таких папки в var две: lock & run. Горят светло-голубым дьявольским огнём. Заходишь внутрь, а там куча файлов и каталогов! Переменовываешь - пох. Перед этим делом я сделал резервную копию lfs - lfs_bckp. Захожу в lfs_bckp/var/run, а там - та же херня! Мистика! Оказалось, это симлинки(ярлыки)! Указывают на /run & /run/lock! Конечно, бля, там будет куча файлов. И ваще, что за умник догадался засунуть в /var симлинки на /run да ещё и /run/lock? Есть же /run в корне, её прекрасно всем видно, хер ли ему не хватает-то? Он бы ещё на десять уровней вглубь бы их захерачил, чтобы точно никто не нашёл! ((

команда cp позволяет не следовать по симлинкам. А в scp такой опции нет. Что делать? Попробуем через общие папки в виртуалке. Проблема в том, что Х-ы подо мной, VirtualBox тоже подо мной, а собирал я под lfs - прав у меня нет на его папку. Решил на корень lfs дать права себе, а дальше мы подмонтируем и в виртуале уже будет root. Подмонтировал, копирую, cp не хочет копировать некоторые файлы. Там суидный бит. А ещё на некоторые файлы права не root:root, а root:какая-то левая группа. Которой нет ни на моей машине, ни на виртуалке. Только в файлах lfs. cp при копировании ставил root:root.

Почитал тырнет - самый верный способ - сделать архив и распаковать его там. Делаем архив:
tar cvf --numeric-owner --same-owner --preserve-permissions lfs_bckp lfs
Сделал, перекачал на виртуалку, распаковал - красота! Всё сохранилось - права, суидные биты и прочее. Смонтировал там всякие /dev /run /sys и прочее, перешёл в chroot, а времени уже до хера. Читаю про конфиг ядра. Открываю, там менюшка неебовая, короче, опять читать надо, что отмечать, что нет, а уже пора домой валить - время 21:30.

Если бы собирал на отдельном разделе этой херни бы не было, сэкономил бы несколько часов. Вот такая у меня потрясающая эффективность! И этот человек хочет учить других Линуксу ыыы. Хотя... Кто умеет - работает, кто не умеет - руководит, кто не умеет руководить - учит. Так что всё по канону.

Во FreeBSD и Windows такого дерьма ни-ког-да бы не случилось! Потому что во Фри нет всяких виртуальных run'ов и прочей хуйни, а в Windows ярлык это блядь просто ярлык! Там можно сделать похожие симлинки, но - не нужно.

@темы: Linux, LFS

---

Великий и ужасный LFS - Часть 4. Вторая установка Arch (внеплановая)

Итак, камрады, я докомпилировал 6ю главу LFS ещё во вторник. Начал читать про 7ю главу про настройку и прочее. Посмотрел видео одного перца, дык там он за 25 минут прошёл 7,8,9 главу и загрузился в LFS. Ободрённый его успехом я с новыми силами ринулся в среду на бастион. Прочитал 7ю главу повторно, внезапно всё стало понятно. Создал конф.файлики.
Нужно удалить отладочные символы из системных библиотек и пакетов (это называется striping) для уменьшения места. Но перед этим надо сохраниться.
14499 Мб=14,5 Гб - размер системы до операции
13672 Мб=13,7 Гб - после. Мы спасли целых 828 Мб!
Потом я решил удалить распакованные исходники (во время компиляции я их не удалял, плевал на инструкции)
2401 Мб=2,4 Гб фига се! Вот это эффект! Мож не стоило эти сраные символы трогать, достаточно исходники было удалить. Это токо распакованные исходники. Архивы tgz там ещё остались. Ну да ладно.

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

У меня на компе лишних дисков нет, собирал всё в папке. И основной загрузчик я трогать не хочу. Поэтому будем делать всё на виртуалке. Для этого нужно как-то закинуть содержимое на виртуальный диск.
Сначала я думал подмонтировать виртуальный диск к основной системе и перелить всё на него, но ни хрена не вышло. Не знаю, чем подмонтировать. Вроде есть какой-то пакет virtualbox-fuse, но в основных репозиториях его нет. Мож надо какой-то сторонний подключить, хз, это разбираться надо.
Тогда я решил подмонтировать содержимое к виртуалке как общую папку, но на пустой виртуалке этого сделать нельзя.
Тогда я решил загрузиться с LiveCD, пусть это будет Arch - он маленький, всего 523 Мб. Скачал, запустился. Но, оказалось, без guest additions общие папки всё равно сделать нельзя, а установить их можно только на нормальную систему. Тогда я решил "по-быстрому" установить Arch. (Это как бы намекает на аццкую сложность его установки). Разбил диск в GPT, а на виртуалке BIOS. EFI написано "только для ОС специального назначения" и я его зассал включать, но это и хорошо, т.к. для UEFI на диске нужен специальный раздел размером 500Мб, а нах он нам там нужен?
Arch поставился без проблем, ставлю загрузчик GRUB, а хер там, ошибку пишет. Оказывается, ему нужен маленький раздел, буквально 1Мб для BIOS-boot. Тороплюсь, 1Мб создать не получилось, грохнул бутовый раздел 100Мб в начале диска, создал этот BIOS-boot 1 Мб и 99Мб бутовый раздел для Linux. Сделал grub-install, написал grub.cfg, гружусь, а хер там - ядра нет в /boot. Сначала я поставил Arch, потом грохнул /boot, и там было ядро. Надо его переустановить. А времени уже не осталось, и пошёл я домой. В выходные точно добью эту хрень.

В четверг меня мысли одолевают - ну допустим, поставлю я Arch, надо вкрячить guest additions, чтобы общие папки были доступны. Дома же есть Arch, можно значит попробовать. Подцепляю диск guest additions - конечно, ни хера не ставится. Лезу в тырнет, оказывается, на Arch-wiki прям расписали чо как делать для virtualbox и даже пакеты специальные есть - те же guest additions, но проверенные. Я от такого сервиса аж охуел. Во виртуализация как далеко шагнула! Раньше как было - есть у тебя, допустим, vmware, к нему чо-то там прилагается, не работает, вот и ебись! Это проблема твоя и vmware. А щас не так. Ща виртуалки токо ленивый не запускает, и, видимо, как производители, так и пользователи уделяют повышенное внимание тому, чтобы всё работало без гемора.

Ставлю пакеты - не ставятся. Уже, говорят, стоит там уже guest additions, которые с диска. Наполовину встали и зафейлились. А чо толку, что они стоят, они ж не работают. Полез смотреть. Это всё софт-линки, а сами guest additions поставились в /opt. Линки я удалил, и пакеты встали. Сразу общие папки появились, экран больше стал, ваще красота!

@темы: Linux, LFS

---

Великий и ужасный LFS - Linux-from-Scratch Часть 4

Продолжаем собирать ебучий LFS. Я честно гря уже заебался, но не потому, что это сложно, а потому что думаешь бля, сегодня уже закончишь, а хер там, продвигаешься на чуть-чуть всего, а я уже хотел бы прихвастнуть перед коллегами новым LFSом. Почему так долго? Ну, например, собираешь какой-нибудь ебучий пакет. Запускаешь на нём тесты (прилагаемые к пакету) Тесты валятся с ошибкой. Может это хуйня, а может и нет. Если хуйня, можно продолжать, а если что серьёзное, может получиться так, что дальше что-нибудь не соберётся и всё равно придётся возвращаться обратно.
В пятницу я немного дособрал и остановился перед пакетом systemd. Пакеты нужно собирать в определённом порядке, так как некоторые пакеты требуют присутствия других пакетов в системе на момент установки. Но не все. Я осмелел и поставил сначала команду less, хоть она впереди хер знает где. Сначала проверил её зависимости на своей хостовой системе через rpm -qR и ldd, в книжке про зависимости тоже ничего не написано. less скомпилилась и поставилась. Теперь работает. Но мож подвох какой потом выяснится. Потом нашёл пакет which и поставил его. Нашёл в тырнете, но потом подглядел в книжке BLFS 8.1, какую версию надо ставить и как. Никаких хитростей, which собралась и тоже работает. А тут надо сказать, что щас есть две версии LFS - с systemd и с sysvinit. Я подумал, почему бы не собрать их обе? Сделать это просто - надо скопировать сейчас перед установкой systemd всё, что я уже поставил и на одну копию поставить systemd и остальные пакеты, а на другую sysvinit и его пакеты в очерёдности, которая указана в нужной версии книги. Так я подумал и ушёл домой. Дома у меня родился хитрый план. Что там, что там пакеты одни и те же. Нафига спрашивается два раза их ставить на обе копии, если можно сначала поставить все общие пакеты, а под конец оставить systemd с d-bus или sysvinit, ksyslogd & Eudev.

На работе с утра я поискал о зависимостях и обнаружил глюк. В обеих версиях книги в Приложении С указаны зависимости для sysvinit. Об чём я набрался наглости написать авторам проекта. Ещё раз внимательно перечитал 6ю главу - всё-таки есть пакеты, зависящие от systemd и требующие его наличия в системе до установки. Это, например, coreutils. util-linux. Ещё он же встречается в зависимостях для Kmod & Xz. Кто там от кого зависит, хз, но факт имеет место быть. Подумал, и решил собирать по инструкции. Сделал резервную копию, потом поставил systemd. Дальше поставил два пакета более менее без проблем и застрял на coreutils. К нему прилагается патч, причём написано, что в патче в своё время находили много глюков, поэтому проверьте, может, новый вышел. Вот она, сука-бля, самая совершенная и безопасная система в мире. coreutils, между прочим не последнее место в ней занимают, как ясно из самого названия. Это команды, которые используются каждый день. Начал собирать, делаю тест, ошибку выдаёт, падла. Ошибка на тесте test/mv/sticky-to-xpart. В логах на сайте LFS этот тест пройден, в тырнете похожая ошибка обсуждается один или два раза. Нашёл видео какого-то перца, дык и у него тест прошёл. Ладно, думаю, попробую пройти дальше. Дальше тоже выдало ошибки. Стал ковырять логи. Чо-то там пишут про selinux. Отключил, помогло. Перекомпилял для чистоты. Первый тест норм, следующий прерывается с ошибкой, а на сайте логи дальше идут. В инструкции приведена команда make RUN_EXPENSIVE_TESTS=yes check, и если верить логам, у них всё шоколадно - делает два теста, в каждом по 1 ошибке, но идти продолжает. А у меня останавливается на первом из-за ошибки. Попробовал make RUN_EXPENSIVE_TESTS=yes -k check, проканало.
Ошибки выдаются на тестах misc/date debug и test-getlogin, об чём написано в инструкции. Решил продолжить, но сомнения гложут - у них в инструкции нет ключа -k и типа дальше проходит, хотя ошибки точно такие же, а мне вот ключ пришлось поставить. И целый час на эту херню убил ((

Осталось немного до седьмой главы, где начинается новый ебаторий - конфигурация.

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

Начинается всё с того, что мы собираемся компилировать систему. Что нам для этого нужно? Первым делом - компилятор, компоновщик, и библиотека языка (о которой часто забывают). Если речь идёт о С, понадобится ещё ассемблер, т.к. С транслирует сначала в него. Если речь идёт ещё и о С++, то понадобится ещё и препроцессор и библиотека для С++.

С этого LFS и начинает - первым шагом собирается компоновщик с ассемблером. Потом сразу же компилятор. Причем, устанавливается в /tools/bin. /tools/bin не похож ни на один из стандартных системных путей типа /usr /bin /sbin и т.д. Таким образом, это гарантирует, что случайно не запустится утилита с хостовой системы, а только то, что мы поставили в /tools/bin.

Потом собираются заголовки ядры и библиотеки для С и С++ (glibc & libstdc++). Компоновщик и компилятор были собраны хостовыми инструментами и испытали на себе "влияние" хостовой среды. В частности, то, что в бинарниках прописан (насколко я понял) хостовой компоновщик и хостовые библиотеки. Теперь, когда у нас есть свои библиотеки в /tools/bin, мы пересобираем заново компоновщик и компилятор. Т.к. они собраны в среде /tools/bin, то испытают на себе "влияние" уже этой среды - в них будут прописаны пути /tools/bin и они же будут прописываться во всех компонентах, которые мы теперь будем собирать.

Дальше меня смущает, что мы не пересобираем библиотеки С и С++ (glibc & libstdc++), как можно было бы подумать, а продолжаем собирать остальные пакеты. Хрен знает, возможно, именно эти библиотеки неподвластны "влиянию" среды, т.к. туда некуда прописывать путь, а возможно вообще все библиотеки неподвластны. Рано или поздно мы это узнаем.

Дальше мы собираем кучу пакетов, после чего начинаем с заголовков ядра, комплекта мануалов и библиотеки С - glibc. (видимо, это компоненты, не подверженные "влиянию"). Потом мы делаем "adjusting toolchain" - подправляем пути и подменяем компоновщик, чтобы он указывал не на /tools/bin, а на /usr/lib, /usr/include и т.д. Дальше собираем пакеты и инсталлируем их в каталоги будущей ОС, а дальше я пока не дошёл.

Раньше я думал, что glibc это один большой бинарный файл. Хер там. Glibc это пакет, в который входит куча мелких файлов-библиотек, составляющих функционал glibc + ещё несколько команд для установки временной зоны, функции для работы с файлами /etc/passwd & /etc/group + ещё локали и команды для работы с ними.

Я понял, что мало написать и отладить пакет. К нему нужен ещё набор тестов, который убедит остальных, что всё собралось и работает правильно.

Я понял, почему FreeBSD называют "логичной", а Linux - набором пакетов с кое-как прикрученным ядром. Дело в том, что сообщество FreeBSD разрабатывает всё вместе - ядро и обвязку. Изменилось у них что-то в ядре - они могут подогнать под это функционал команд. Могут менять код команд и ядра так, как им удобно. В Linux ядро разрабатывает отдельно одна группа разработчиков во главе с Линусом, а всё остальное разрабатывается сообществом GNU и им ещё надо совместно договариваться, как и что писать, чтобы их продукты можно было соединить в систему. Не всё разрабатывается GNU, что-то ещё кем-то другим пишется. Через это типа ядро Linux никогда не будет так плотно пригнано, как ядро FreeBSD. Странно, правда, что GNU за все эти годы так и не удосужилось разработать своё ядро.

Раньше я изучал команды "группами". Группы формировал по своему усмотрению. Ну или в книгах команды даются вместе, я их и читал. Дык вот, оказывается, очень удобно, хоть и не очевидно, учить команды пакетами. Например, в пакет e2fsprogs входят библиотеки и команды для работы с системами ext2, ext3, ext4. Команды очень разные по назначению, но выстроены вокруг файловой системы. В другом пакете будут например команды работы с текстом.

До хера ваще виртуальных файловых систем в Linux! Да, возможно, удобно, но всё равно многовато: /proc /run /sys /dev /dev/pts хуй прассыш! Кстати, пакет procps-ng выстроен вокруг файловой системы /proc. Во FreeBSD пока замечены /proc & /dev. Но наверняка скоро появится и остальное.

Раздобыл книжку How Linux Works Брайана Уорда. Читаю, вникаю. Всё началось с команд ldd & readelf, с которыми я познакомился в LFS.

Вот ещё нашёл статейку прикольную stoplinux.org.ru/project/FAQ_why_linux_suks.htm... Круто он их обосрал! Но это был 2009 год, и щас что мы видим? Прошло 8 лет, Linux по-прежнему в строю, тех микроядерных систем, про которые он говорил (Haiku, Syllable, AROS) не видно и не слышно, только Haiku вроде ещё пока существует, а сам он пишет какие-то унылые новости, а вот раньше жог просто пиздец, у красноглазегов пуканы взрывались!

Ещё вот бесило меня, когда набираешь find / он начинает искать по всем этим ёбаным /proc /run и т.д. Нашёл я вариантик - find -xdev или find -mount. Оставаться в пределах файловой системы. Если у тя токо /home и всё остальное на / (у меня на десктопе так), это очень удобно. Если /usr /var и прочее подмонтированы, тогда да, херня.
Версия для cp: cp -x чтоб не копировать опять же все эти /proc /run, а только то, что нужно.

Ладно, пока хватит, вникайте, а я спать пошёл

@темы: Linux, LFS

---

Собираем LFS Часть 3

Короче, я думал за эти два дня (пн, вт) уже закончу, но тут меня загрузили работой в кои-то веки. Как раз на два дня хватило. Конечно, после шести, когда все расходились, я филонил и продолжал собирать. Но сначала о том, что было до понедельника. В прошлую пятницу я остановился на сборке GCC из 6й главы. Это уже третья сборка GCC с начала книги.

Инструкция, скажем так, ненавязчивая, но спасибо, что хоть такая есть. Не помешало бы побольше объяснений для тупого меня. Первые два раза нужно было собрать его вместе с mpfr, gmp & mpc. Судя по командам, они копировались внутрь папки gcc и потом всё собиралось. В третий раз сначала шло три пункта сборки этих mpfr, gmp & mpc, после чего шла сборка gcc. Они, видимо, предполагают, что каждый раз ты заново распаковываешь архив сорцов. У меня это не так. Исходники после сборки я никуда не удаляю, потому что некогда - надо дальше собирать. Я собрал по отдельности mpfr, gmp & mpc. Они так и лежали в папке gcc. И, поскольку первые два раза gcc я собирал с ними в папке, также поступил и на этот раз. Каково же было моё удивление, когда gcc написал "не могу сконфигурить mpfr, кажется он уже сконфигурен". Озадаченный, я подумал "вот пидрилы!" и сделал make clean последовательно всем этим трём приблудам, после чего gcc таки собрался, я запустил тесты и свалил домой.

В понедельник продолжил. Тесты прошли нормально, делаем make install - устанавливаем всё, после чего идут ещё одни тесты. И тут мне энтот gcc вместо /lib64/... выдаёт /tools/... Хз, чо я там сделал неправильно, погуглил, ни хера не понял. Нашёл одного перца, у которого было похожее, и он подумал, что накосячил в пункте 6.10 и решил переделать всё заново. А сборка gcc это уже пункт 6.19. Чо делать? Неохота было возвращаться назад, поэтому я решил для начала сделать make uninstall. А нету такого пункта в gcc - не предусмотрен! install есть, uninstall'a нету (( Вот говно!

Ну я прикинул, щас надо чо-то соображать, а я ваще смутно понимаю, что мы делаем. Что если обычной перекомпиляции будет недостаточно? Он где-то час компилится, тестируется хз скоко ещё. Погуглил про сборку gcc. Оказывается, его можно собирать двумя способами - первый, приблуды собираются отдельно, второй - приблуды помещаются в папку gcc и собираются вместе с ним. Но совмещать два способа не получится. В общем, я подумал, что можно очень долго искать, а главное - безрезультатно. Особенно, если ни хера не понимаешь, что они там в своей инструкции делают. Быстрее всё заново сделать. Грохнул всю эту временную систему, из-за этого чо-то глюкануло, и когда я залочил комп, не смог зайти обратно - какая-то хрень творилась, пароль не набирался. Пришлось перезагрузиться, начал заново шестую главу. До ухода с работы успел продвинуться как раз до сборки gcc. Посмотрел видео на ютубе от EvilFreelancer'a, где он собирает LFS. Он в отличие от меня сразу сообразил, что в этот раз надо приблуды отдельно собирать. Фига се, думаю, по ходу дела и правда надо в этот раз их вынуть из папки. Причём, об этом ничего не сказано. Вот пидоры!

Во вторник между работой я успевал скармливать команды компилятору. С утра прошли тесты gcc, make install и снова post-install тесты. Я замер, но в этот раз он мне выдал всё правильно. Можно собирать дальше. Ура, товарищи! Окрылённый, я потихоньку продолжил, вечером задержался до 21.30, но всё равно не успел. Остановился на пункте 6.44, а их там 72! Честно говоря, уже заебало, хочется доделать побыстрее. Поначалу интересно, конечно, компилировать, но быстро утомляет. Ладно, скоро закончим.

Что я нового узнал или сделал?

- Ну вот, узнал про два способа сборки gcc и что у него нет make uninstall.

- Поковырял про make - хотел выяснить, откуда они берут все эти опции для сборки типа --prefix=/usr и т.д. А ещё как узнать, какие действия есть в конкретном Makefile, не открывая сам Makefile. Второе так и не узнал, а за первое отвечает вовсе не make, а configure. Если скомандовать:
./configure --help=short - выдадут все опции сборки с кратким объяснением (которого не всегда достаточно) ну хоть что-то.
./configure --help выдаёт гораздо более длинную простыню.
Некоторые пакеты (очень немногие, видимо, старой школы) в конце configure пишут:
bla-bla1 yes
bla-bla2 no
bla-bla3 yes
и ты сразу видишь, что включено, а что возможно ещё надо включить. Попробовал в passwd включить cracklib, дык оно не собралось нифига. Пришлось собирать по умолчанию, как в инструкции.

- рискнул-таки и собрал пакет less гораздо раньше, чем по инструкции. Но я сначала проверил зависимости, зависит он вроде только от glibc, поэтому пофиг. Пакет собрался и работает.

Ещё не хватает команды which. В дистре её нет, а мне пригодилась бы. Сегодня задался вопросом, по какому принципу пакеты включаются в LFS? Почему именно этот, а не какой-то другой. Perl5 вот там есть, типа без него даже в минимальном дистре не обойтись. Короче, ладно. Будем дальше собирать, не так много осталось.

@темы: Linux, LFS

---

С подачи LFS разбираемся, как эта хрень компилируеццо

make - утилита для сборки проекта (пакета) с помощью Makefile
gmake - GNU версия make
remake - make с дополнительными возможностями отладки
Cmake - утилита, которая делает Makefile. Добавлена позже, чтобы типа упростить работу с make в больших проектах.
Qmake - утилита из набора Qt, генерирует Makefile (который потом, видимо, используется make)
autotools - система автосборки GNU (configure && make && make install) Включает в себя инструменты automake, autoconf и libtool
autoconf читает configure.ac делает configure.sh. configure.sh читает Makefile.in делает Makefile
automake читает Makefile.am делает Makefile.in
libtool
mk-configure
bmake - переносимая версия make из NetBSD. Имеет какие-то доп.фичи
install - копирует файлы и выставляет атрибуты и, если возможно, SID & GID

Что нужно знать про make
Быстрое введение
Implicit rules www.gnu.org/software/make/manual/html_node/Impl...
builtin rules www.gnu.org/software/make/manual/html_node/Cata...
Пространная инструкция rus-linux.net/nlib.php?name=/MyLDP/algol/gnu_ma...
mini HOWTO www.opennet.ru/base/dev/mini_make.txt.html
Эффективное использование www.opennet.ru/docs/RUS/gnumake/
А теперь немного дёгтя:
Чем плох GNU-make habrahabr.ru/post/138682/
все обсирают GNU-make и autotools, однако, идеальной системы для сборки, которая бы вот всех устроила, пока ещё никто не предложил. Везде есть какие-то "но". С другой стороны, афтары autotools, когда их писали, не думали, что в наши дни программы разрастутся до таких неебических размеров.

Главная либа с++ это libstdc++, но есть альтернатива: libc++ это менее полная версия стандартной либы.
С главной либой С всё сложнее - есть до жопы вариантов. Стандарт это libc
glibc - GNU-версия libc, используется в дистрах linux
uclibc - меньше размером, чем glibc. Ориентируется на встроенные системы.
musl libc - заново написанная версия libc под лицензией MIT, более строго следует стандартам POSIX
newlib - версия для встроенных систем, с упором на экономию памяти
libgcc - это ваще не то, это библиотека поддержки gcc для некоторых архитектур
eglibc = emdedded glibc - версия glibc для встроенных систем
bionic - версия libc, разработанная Google под свой Андроид. Распространяется под BSD-лицензией
dietlibc - переписана с нуля, распространяется под GNU GPLv2, делает упор на минимальный размер программ и памяти - включает в себя наиболее часто используемые функции libc. Для встроенных устройств.
Чувствую, список будет пополняться. en.wikipedia.org/wiki/Embedded_GLIBC

возможно, в исходниках на с вначале можно пейсать #!/usr/bin/gcc. Надо бы проверить.

Всё это поможет лучшему пониманию сборки LFS и компиляции пакетов из исходников. Вся эта тяга к знаниям инициирована именно сборкой LFS и компиляцией пакетов (из которой процесс сборки LFS состоит чуть менее, чем полностью).
Как это поможет мне в жизни? Хз, если честно.

@темы: Linux, программирование, LFS

---

Великий и ужасный LFS - Linux-from-Scratch Часть 2

Потихоньку продвигаемся. Начал я его собирать вечером в четверг 19 октября. С одной стороны, сейчас прошло уже больше недели. С другой стороны, в эти 9 дней собирал я его всего 5 вечеров. Почему-то по вечерам меня на активность пробивает. То есть, если иметь некоторый опыт, за день вряд ли, но за два дня можно полностью собрать LFS.

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

1) манагер пакетов можно прикрутить в любой момент сборки. Не в том смысле, что я уже знаю, как это сделать, а в смысле, что LFS можно дальше собирать, и время не тратить. Конечно, чем раньше прикрутишь, тем лучше, НО! Это сведёт на нет всю идею LFS. Идея в том, чтобы самому собирать, смотреть опции и потихоньку вникать. А так ну чо - манагером ты поставишь, чо там происходит - хз.

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

3) появились мысли о написании собственного пакетного менеджера. Вряд ли я это буду делать, но понять, как его можно сделать было бы неплохо. У нас есть набор файлов до и набор файлов после. Манагер пакетов должен всё это запоминать, суметь в случае чего откатить всё обратно и, если какие-то файлы могут быть затёрты, сообщить об этом.

Короче, ладно. Продолжаем собирать. В шестой главе всё, что собиралось в пятой ( + ещё немного) собирается заново, токо в другое место. До этого собиралось в /tools, теперь в /usr. Причём, собирается с помощью того, что собиралось в пятой. Это типа важно.

Пишут, мол, все пакеты суперкритичные, поэтому во время сборки каждого пакета обязательно делайте тесты. Тест делается командой make check или make -k check. Собираем glibc, делаем тест. Вылазит пять или семь ошибок. Читаем руководство.

You may see some test failures. The Glibc test suite is somewhat dependent on the host system. This is a list of the most common issues seen for some versions of LFS:

- posix/tst-getaddrinfo4 and posix/tst-getaddrinfo5 may fail on some architectures.
- The rt/tst-cputimer1 and rt/tst-cpuclock2 tests have been known to fail. The reason is not completely understood, but indications are that minor timing issues can trigger these failures.
- The math tests sometimes fail when running on systems where the CPU is not a relatively new Intel or AMD processor.
- The nptl/tst-thread-affinity-{pthread,pthread2,sched} tests may fail for reasons that have not been determined.
- Other tests known to fail on some architectures are malloc/tst-malloc-usable and nptl/tst-cleanupx4.

Типа, эти ошибки - это нормально, эта возникает хер знает из-за чего, в общем, всё заебись, продолжайте.

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

Маленько в ахуе продолжаю дальше. Несколько утилит собирается без вопросов, тесты проходят отлично, следующий бастион binutils. В пятой главе она собиралась первая и без вопросов, а щас на тестах выдаёт ошибки. Написано:
One test, debug_msg.sh, is known to fail.
Но там чо-то написано, что вообще пиздец, куча ошибок и всё такое. Часа два я на это убил. Лазил по тырнету - там были похожие случаи, но во-первых другие версии, во-вторых данные там советы в стиле "забей и продолжай" уверенности мне не внушал. Как вот понять - критичные это ошибки или херня? Обратился к ютуберам. Мне подходили только те, кто собирает версию 8.0 или 8.1. Дык они или вообще тестов не делают или делают, но продолжают вне зависимости от результата. Прям как обезьяны! Ладно, внимательно посмотрел весь вывод тестов (а я, блин, не знаю, каким должен быть вывод успешных тестов), короче, все тесты пройдены, кроме этого debug_msg.sh, и вот после того, как он зафейлился, начинают появляться ошибки вида make *** Error 1 или Error 2. Подумал, нельзя ли как-нибудь энтот msg.sh исключить оттудова, но это надо где-то там ковыряться, а я не знаю, где. Забил, и дальше в книжке нашёл сцылку на логи:
www.linuxfromscratch.org/lfs/build-logs/8.1/
Я её потом искал на сайте, но тщетно (( А вот если бы эти ссылка была у меня до книги или хотя бы в её начале, это сэкономило бы мне несколько часов.

Дальше собираем gcc. Сначала сказано отдельно собрать все эти mpfr, mpc & gmp, а потом во время gcc configure начинаются жалобы, что mpfr, mpc & gmp уже сконфигурены. То ли баг, то ли фича. На этом я пока остановился.
Ту би континУед... Занимательного красноглазия будет очень, очень много!

@темы: Linux, LFS

---

Великий и ужасный LFS - Linux-from-Scratch

Короче, камрады, во время установки этих всяких *BSD наткнулся я на LFS или мож чуть раньше наткнулся, но в башку ёбнуло токо сейчас. Есть такой сайт www.linuxfromscratch.org, на ём есть книжка-инструкция LFS, в которой абисняицца, как по тырнету натырить пакетов, скомпилировать их и получить свой минимальный Линукс. Linux-from-Scratch переводицца как "Линукс с нуля" или "Линукс из ничего". Ну, он не очень минимальный, но не будем об этом. Уметь он будет очень мало - загружацца, выключацца и простейшие операции какие-то. Если хочется большего, есть другая книжка-инструкция BLFS - Beyond Linux From Scratch, вот там точно до хрена всего. Есть ещё ALFS - Automated LFS, типа всё то же самое, токо не ты сам, а скрипт для тебя всё буит собирать для экономии времени. Ещё есть Hardened LFS - с заёбами по безопасности и CLFS - Cross Linux - кросс-компиляция для другой платформы.

Это ещё не всё. Поскоку Линукс развиваецца - постоянно выходят новые версии пакетов, то и LFS вынужден идти в ногу со временем - инструкция имеет версии. Последняя стабильная (типа без глюков) версия имеет номер 8.1. И BLFS тоже имеет такие же версии. Для ALFS это не так актуально. Ну и, если вы ещё не охуели, с некоторого времени LFS имеет два варианта сборки - со старым добрым init и с новым еретическим systemd.

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

Сказано тщательно следуйте приведённым инструкциям. Ну чо я, читать штоле не умею? Буду следовать, конечно. Рекомендуется смонтировать отдельный диск. Нет у меня отдельного, херня, думаю, обычная папка сойдёт. Даётся список требований, что должно быть в системе и сразу скрипт, который всё это проверяет автоматом. Нах мне скрипт, чо я, совсем штоле? Руками проверил, вроде соотвецтвует.

Приступаем к сборке "временной цепочки инструментов". Первый пакет binutils собрался на ура за 36сек. Ободрённый успехом, скачиваю 4 пакета - gcc, mpc, mfpr, gmp. По инструкции 3 пакета куда-то складываются внутрь gcc, это я не сразу понял. Дальше нужно найти 3 файла в папке gcc/config. А именно:
config/linux.h
config/i386/linux.h
config/i386/linux64.h
А нет их там! Я завис и на этом ушёл домой. Дома ещё раз скачал и распаковал этот же пакет - нету этих файлов! Ну, думаю, мож с предыдущей версии LFS инструкция осталась? Скачал пакет gcc-6.3.0 из LFS-8.0. Там тоже нету этих файлов! Ладно.

В вс пришёл на работу нашёл на ютюбе запись Linux-from-Scratch 8.0. Смотрю.
youtu.be/eAPhPLx-dLg
Приближаемся к моменту поиска файлов, он копирует команду, у него файлы есть, у меня нет. Скачиваем один и тот же пакет! Как так-то, бля? о_О Поискал через find. Оказывается, структура пакета:
gcc-7.2.0/config
gcc-7.2.0/gcc/config/linux.h
gcc-7.2.0/gcc/config/i386/linux.h
gcc-7.2.0/gcc/config/i386/linux64.h
то есть, внутри есть папка config, в которой ничего нет, а есть ещё gcc и уже в ней config, в которой всё есть.
- Вот пидоры! - подумал я.
Начал собирать. Не собирается. Идёт-идёт, потом хуяк error. Полез в тырнет, искал-искал, встретил намёк на то, что нету g++. G++ это GNU версия C++. Да ладно, чо за бред? У меня ж есть компилятор gcc, конечно там есть с++. Скопировал энтот скрипт проверки требований, он мне показывает: С есть, С++ нет.
- Вот пидоры! - подумал я.
Установил С++, проверил скриптом требования, вроде всё норм, поехали собирать. Собралось.
Дальше вроде всё без сюрпризов, иногда на тестах глючило, но в главе 5 тесты делать необязательно, это всё равно всё временное. Ну вот для byson нужен flex, тогда тесты проходят. gawk выдавал тоже косяки какие-то на тестах. Не помню, как решил, короче, закончил пятую главу. Щас шестая впереди - то же, что и пятая, только в большем масштабе. А потом ещё чуть-чуть и буит у меня LFS.

В свете этого почитываю записи тех, кто уже собрал. Рекомендуют как можно раньше прикручивать менеджер пакетов. Другие говорят, что с менеджером пакетов это уже будет не LFS. Но перед тем, как прикрутить этот менеджер, надо ваще понять, как это сделать. Есть несколько способов применить "пакетную технику" в Linux и каждый пакетный менеджер использует ту или иную из них. И прежде чем решить, надо всё это понимать, а у меня с пониманием очень смутно. Так что пока думаем, что делать. Варианты:
1) дособрать чистый LFS, а потом попробовать установить Gentoo или Arch для расширения кругозора, т.к. это практически тот же LFS + менеджер пакетов
2) попробовать прикрутить какой-нить менеджер пакетов, а для этого изучить какие они есть и как вообще работают
То бишь теперь увлекательного красноглазия будет очень, очень много! (с) Lurkmore

@темы: Linux, LFS