[мерялка]размер ядра

что, собственно, и делает моя initramfs или же может делать preinit-скрипт на корневой ФС

Если основной затык в devю. то есть devtmpfs, классная штука

du /boot/3.0.4 
1371	/boot/3.0.4

 du -sh /lib/modules/3.0.4-ck/kernel/
3.2M	/lib/modules/3.0.4-ck/kernel/

Сжатия ядра xz, самосбор, Gentoo/

Забыл написать, что initrd нет

1371 /boot/3.0.4

Даже на version_string сэкономил байты?

Мало ли что в модулях есть.

9,2M	/lib/modules/2.6.30.10/kernel/drivers/video/nvidia.ko

Покажи мне такую дискету.

в холодной воде, добавь :D

На моей дискете всякого шлака не было: просто система, которая может загрузиться, смонтировать флешку и использовать busybox (busybox на дискете, на флешке ничего системного нет). Я не ставил себе цель постоянно работать с этой дискеты или чтобы она была совместима с множеством железа.

Если основной затык в devю. то есть devtmpfs, классная штука

Я его и использую. Но в общем случае, когда дистрибутив не делается под конкретную машину, неизвестно, нужен ли udev для монтирования /usr. По крайней мере, все распространённые дистрибутивы, не использующие systemd, запускают udev до монтирования /usr, значит, смысл в этом есть.

Так легче в грабе править. попробуй запомнить название ядра vmlinuz-my-ck-sources-3.0.4 и попробовать угадать как называется 3.2.1.

Ещё раз тебя спрашиваю, почему система с systemd и отдельным /usr не загружается

4.2. Система с systemd и отдельным /usr загружается.

А без systemd, но с glibc/udev всё прекрасно грузится и очень даже шустро?!

Уж точно не шустрее, чем с systemd. И это всё зависит от конкретного железа. Если у тебя нету проблемной железки, то у тебя будет работать. У меня же не запускался bluetoothd при загрузке с включённым bluetooth, например, потому что udev запускался раньше монтирования /usr, а bluetoothd находится в /usr/sbin, и bluetoothd запускается правилом udev. Это называется «всё прекрасно грузится»?!

Я, post-factum, ядро компилю, понятное дело, сам, кое-что вкомпилено, кое-что в модулях, initramfs отдельно, размер ядра 3,4 Мб, размер модулей 7,8 Мб.

initramfs 1,8 Мб.

А разве можно PE-загрузчик использовать на этапе загрузки ядра?

4.2. Система с systemd и отдельным /usr загружается.

Костыли ради костылей

Помнишь анекдот «у вас бы и не так скукожился»? Так это про меня.

монолит 3 мб

Васисуалий

Взбодрили

Костыли ради костылей

Информация по ссылке основана на моём личном опыте и не соответствует действительности, потому что на тот момент я ошибался.

Конечно, можно и SysVinit собрать с префиксом /usr, тогда ничего не загрузится совсем. Можно и init-скрипты положить в /usr/share/init.d, тогда тоже не загрузится. А чтобы грузилось, кладут SysVinit и init-скрипты в корневую ФС, чтобы они были доступны.

Точно также и systemd надо собирать с префиксом /, и его зависимости тоже делать доступными из корневой ФС (это я про dbus). То, что мейнтейнеры Генты не положили dbus в корневую ФС (хотя бы при установке определённого USE-флага) и даже не положили такой ебилд в оверлей systemd, — проблемы Генты, а не systemd.

Более того, сейчас в Генте вообще стали собирать и systemd с префиксом /usr, потому что бегут впереди паровоза. До этого они замаскировали ебилды новых версий systemd, пока не придумают решения для проблемы с /usr, но почему-то потом пропустили в ~arch ебилд, устанавливающий systemd в /usr.

systemd работает даже при /usr на отдельном разделе. При этом он способен сам его смонтировать, и работать всё будет не хуже, чем с SysVinit (systemd не решает проблемы udev и /usr, но новых проблем не добавляет). Но ебилды для systemd и для dbus составлены неправильно: они устанавливают эти пакеты в /usr, делая их недоступными на раннем этапе загрузки. Если составить правильные ебилды, то будет 2 варианта: либо без initrd, но проблема udev остаётся та же, что и с SysVinit; либо с initrd или preinit-скриптом в корневой ФС, монтирующими /usr и решающими проблему udev. С неправильными ебилдами остаётся только второй способ, т.е. таким радикальным способом мейнтейнеры Генты решают проблему udev, но при этом бегут впереди паровоза, т. к. они ещё не написали ни initrd, ни preinit-скрипт.

Делаем вывод из всей это простыни: systemd одна большая проблема.

Делаем вывод из всей это простыни: systemd одна большая проблема.

Вывод сделан неправильно: видимо, невнимательно читал. Правильный вывод такой: разрабы Генты криво пишут ебилды, нифига не могут поддерживать systemd, который может вполне нормально работать, если его правильно собрать. Правильно собранный systemd не решает проблемы udev, но не добавляет новых, при этом работает. Для решения проблемы udev, не имеющей ничего общего ни с SysVinit, ни с systemd, предназначен либо initrd, либо preinit-скрипт.

Для решения проблемы udev, не имеющей ничего общего ни с SysVinit, ни с systemd, предназначен либо initrd, либо preinit-скрипт.

Каких проблем?! Почему у меня оно просто работает?!

разрабы Генты криво пишут ебилды, нифига не могут поддерживать systemd, который

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

если его правильно собрать

то dbus всё равно будет в /usr и это проблема systemd, а не генты и её разрабов.

я, Глеб Мизгирь, ядро конпелял сам, монолитное, initrd внутренний, ядро весит 5 мб

