LINUX.ORG.RU
ФорумTalks

[НАТЕ][поттеринг][gentoo]прилетела новостишка

 ,


0

2

udev-181 is being unmasked on 2012-03-19.

This news item is to inform you that once you upgrade to a version of udev >=181, if you have /usr on a separate partition, you must boot your system with an initramfs which pre-mounts /usr.

An initramfs which does this is created by

=sys-kernel/genkernel-3.4.25.1 or
=sys-kernel/dracut-017-r1. If you do not want to use these tools, be

sure any initramfs you create pre-mounts /usr.

Also, if you are using OpenRC, you must upgrade to >= openrc-0.9.9.

For more information on why this has been done, see the following URL: http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken

Смысл приблизительно в следующем: в генте размаскировали udev-181 и предупреждают, что в нём убрана возможность работы с /usr на отдельном разделе. В качестве костыля предлагают использовать initramfs.

HATE!!!

★★★★★

Ответ на: комментарий от Myp3ik

1). откуда цитата? возможность работы с /usr на отдельном разделе не убрана.

2). потцеринг тут не при чём

qnikst ★★★★★
()
Ответ на: комментарий от Deleted

над тем почему был написан твой комментарий?

qnikst ★★★★★
()

У арчеров, кстати:

Как видно, в пакетах udev и kmod бинарники переехали в /usr/bin/
Соображения тут, видимо, такие – раз всё равно это всё в initcpio, то незачем держать в /sbin/

$ cd /var/cache/pacman/pkg/
$ tar tf udev-180-1-i686.pkg.tar.xz |grep bin/
sbin/
sbin/udevd
sbin/udevadm
$ tar tf udev-181-2-i686.pkg.tar.xz |grep bin/
usr/bin/
usr/bin/udevd
usr/bin/udevadm
$ tar tf kmod-4-2-i686.pkg.tar.xz |grep bin/
bin/
bin/lsmod
sbin/

http://archlinux.org.ru/forum/viewtopic.php?p=70675&sid=3f68b866369b36a95...

Я ничего не понял.

FiXer ★★☆☆☆
()
Ответ на: комментарий от FiXer

Если нет initrd, то будут проблемы, иначе все ок.

Kosyak ★★★★
()
Ответ на: комментарий от Kosyak

На десктопе - сферическое красноглазие в вакууме.

pekmop1024 ★★★★★
()
Ответ на: комментарий от daemonpnz

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

Если бы ты не просто мог грепать systemd, но еще и умел читать, то понял бы, что systemd ни при чем.

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

geekless ★★
()
Ответ на: комментарий от CYB3R

Гентушники на тракторах переезжают на слаку.


Они ещё трактор не собрали.

Dragon59 ★★
()
Ответ на: комментарий от ksevelyar

/data  — файлы и документы с которыми я работаю

как ты умудрился сделать 4 ошибки в слове home?

winlook38 ★★
()
Ответ на: комментарий от O02eg

Слава богу, что я альсой не пользуюсь.

daemonpnz ★★★★★
() автор топика

А Поттеринг-то тут при чём?

carasin ★★★★★
()

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

druganddrop-2 ★★
()
Ответ на: комментарий от GotF

Плюсую. В Fedor'е оно уже достаточно давно, проблем нет.

carasin ★★★★★
()
Ответ на: комментарий от Myp3ik

Имя нарицательное для дурацких нововведений.

Это не нововведение. Отдельный /usr был сломан годы назад. В том же udev.

x3al ★★★★★
()
Ответ на: комментарий от shatsky

а ты внизу смотрел, кто эту простыню бреда по ссылке накатал? Поттеринг!!!

Harald ★★★★★
()

размаскировали

замаскировывать

Кто все эти люди?

buddhist ★★★★★
()
Ответ на: комментарий от qnikst

Я на Fedor'е делал самосбор из *.src.rpm'ок, initramfs был.

carasin ★★★★★
()

казалось бы, при чем здесь systemd

registrant ★★★★★
()
Ответ на: комментарий от daemonpnz

Ох, хотел бы я посмотреть как ты с помощью голого ядра будешь делать fsck разделу /.

Из initramfs. Я себе давно уже сам запилил initramfs со своими скриптами, которая монтирует вместе с корнем ещё и /usr, к тому же проверяет эти файловые системы с помощью fsck. У этого есть огромный плюс: если надо исправить ошибки на корневой ФС, то раньше обязательно надо было перезагружаться, потому что она была смонтирована (в read-only). Теперь же при проверке ФС из initramfs она проверяется, пока ещё не смонтирована, поэтому лишняя перезагрузка не нужна.

