Bug 15426 - init: udev*
: init: udev*
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/mkinitrd)
: unstable
: all Linux
: P2 normal
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2008-04-21 19:24 by
Modified: 2008-09-02 18:09 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2008-04-21 19:24:39
Не является ли
udevd
udevtrigger
udevsettle
вместо
/sbin/udevd
/sbin/udevtrigger
/sbin/udevsettle
тщательно (или нечаянно) расставленными граблями (в /init)?
------- Comment #1 From 2008-04-21 20:11:27 -------
Иными словами, у нас в initrd имени ltsp-mkbootiso вылезли штуки четыре
/bin/sh: неполучаетсянайти udevsettle
/bin/sh: неполучаетсянайти udevtrigger
------- Comment #2 From 2008-04-22 13:57:29 -------
Здесь страньше.

С 2.6.22 и сизифным udev (см.тж. Bug #15427) -- наблюдаются две проблемы.
С тем же 2.6.22 и M40-ным udev -- всё в порядке.

2 led: похоже, я вчера не переписал образ, сгенерированный с сизифным udev, тем,
который был собран с udev/mkinitrd из бранча.  Это помимо того, что сказал
"работает", загрузившись по PXE %).  Так что давай сегодня более спокойно и без
отвлечений проверим -- пока мне кажется, что пакеты из бранча (mkinitrd, udev,
busybox? и ядро led-tc) в сумме ездят адекватно.

