Обновление udev
winterheart 12 февраля, 2013 - 18:32
Недавно появилась стабилизированная версия udev-197. Если вы обновляете систему, прочтите это сообщение с особым вниманием, так как беспечное обновление может привести к невозможности загрузки системы.
Прежде, чем обновлять udev, убедитесь, что в ядре установлен параметр CONFIG_DEVTMPFS=y. Не перезагружайте систему с новым udev, если это не так!
Будьте готовы, что ваши сетевые интерфейсы будут переименованы. В udev-197 появился новый механизм именования сетевых интерфейсов, поэтому ожидайте, что у вас может пропасть сеть.
»
- Блог пользователя - winterheart
- Для комментирования войдите или зарегистрируйтесь
Как проверить
emerge Your world
Gentoogle
И всё-таки, как быть с
И всё-таки, как быть с вынесенным на отдельный раздел /usr? А указанный параметр включил ещё как только об этом разговор пошёл, чтобы не забыть при таком вот обновлении. В принципе initramfs я создал, но хоцца обходиться без него.
Червон00кий.
Как я понял, оно и без /usr
Как я понял, оно и без /usr загрузится http://0pointer.de/blog/projects/the-biggest-myths.html - 28 пункт
Я бы не стал доверять словам
Я бы не стал доверять словам товарища, который хронически не делал свою домашку.
Не грусти, товарищ! Всё хорошо, beautiful good!
Не совсем так.
Собственно добрался таки до компа. Командой
equery f udevпроверил где раскиданы кишки удава и решил попробовать загрузить комп без initramfs! И знаете что? Он загрузился и работает. Так что можно. Товарищ, ответивший на мой комментарий, таки был прав. УМВР без initramfs с вынесенным в отдельный раздел /usr.
{UPD} Обновил portage и заметил новость датированную 2013-01-23, которая гласит:
- The case of separate /usr; if it worked for you with 171 it will continue
to work for you with 197. We still recommend initramfs with separate /usr
mounting capabilities because you might need packages like sys-apps/kbd
(keymaps in /usr) or net-wireless/bluez (possible keyboard) in early boot.
Ну и:
Apologies if this news came too late for you.
Червон00кий.
Это же вроде очень старая
Это же вроде очень старая история...
В udev-197 появился новый
А это надолго?
Или там у них опять чего-то зачешется и, глядишь, все вернуть назад?
Может стоит его замаскировать ?
PS вообще не понял зачем переименовывать интерфейсы ;(
知る者は言わず言う者は知らず
"Бабло, побеждает даже зло"
.
Подозреваю, навсегда.
А если подумать, то тенденция вполне логична.
Не стоит.
Тем более, что переименование устройст (если внимательно и рекурсивно почитать сообщение portage) только для новых установок (ну или если тебе так возжелается).
Так что неприятных сюрпризов, при наличии достаточного внимания к первичной документации, опасаться не стоит.
ЕМНИП переход с привязки имени устройства к его аппаратному идентификатору (MAC-адресу) к формированию первичного имени по используемому драйверу.
Непривычно --- возможно. Но вполне логично.
:wq
--
Live free or die
смысл прост
Смысл в том, что теперь интерфейсы получают имена предсказуемым и не зависящим от нюансов реализации определения устройств образом. То есть теперь, воткнув что-то куда-то — теоретически мы уже знаем, какое будет имя интерфейса.
Теоретически мы и так знаем
Теоретически мы и так знаем имя устройства или можем указать как ему называться, по крайней раньше так было, а теперь правила именования сетевых устройств для udev не работают.
Вполне себе работают, куда бы
Вполне себе работают, куда бы им деться. Просто в данный исторический период, ты не можеш переименовать eth3 в eth0 сразу, нужно делать какоето промежуточное имя, а потом давать нужное. Так и поступал раньше UDEV, а теперь этот костыль убрали, и заменили на... на то что заменили.
Поправочка. Нельзя сразу
Поправочка. Нельзя сразу переименовать eth3 в eht0, если eth0 уже присутствует. На одной из моих машин:
JUPITER ~ # grep -v ^# /etc/udev/rules.d/70-persistent-net.rules | sed -e "/^$/d" SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:0f:ea:64:d5:6d", KERNEL=="eth*", NAME="eth0" SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:13:77:91:95:06", KERNEL=="eth*", NAME="eth1" SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:21:63:2c:22:8b", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:16:17:47:7a:ed", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:80:48:c6:83:f0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth3" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:e0:4c:51:1c:a9", ATTR{type}=="1", KERNEL=="eth*", NAME="eth4" JUPITER ~ # ifconfig -a | grep ^eth eth2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 eth4: flags=4098<BROADCAST,MULTICAST> mtu 1500 JUPITER ~ # dmesg | grep rename [ 5.600133] systemd-udevd[1241]: renamed network interface eth0 to eth4 [ 5.641120] systemd-udevd[1242]: renamed network interface eth1 to eth2Траблы с сетевым интерфейсом
Почему то сетевые интерфейсы не работали с udev-197 при вкомпиленных модулях в ядро, при этом ifconfig видит все карты, но не стоит статус RUNNING и ping соответственно не ходит и даже route -v выполняется несколько минут. Если собрать ядро с модулями сетевых карт, то все нормально работает.