PS И вообще, это уже было: Gentoo udev /usr. Хоть бы поиск осилил перед тем, как постить здесь, если синкнулся так поздно.

gentoo_root ★★★★★
()
Ответ на: комментарий от gentoo_root

Вот бы ещё поттеринг и сотоварищи осилили программирование и здравый смысл... тогда бы не было этих тредов воообще

daemonpnz ★★★★★
() автор топика
Ответ на: комментарий от xorik

Придется ядро некошерным genkernel-ом собирать, печалька

Можно без genkernel: лови мою initramfs: http://ompldr.org/vZDJvMA

Туда надо распаковать исходники busybox, поправить симлинк на них, скопировать initramfs/busybox-config в initramfs/busybox/.config, перейти в initramfs/busybox, собрать его (make && make install), перейти в .., запустить install.sh, после этого установится initramfs прямо в /boot.

// Распространяю как Public Domain всем, кому нужно.

gentoo_root ★★★★★
()
Ответ на: комментарий от daemonpnz

Вот бы ещё поттеринг и сотоварищи осилили программирование и здравый смысл... тогда бы не было этих тредов воообще

Почему только Поттеринг и сотоварищи? Очень мало в Линуксе сделано по здравому смыслу и качественно. Начиная от иксов, в которых при повороте экрана (который ещё и повернуть — целая проблема) всё начинает лагать, заканчивая тулкитами, начинёнными костылями и подпорками для решения всевозможных проблем, которых вообще быть не должно. Это не говоря о наличии миллиона велосипедов для решения всевозможных задач, ни один из которых качественно её не решает. Тех же плееров музыки миллионы, а нормального ни одного нет.