Каких проблем?!

Я уже сказал. У меня не запускался bluetoothd при загрузке с включённым bluetooth и отдельным /usr, потому что он в /usr/sbin.

Почему у меня оно просто работает?!

Потому что у тебя нет железа, которое обрабатывается проблемными скриптами. Список проблемных скриптов: «grep -Er 'usb-db|pci-db|FROM_DATABASE|/usr' /{etc,lib}/udev/rules.d».

то dbus всё равно будет в /usr и это проблема systemd, а не генты и её разрабов.

Это не проблема systemd ни в каком случае, потому что dbus — зависимость systemd, значит, мейнтейнеры должны обеспечить его доступность во время запуска и работы systemd. Например, делается USE-флаг systemd, при установке которого dbus-daemon и libdbus устанавливаются в /bin и /lib. Если вдруг в какой-нибудь новой BolgenOS glibc будет установлено в /usr/lib, и система не загрузится, то это что, проблема SysVinit, что ли?!

Версия 3.2.2, без модулей, initramfs (для загрузки с LVM) внутри - 3916320.

Это не проблема systemd ни в каком случае, потому что dbus — зависимость systemd, значит, мейнтейнеры должны обеспечить его доступность во время запуска и работы systemd.

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

Ну, мне хотя бы справку от врача :D

Для dbus можно было сделать отдельного демона, который бы запускался при доступности самого dbus.

o_O Зачем нужно 2 демона, выполняющих одну и ту же функциональность? Ничего плохого нет в перемещении dbus в корень и установке симлинков на старых местах для обратной совместимости с кривыми программами, в которые захардкодены пути.

Я чёт не понял щас. systemd зависит от d-bus, а библиотеки d-bus устанавливается в /usr/lib?

В таком случае пара вопросов.

1. Автор systemd е***ся что ли?

2. Статически слинковать не проще?

Кто говорил об одинаковой функциональности?! О_о

1. Автор systemd е***ся что ли?

А ты об этом только узнал?!

Кто говорил об одинаковой функциональности?! О_о

Тогда я вообще не понял, что это за набор костылей получится.

И да, как верно заметил name_no, можно и статически слинковать systemd с libdbus.

А ещё он другое заметил, но ты это проигнорировал.

А ещё он другое заметил, но ты это проигнорировал.

Я не проигнорировал, на том предложении мой парсер вышел с кодом 1 и сообщением на stderr: «Вложенные *».

Я не проигнорировал, на том предложении мой парсер вышел с кодом 1 и сообщением на stderr: «Вложенные *».

Я там предположил, что автор systemd — идиот, потому что написал init, который зависит от dbus — это надо быть на всю башку больным, что такое написать, а уж использовать это добровольно...

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

Ну так вот, в /usr по определению лежат те либы, которые а) не входят в базовый набор и б) могут запросто отсутствовать вообще. Init в системе нужен обязательно, а dbus — нет. Зависимость init от d-bus выдаёт в его авторе...

Собственно, когда я понял, что автор systemd так же является автором pulseaudio, всё встало на свои места.

Я там предположил, что автор systemd — идиот, потому что написал init, который зависит от dbus — это надо быть на всю башку больным, что такое написать, а уж использовать это добровольно...

D-Bus там нужен как интерфейс для управления systemd. SysVinit'ом, по сути, вообще нельзя управлять — только менять ранлевелы через /dev/initctl, чего явно недостаточно для нормального управления. systemd также поддерживает интерфейс /dev/initctl. А для нормального управления сервисами он выставляет интерфейс на D-Bus. Предложишь другой, лучший способ?

Ну так вот, в /usr по определению лежат те либы, которые а) не входят в базовый набор и б) могут запросто отсутствовать вообще. Init в системе нужен обязательно, а dbus — нет. Зависимость init от d-bus выдаёт в его авторе...

Здесь нарушена логика, потому что init нужен обязательно, но это не обязательно systemd. Если нет D-Bus, используй SysVinit. Если есть D-Bus, тогда можно использовать или SysVinit, или systemd. Поэтому init в общем не зависит от D-Bus и D-Bus таки необязателен.

те либы, которые а) не входят в базовый набор

А вот здесь поподробнее, где мне почитать полный список этого базового набора? И почему он разный для разных дистрибутивов?

И почему он разный для разных дистрибутивов?

Для дистрибутивов, соответствубщих lsb, базовый набор — одинаковый.

Но на момент старта init базовым являются linux-utils, coreutils и libc и рассчитывать, что будут доступны другие — преступление против пользователя.

Хотя не могу не отметить, что во многих линуксах есть куча проблем, связанных с вольной трактовкой «базового набора». Например, если каталог etc смонтирован read-only, то ето жёппа, господа. Хотя никто не обещал, что этот каталог будет доступен на запись, на запись обещаны только /var и /tmp (ну и home, конечно). Или ещё вариант, если /var при старте системы пустой — половина хлама из init.d не запустится. Мало кто из них способен сам создать себе каталог /var/cache, если его нет.

Конечно, надо разработчиков лопатой бить, но почему-то их все защищают и поддерживают (дескать, нефиг делать read-only /etc и чистить /var и делать /usr на внешнем разделе). Меня это удручает.

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

Это зависит от тормозилы или от железа?

монолитное, не получилось

ЛОХ!

Это зависит от тормозилы или от железа?

А как прожорливость тормозиллы зависит от железа?

А как прожорливость тормозиллы зависит от железа?

А как конфиг ядра зависит от тормозилы?

А как конфиг ядра зависит от тормозилы?

А как тормозилла зависит от конфига KDE?

А как тормозилла зависит от конфига KDE?

А как конфиг КДЕ зависит от конфига ядра?