Патчик-то привесь, в любом разе.
------- Comment #3 From 2008-04-22 14:13:01 -------
(In reply to comment #2)
> Так что давай сегодня более спокойно и без
> отвлечений проверим -- пока мне кажется, что пакеты из бранча (mkinitrd, 
udev,
> busybox?

В Сизифе только udev новый, mkinitrd и busybox - AFAIR те же

> и ядро led-tc) в сумме ездят адекватно.
> 
> Патчик-то привесь, в любом разе.

Нету у меня "патчика"
------- Comment #4 From 2008-04-22 14:38:16 -------
(In reply to comment #1)
> Иными словами, у нас в initrd имени ltsp-mkbootiso вылезли штуки четыре
> /bin/sh: неполучаетсянайти udevsettle
> /bin/sh: неполучаетсянайти udevtrigger

А что там выполняет роль /bin/sh?  В том, что создаёт mkinitrd - dash из klibc,
у него по умолчанию
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin, так что
проблем не возникает.  Можно, конечно, напихать явных /sbin везде...
------- Comment #5 From 2008-04-22 14:45:20 -------
(In reply to comment #4)
> (In reply to comment #1)
> > Иными словами, у нас в initrd имени ltsp-mkbootiso вылезли штуки четыре
> > /bin/sh: неполучаетсянайти udevsettle
> > /bin/sh: неполучаетсянайти udevtrigger
> 
> А что там выполняет роль /bin/sh?  В том, что создаёт mkinitrd - dash из 
klibc,
> у него по умолчанию
> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin, так что
> проблем не возникает.  Можно, конечно, напихать явных /sbin везде...

Ну так вот: с явными /sbin/ проблем и не возникает, а с "неявными" - возникают.
------- Comment #6 From 2008-04-22 14:54:29 -------
(In reply to comment #5)
> Ну так вот: с явными /sbin/ проблем и не возникает, а с "неявными" - 
возникают.

Справедливости ради, надо отметить, что проблемы начали вылазить после 
обновления udev до 118. Но ИМХО лучше перестраховаться от таких обновлений, тем 
более, что такая "перестраховка" ничего не стОит.
------- Comment #7 From 2008-04-25 17:57:26 -------
(In reply to comment #5)
> Ну так вот: с явными /sbin/ проблем и не возникает, а с "неявными" - возникают.

Споткнулся об эту же проблему. После правки /lib/mkinitrd/initramfs-base/init
проблема ушла.
------- Comment #8 From 2008-04-25 19:37:34 -------
(In reply to comment #7)
> Споткнулся об эту же проблему. После правки /lib/mkinitrd/initramfs-base/init
> проблема ушла.

В initramfs опять было что-то нестандартное?
Какие версии пакетов туда попали (rpmquery -f /lib/mkinitrd/*)?

Явное выставление PATH:
http://git.altlinux.org/people/vsu/packages/?p=mkinitrd.git;a=commitdiff;h=4744aec09e354a8c04a0922747dddbaf8d48a3d6
исправляет ситуацию?
------- Comment #9 From 2008-04-25 19:43:06 -------
(In reply to comment #8)
> Явное выставление PATH:
> 
http://git.altlinux.org/people/vsu/packages/?p=mkinitrd.git;a=commitdiff;h=4744aec09e354a8c04a0922747dddbaf8d48a3d6
> исправляет ситуацию?

У меня не исправляло. Правда, я не помню, делал ли export
------- Comment #10 From 2008-04-25 19:45:29 -------
В порядке бреда: может это из-за того, что сейчас (118) утилиты udev* (в 
initrd) - это фактически хардлинки на один и тот же файл?
------- Comment #11 From 2008-04-25 19:48:40 -------
А с какими ядрами проявляется эта проблема - как обычно, исключительно с теми,
которые отсутствуют на git.alt?
------- Comment #12 From 2008-04-25 19:56:28 -------
(In reply to comment #10)
> В порядке бреда: может это из-за того, что сейчас (118) утилиты udev* (в 
> initrd) - это фактически хардлинки на один и тот же файл?

Возможно. Как-то не подумал, что для того, чтобы исправить ошибки sh или 
скрипта, нужно патчить ядро:)
Как бы то ни было, до udev-118 это не проявлялось ни на каких ядрах, даже на 
самых что ни есть "ванильных".
------- Comment #13 From 2008-04-25 19:57:56 -------
(In reply to comment #12)

> Возможно. Как-то не подумал, что для того, чтобы исправить ошибки sh или 
> скрипта, нужно патчить ядро:)
> Как бы то ни было, до udev-118 это не проявлялось ни на каких ядрах, даже на 
> самых что ни есть "ванильных".

Это был ответ на #11 (или багзилла глюкнула, или я промахнулся...)
------- Comment #14 From 2008-04-25 20:11:58 -------
(In reply to comment #13)
> Это был ответ на #11 (или багзилла глюкнула, или я промахнулся...)


[выныривая]
Багзилла не глючит, она фундаментально ошибается! :)
[нырнул обратно в дебри Bugzilla/DB/Schema.pm]
------- Comment #15 From 2008-08-30 01:36:24 -------
(In reply to comment #10)
> В порядке бреда: может это из-за того, что сейчас (118) утилиты udev* (в 
> initrd) - это фактически хардлинки на один и тот же файл?

"Бред" подтвердился. Если заменить харлинки на симлинки и в mkinitrd сделать
-Cp -aL /lib/mkinitrd/udev/* "$MNTDIR/"
+Cp -a /lib/mkinitrd/udev/* "$MNTDIR/"
неприятный эффект исчезает.
------- Comment #16 From 2008-08-31 12:54:14 -------
(In reply to comment #15)
> (In reply to comment #10)
> > В порядке бреда: может это из-за того, что сейчас (118) утилиты udev* (в 
> > initrd) - это фактически хардлинки на один и тот же файл?
> 
> "Бред" подтвердился. Если заменить харлинки на симлинки и в mkinitrd сделать
> -Cp -aL /lib/mkinitrd/udev/* "$MNTDIR/"
> +Cp -a /lib/mkinitrd/udev/* "$MNTDIR/"
> неприятный эффект исчезает.

Тогда это ядерные штучки.  Интересно, кстати, какая у этого initrd файловая
система?
------- Comment #17 From 2008-08-31 13:34:48 -------
(In reply to comment #16)
> Тогда это ядерные штучки.  Интересно, кстати, какая у этого initrd файловая
> система?

initramfs
------- Comment #18 From 2008-08-31 23:25:02 -------
(In reply to comment #12)
> (In reply to comment #10)
> > В порядке бреда: может это из-за того, что сейчас (118) утилиты udev* (в 
> > initrd) - это фактически хардлинки на один и тот же файл?
> 
> Возможно. Как-то не подумал, что для того, чтобы исправить ошибки sh или 
> скрипта, нужно патчить ядро:)

Увы, это вполне вероятно.

> Как бы то ни было, до udev-118 это не проявлялось ни на каких ядрах, даже на 
> самых что ни есть "ванильных".

Так или иначе, но добавлять полный путь к udevtrigger -- это лишь маскировать
проблему.

Ладно, как эту ошибку воспроизводить?
------- Comment #19 From 2008-08-31 23:55:20 -------
(In reply to comment #18)
> > Возможно. Как-то не подумал, что для того, чтобы исправить ошибки sh или 
> > скрипта, нужно патчить ядро:)
> 
> Увы, это вполне вероятно.

Это в идеале. Но можно обойтись и без этого.

> Так или иначе, но добавлять полный путь к udevtrigger -- это лишь маскировать
> проблему.

Добавление "полного пути", к сожалению, никоим образом не решает проблему.

> Ладно, как эту ошибку воспроизводить?

mkinitrd --extra <etherboot-module> ...

ethernet-модуль должен загрузиться ещё при обработке в initrd
------- Comment #20 From 2008-09-01 00:28:21 -------
(In reply to comment #19)
> (In reply to comment #18)
> > > Возможно. Как-то не подумал, что для того, чтобы исправить ошибки sh или 
> > > скрипта, нужно патчить ядро:)
> > 
> > Увы, это вполне вероятно.
> 
> Это в идеале. Но можно обойтись и без этого.
> 
> > Так или иначе, но добавлять полный путь к udevtrigger -- это лишь маскировать
> > проблему.
> 
> Добавление "полного пути", к сожалению, никоим образом не решает проблему.

Это хорошо, ибо уменьшает вероятность ошибки вне mkinitrd/udev.

А каким образом удаётся решить проблему?
------- Comment #21 From 2008-09-01 00:35:24 -------
(In reply to comment #15)
> (In reply to comment #10)
> > В порядке бреда: может это из-за того, что сейчас (118) утилиты udev* (в 
> > initrd) - это фактически хардлинки на один и тот же файл?
> 
> "Бред" подтвердился. Если заменить харлинки на симлинки и в mkinitrd сделать
> -Cp -aL /lib/mkinitrd/udev/* "$MNTDIR/"
> +Cp -a /lib/mkinitrd/udev/* "$MNTDIR/"
> неприятный эффект исчезает.

Т.е. либо сам initramfs с хардлинками получается кривой, либо ядро глючит
при обработке initramfs с хардлинками?
------- Comment #22 From 2008-09-01 00:44:46 -------
(In reply to comment #21)
> > "Бред" подтвердился. Если заменить харлинки на симлинки и в mkinitrd сделать
> > -Cp -aL /lib/mkinitrd/udev/* "$MNTDIR/"
> > +Cp -a /lib/mkinitrd/udev/* "$MNTDIR/"
> > неприятный эффект исчезает.
> 
> Т.е. либо сам initramfs с хардлинками получается кривой, либо ядро глючит
> при обработке initramfs с хардлинками?

Скорее, второе. Потому как с 2.6.25 - всё нормально.
Похоже, ядра до 2.6.25 (или 2.6.24?) некорректно обрабатывает хардлинки в
initramfs, считая их файлами с нулевым размером.
------- Comment #23 From 2008-09-01 00:50:48 -------
(In reply to comment #22)
> Скорее, второе. Потому как с 2.6.25 - всё нормально.
> Похоже, ядра до 2.6.25 (или 2.6.24?) некорректно обрабатывает хардлинки в initramfs,
> считая их файлами с нулевым размером.

Имеет ли смысл внедрять костыли в пакет udev-initramfs,
или все актуальные ядра в Сизифе уже исправлены?
------- Comment #24 From 2008-09-01 01:01:32 -------
(In reply to comment #23)
> Имеет ли смысл внедрять костыли в пакет udev-initramfs,
> или все актуальные ядра в Сизифе уже исправлены?

1) Ядра не исправлены.
2) Мне кажется, что "костыли" - это то, что в udev-initramfs сейчас. Потому как
в документации к udev ничего про хардлинки не говорится, а говорится как раз о
симлинках на udevadm

Также на костыль смахивает текущее
Cp -aL /lib/mkinitrd/udev/* "$MNTDIR/"
в mkinitrd. Зачем здесь разименовывать симлинки?
------- Comment #25 From 2008-09-01 01:33:35 -------
(In reply to comment #24)
> (In reply to comment #23)
> > Имеет ли смысл внедрять костыли в пакет udev-initramfs,
> > или все актуальные ядра в Сизифе уже исправлены?
> 
> 1) Ядра не исправлены.

Жаль.

> 2) Мне кажется, что "костыли" - это то, что в udev-initramfs сейчас. Потому как в
> документации к udev ничего про хардлинки не говорится, а говорится как раз о
> симлинках на udevadm

Давно там появились hardlink'и вместо symlink'ов?

> Также на костыль смахивает текущее
> Cp -aL /lib/mkinitrd/udev/* "$MNTDIR/"
> в mkinitrd. Зачем здесь разименовывать симлинки?

Вероятно, там раньше были абсолютные ссылки.
Если ссылки относительные в пределах /lib/mkinitrd/udev/,
то разыменовывать не надо.
------- Comment #26 From 2008-09-01 01:41:03 -------
(In reply to comment #25)
> (In reply to comment #24)
> > (In reply to comment #23)
> > > Имеет ли смысл внедрять костыли в пакет udev-initramfs,
> > > или все актуальные ядра в Сизифе уже исправлены?
> > 
> > 1) Ядра не исправлены.
> 
> Жаль.
> 
> > 2) Мне кажется, что "костыли" - это то, что в udev-initramfs сейчас. Потому как в
> > документации к udev ничего про хардлинки не говорится, а говорится как раз о
> > симлинках на udevadm
> 
> Давно там появились hardlink'и вместо symlink'ов?

Не "вместо". Раньше в udev-initramfs линков не было. Симлики рекумендуют (в
апстриме) делать на udevadm начиная с версии 117

> 
> > Также на костыль смахивает текущее
> > Cp -aL /lib/mkinitrd/udev/* "$MNTDIR/"
> > в mkinitrd. Зачем здесь разименовывать симлинки?
> 
> Вероятно, там раньше были абсолютные ссылки.

Не было. Скорее - обычный копипаст предидущей строки, когда udev у нас появился
в initrd.

> Если ссылки относительные в пределах /lib/mkinitrd/udev/,
> то разыменовывать не надо.

Об этом я и говорю.
------- Comment #27 From 2008-09-01 02:23:21 -------
(In reply to comment #26)
> > > 2) Мне кажется, что "костыли" - это то, что в udev-initramfs сейчас. Потому как в
> > > документации к udev ничего про хардлинки не говорится, а говорится как раз о
> > > симлинках на udevadm
> > 
> > Давно там появились hardlink'и вместо symlink'ов?
> 
> Не "вместо". Раньше в udev-initramfs линков не было. Симлики рекумендуют (в апстриме)
> делать на udevadm начиная с версии 117

OK, давайте сделаем ссылки.

> > > Также на костыль смахивает текущее
> > > Cp -aL /lib/mkinitrd/udev/* "$MNTDIR/"
> > > в mkinitrd. Зачем здесь разименовывать симлинки?
> > 
> > Вероятно, там раньше были абсолютные ссылки.
> 
> Не было. Скорее - обычный копипаст предидущей строки, когда udev у нас появился
> в initrd.
> 
> > Если ссылки относительные в пределах /lib/mkinitrd/udev/,
> > то разыменовывать не надо.
> 
> Об этом я и говорю.

В 3.0.6-alt1-1-gfe2c662 я убрал это разыменование ссылок.
------- Comment #28 From 2008-09-01 02:29:53 -------
(In reply to comment #27)
> В 3.0.6-alt1-1-gfe2c662 я убрал это разыменование ссылок.

Для /lib/mkinitrd/klibc/ не стоило этого делать
------- Comment #29 From 2008-09-01 14:19:56 -------
На самом деле с udev-118 и kernel-image-2.6.18-alt12 всё работает даже с
хардлинками в initramfs. Пожалуйста, назовите точные версии ядра, udev,
coreutils, mkinitrd, с которыми воспроизводится эта проблема.
------- Comment #30 From 2008-09-01 15:11:13 -------
Хардлинки, похоже, не при чём, а вот /lib/mkinitrd/udev/sbin/udevtrigger в
udev-initramfs-126-alt3, похоже, сломан - это можно наблюдать при загрузке с
break=mount.
------- Comment #31 From 2008-09-01 16:42:58 -------
(In reply to comment #30)
> Хардлинки, похоже, не при чём, а вот /lib/mkinitrd/udev/sbin/udevtrigger в udev-initramfs-126-alt3,
> похоже, сломан - это можно наблюдать при загрузке с break=mount.

Нет, udevtrigger не сломан, а вот в /etc/udev/initramfs-rules.d не хватает
нужных правил, в результате дополнительные модули в initramfs не грузятся
(также не работает загрузка firmware и, вероятно, ещё что-то).

Воспроизвести именно проблему с хардлинками так и не удалось - пожалуйста,
приложите пример образа initrd с отсутствующими udevtrigger и т.п., по
возможности с указанием рецепта его получения.
------- Comment #32 From 2008-09-01 16:56:08 -------
(In reply to comment #31)
> Нет, udevtrigger не сломан, а вот в /etc/udev/initramfs-rules.d не хватает нужных правил, в
> результате дополнительные модули в initramfs не грузятся (также не работает
> загрузка firmware и, вероятно, ещё что-то).

дополнительные модули не грузятся вообще или что то конкретное?
------- Comment #33 From 2008-09-01 17:27:54 -------
(In reply to comment #32)
> дополнительные модули не грузятся вообще или что то конкретное?

Не хватало 80-drivers.rules: 
http://git.altlinux.org/people/vsu/packages/?p=udev.git;a=commitdiff;h=f1abee5b02b5bce33ff184a18dcaaf20571ec208

Правило для firmware обнаружилось в 50-udev-default.rules (работоспособность в
initramfs пока не проверял).
------- Comment #34 From 2008-09-01 18:43:10 -------
(In reply to comment #32)
> дополнительные модули не грузятся вообще или что то конкретное?

Проверил udev-127-alt1 (0ee712a8dcdec2410f965d1848e72f6073b296b8) - теперь
загрузка дополнительных модулей из initramfs работает; также заработала
загрузка с корнем на md, заданным через UUID (в версии 126 это тоже было
сломано).
------- Comment #35 From 2008-09-01 19:53:50 -------
значит выкладываю
------- Comment #36 From 2008-09-01 20:19:45 -------
(In reply to comment #35)
> значит выкладываю

e6282b011d88172bfc7ff8abfee5eb2c7257a394 - /lib/firmware/$(uname -r) для
будущих ядер добавлять будем?
------- Comment #37 From 2008-09-01 20:45:00 -------
вообще надо. ща сделаю alt3
------- Comment #38 From 2008-09-02 15:32:29 -------
(In reply to comment #29)
> На самом деле с udev-118 и kernel-image-2.6.18-alt12 всё работает даже с хардлинками в initramfs.
> Пожалуйста, назовите точные версии ядра, udev, coreutils, mkinitrd, с которыми
> воспроизводится эта проблема.

Назвать могу, но, похоже, в этом нет смысла. Это был missconfiguration в
конкретном ядре:(
Кроме того, с udev-12x даже с симлинками перестало работать. 
------- Comment #39 From 2008-09-02 15:52:04 -------
(In reply to comment #38)
> Назвать могу, но, похоже, в этом нет смысла. Это был missconfiguration в
> конкретном ядре:(

Т.е., для изначальной формулировки этого бага получается RESOLVED/WORKSFORME?

> Кроме того, с udev-12x даже с симлинками перестало работать. 

Сборки udev-126-alt1..alt3 действительно сломаны в этом отношении - либо
откатите на предыдущую версию, либо обновите до udev-127-alt3, либо (временное
решение для udev-126-alt*) добавьте недостающий симлинк:

  ln -s ../../../lib/udev/rules.d/80-drivers.rules \
        /etc/udev/initramfs-rules.d/

и пересоздайте initrd (проверьте именно с mkinitrd-3.0.6-alt1 без
дополнительных патчей).
------- Comment #40 From 2008-09-02 16:15:21 -------
(In reply to comment #39)
> Т.е., для изначальной формулировки этого бага получается RESOLVED/WORKSFORME?

Если учтено http://bugzilla.altlinux.org/show_bug.cgi?id=16959 (Comment #3) -
тогда да
------- Comment #41 From 2008-09-02 18:09:53 -------
(In reply to comment #40)
> Если учтено http://bugzilla.altlinux.org/show_bug.cgi?id=16959 (Comment #3) - тогда да

В mkinitrd-3.0.8-alt1 учтено с сохранением совместимости со старыми версиями
udev, не имевшими утилиты udevadm.