И неужели разделение исполняемых файлов по /bin, /sbin, /usr/bin, /usr/sbin, /usr/lib/* и /usr/libexec/** — это здравый смысл?

Для начала bin и sbin — кому нужно это разделение? Мне постоянно приходится выполнять из-под обычного пользователя команды, лежащие в sbin. Да, их функциональность ограничивается, потому что не рут их запустил, но мне-то и нужна эта ограниченная функциональность (например, просто посмотреть IP-адрес с помощью ifconfig, но не настраивать сеть, и это не единственная команда из sbin, которую я запускаю от пользователя). Но почему-то в Генте решили убрать sbin из $PATH пользователя. Я-то назад его запилил, но этот случай подтверждает глупость решения с раздельными bin и sbin.

Далее — /usr/bin и /bin. Выше уже было сказано, что половина бинарников из /bin не запустятся без примонтированного /usr из-за отсутствия библиотек из /usr/lib. Зачем их вообще тогда держать в /bin? Напрашивается такой вопрос: зачем вообще держать бинарники в /bin, если есть /usr/bin? Раньше они были нужны для 2 целей: начальная загрузка системы, пока не смонтирован /usr, и минимальная система для восстановления. Но первая цель отпадает: либо /usr не на отдельном разделе, либо же он монтируется из initramfs, потому то иначе всё равно есть куча проблем. Вторая цель тоже отпадает: случай, когда посыпался /usr, но не посыпался корень маловероятен, хотя бы потому что если /usr отдельный, ничего не мешает его смонтировать в read-only — тогда его может убить только физическое разрушение винчестера. При сбое с большей вероятностью полетит корень с «минимальной системой для восстановления», чем /usr. Поэтому хранить бинарники и в корне, и в /usr — бред. Нужно одно из мест. /usr/bin лучше, чем куча разных подкаталогов в корне, потому что тогда можно сразу весь /usr монтировать в ro.

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

Если так разбираться, то ФС можно разделить на 2 части (не считая всяких /dev, /proc, /sys, /tmp и /home): на неизменную (/usr) и на меняющуюся (/var).

gentoo_root ★★★★★
()
Ответ на: комментарий от daemonpnz

А пока я пошёл это говно обратно замаскировывать.

Оно же итак пока в ~arch.

Но тенденция давно не нравится. А в случае udev — не только у Gentoo.

KRoN73 ★★★★★
()
Ответ на: комментарий от daemonpnz

Так послушать, получится гентудевы вообще делать ничего не должны.

Ну, на ЛОРе это очень распространённая и активная точка зрения.

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

Ну так у меня система и стоит преимущественно ~arch, а udev-181 был именно замаскировано жёстко.

daemonpnz ★★★★★
() автор топика
Ответ на: комментарий от ubiquitine

В современных системах я лично не вижу смысла это делать...

Например, делать периодический дефраг мувом /usr без перезагрузки системы (e4defrag не предлагать). Или, вообще, /usr в R/O хранить. Или даже в squashfs. Вариантов много. Это когда-то была Linux, а не Windows…

KRoN73 ★★★★★
()
Ответ на: комментарий от tiandrey

Прочитал, не нашёл ответа.

Значит, тебе это не нужно. Но повод ли это отказываться от не нужных тебе вариантов?

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

Нет, ну правда, покажите сообщение, в котором содержится причина, мне же интересно.

tiandrey ★★★★★
()
Ответ на: комментарий от KRoN73

так же как и точка зрения о том, что нужно срать на локальных форумах о том, как всё плохо, как отнимают свободу ничего не тестят, приводить 4.2 аргументы о том, что патч только в 9999 и при этом приводить ссылку на багзиллу, где в комментарии мясячной(!) давности написано, что патч добавлен в дерево, а сам баг в RESOLVED_FIXED, и при этом даже не заходить на багзиллу.

P.S. может быть ты скажешь, что должны сделать гентудевы в данном конкретном случае? P.P.S для тех кому лень делать squashfs ещё есть вариант сделать EXTRA_ECONF="-prefix" для libkmod.

P.P.S. извиняюсь, что сорвался но наболело.

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

P.S. может быть ты скажешь, что должны сделать гентудевы в данном конкретном случае?

В данном _конкретном_ случае я сразу написал выше: «Но тенденция давно не нравится. А в случае udev — не только у Gentoo».

Что не отменяет множества других случаев (см. соответствующие темы форума), когда Gentoo-девы последнее время всё чаще сносят пакеты из портежа, только потому что ими _в_Gentoo_ «никто не занимается». Или когда сносят пакет, прекрасно собирающийся у многих, но не собирающийся в некоторых.

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

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

В данном _конкретном_ случае я сразу написал выше: «Но тенденция давно не нравится. А в случае udev — не только у Gentoo».

ok

Что не отменяет множества других случаев (см. соответствующие темы форума), когда Gentoo-девы последнее время всё чаще сносят пакеты из портежа, только потому что ими _в_Gentoo_ «никто не занимается». Или когда сносят пакет, прекрасно собирающийся у многих, но не собирающийся в некоторых.

Напомню политику дистрибутива по включению пакетов в основное дерево: http://devmanual.gentoo.org/general-concepts/tree/index.html

Software-wise, in general all of the following should be met in order for a package to be included in the Patching and Distribution Permittedtree:

Active, Cooperative Upstream; Reasonably Stable; Reasonably Useful; Properly Packaged; Patching and Distribution Permitted; Working Ebuilds; Portable; Reasonable Security Record

теперь я захожу в package.mask и смотрю masked for removal у которых нету ссылку на багзиллу: net-mail/vmailmgr, dev-java/netx, что-то протв этих удалений есть?

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

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

а точно не прекрасно собирающихся у некоторых, но не собирающихся у многих?

Объективно, проблем в том числе с выпиливанием интересных некоторым программ много, сейчас к сожалению у девов нет статистики по поводу использования пакетов, чтобы можно было оперировать какими-нибудь хотя бы приблизительными цифрами, если таки проект по GSoC-2012 [1] запилят, то это будет очень хорошо и в целом должно улучшить данную ситуацию.

--

[1] http://wiki.gentoo.org/wiki/Google_Summer_of_Code/2012/Ideas/Package_statisti...

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

а точно не прекрасно собирающихся у некоторых, но не собирающихся у многих?

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

Объективно, проблем в том числе с выпиливанием интересных некоторым программ много

Объективно я сейчас снимаю Gentoo с последнего своего десктопа. Я больше не вижу смысла в таком выборе. И это после более чем 8 лет жизни с этим дистрибутивом, когда-то с мнением, что это — лучший вариант. Сегодня Gentoo на десктопе уже не имеет совсем никаких преимуществ для меня по сравнению хотя бы с той же Ubuntu. А вот минусов — масса. Не один год я дозревал, но смысла мучиться дальше уже не вижу.

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

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

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

P.S.

Объективно я сейчас снимаю Gentoo с последнего своего десктопа.

1). 'я... сейчас.. своего...' это называется субьективно ;) (но это не важно)

qnikst ★★★★★
()
Ответ на: комментарий от KRoN73

да если ты не согласен с моим мнением, то мне действительно интересно услышать доводы

qnikst ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.