Не является ли udevd udevtrigger udevsettle вместо /sbin/udevd /sbin/udevtrigger /sbin/udevsettle тщательно (или нечаянно) расставленными граблями (в /init)?
Иными словами, у нас в initrd имени ltsp-mkbootiso вылезли штуки четыре /bin/sh: неполучаетсянайти udevsettle /bin/sh: неполучаетсянайти udevtrigger
Здесь страньше. С 2.6.22 и сизифным udev (см.тж. Bug #15427) -- наблюдаются две проблемы. С тем же 2.6.22 и M40-ным udev -- всё в порядке. 2 led: похоже, я вчера не переписал образ, сгенерированный с сизифным udev, тем, который был собран с udev/mkinitrd из бранча. Это помимо того, что сказал "работает", загрузившись по PXE %). Так что давай сегодня более спокойно и без отвлечений проверим -- пока мне кажется, что пакеты из бранча (mkinitrd, udev, busybox? и ядро led-tc) в сумме ездят адекватно. Патчик-то привесь, в любом разе.
(In reply to comment #2) > Так что давай сегодня более спокойно и без > отвлечений проверим -- пока мне кажется, что пакеты из бранча (mkinitrd, udev, > busybox? В Сизифе только udev новый, mkinitrd и busybox - AFAIR те же > и ядро led-tc) в сумме ездят адекватно. > > Патчик-то привесь, в любом разе. Нету у меня "патчика"
(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 везде...
(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/ проблем и не возникает, а с "неявными" - возникают.
(In reply to comment #5) > Ну так вот: с явными /sbin/ проблем и не возникает, а с "неявными" - возникают. Справедливости ради, надо отметить, что проблемы начали вылазить после обновления udev до 118. Но ИМХО лучше перестраховаться от таких обновлений, тем более, что такая "перестраховка" ничего не стОит.
(In reply to comment #5) > Ну так вот: с явными /sbin/ проблем и не возникает, а с "неявными" - возникают. Споткнулся об эту же проблему. После правки /lib/mkinitrd/initramfs-base/init проблема ушла.
(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 исправляет ситуацию?
(In reply to comment #8) > Явное выставление PATH: > http://git.altlinux.org/people/vsu/packages/?p=mkinitrd.git;a=commitdiff;h=4744aec09e354a8c04a0922747dddbaf8d48a3d6 > исправляет ситуацию? У меня не исправляло. Правда, я не помню, делал ли export
В порядке бреда: может это из-за того, что сейчас (118) утилиты udev* (в initrd) - это фактически хардлинки на один и тот же файл?
А с какими ядрами проявляется эта проблема - как обычно, исключительно с теми, которые отсутствуют на git.alt?
(In reply to comment #10) > В порядке бреда: может это из-за того, что сейчас (118) утилиты udev* (в > initrd) - это фактически хардлинки на один и тот же файл? Возможно. Как-то не подумал, что для того, чтобы исправить ошибки sh или скрипта, нужно патчить ядро:) Как бы то ни было, до udev-118 это не проявлялось ни на каких ядрах, даже на самых что ни есть "ванильных".
(In reply to comment #12) > Возможно. Как-то не подумал, что для того, чтобы исправить ошибки sh или > скрипта, нужно патчить ядро:) > Как бы то ни было, до udev-118 это не проявлялось ни на каких ядрах, даже на > самых что ни есть "ванильных". Это был ответ на #11 (или багзилла глюкнула, или я промахнулся...)
(In reply to comment #13) > Это был ответ на #11 (или багзилла глюкнула, или я промахнулся...) [выныривая] Багзилла не глючит, она фундаментально ошибается! :) [нырнул обратно в дебри Bugzilla/DB/Schema.pm]
(In reply to comment #10) > В порядке бреда: может это из-за того, что сейчас (118) утилиты udev* (в > initrd) - это фактически хардлинки на один и тот же файл? "Бред" подтвердился. Если заменить харлинки на симлинки и в mkinitrd сделать -Cp -aL /lib/mkinitrd/udev/* "$MNTDIR/" +Cp -a /lib/mkinitrd/udev/* "$MNTDIR/" неприятный эффект исчезает.
(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 файловая система?
(In reply to comment #16) > Тогда это ядерные штучки. Интересно, кстати, какая у этого initrd файловая > система? initramfs
(In reply to comment #12) > (In reply to comment #10) > > В порядке бреда: может это из-за того, что сейчас (118) утилиты udev* (в > > initrd) - это фактически хардлинки на один и тот же файл? > > Возможно. Как-то не подумал, что для того, чтобы исправить ошибки sh или > скрипта, нужно патчить ядро:) Увы, это вполне вероятно. > Как бы то ни было, до udev-118 это не проявлялось ни на каких ядрах, даже на > самых что ни есть "ванильных". Так или иначе, но добавлять полный путь к udevtrigger -- это лишь маскировать проблему. Ладно, как эту ошибку воспроизводить?
(In reply to comment #18) > > Возможно. Как-то не подумал, что для того, чтобы исправить ошибки sh или > > скрипта, нужно патчить ядро:) > > Увы, это вполне вероятно. Это в идеале. Но можно обойтись и без этого. > Так или иначе, но добавлять полный путь к udevtrigger -- это лишь маскировать > проблему. Добавление "полного пути", к сожалению, никоим образом не решает проблему. > Ладно, как эту ошибку воспроизводить? mkinitrd --extra <etherboot-module> ... ethernet-модуль должен загрузиться ещё при обработке в initrd
(In reply to comment #19) > (In reply to comment #18) > > > Возможно. Как-то не подумал, что для того, чтобы исправить ошибки sh или > > > скрипта, нужно патчить ядро:) > > > > Увы, это вполне вероятно. > > Это в идеале. Но можно обойтись и без этого. > > > Так или иначе, но добавлять полный путь к udevtrigger -- это лишь маскировать > > проблему. > > Добавление "полного пути", к сожалению, никоим образом не решает проблему. Это хорошо, ибо уменьшает вероятность ошибки вне mkinitrd/udev. А каким образом удаётся решить проблему?
(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 с хардлинками?
(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, считая их файлами с нулевым размером.
(In reply to comment #22) > Скорее, второе. Потому как с 2.6.25 - всё нормально. > Похоже, ядра до 2.6.25 (или 2.6.24?) некорректно обрабатывает хардлинки в initramfs, > считая их файлами с нулевым размером. Имеет ли смысл внедрять костыли в пакет udev-initramfs, или все актуальные ядра в Сизифе уже исправлены?
(In reply to comment #23) > Имеет ли смысл внедрять костыли в пакет udev-initramfs, > или все актуальные ядра в Сизифе уже исправлены? 1) Ядра не исправлены. 2) Мне кажется, что "костыли" - это то, что в udev-initramfs сейчас. Потому как в документации к udev ничего про хардлинки не говорится, а говорится как раз о симлинках на udevadm Также на костыль смахивает текущее Cp -aL /lib/mkinitrd/udev/* "$MNTDIR/" в mkinitrd. Зачем здесь разименовывать симлинки?
(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/, то разыменовывать не надо.
(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/, > то разыменовывать не надо. Об этом я и говорю.
(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 я убрал это разыменование ссылок.
(In reply to comment #27) > В 3.0.6-alt1-1-gfe2c662 я убрал это разыменование ссылок. Для /lib/mkinitrd/klibc/ не стоило этого делать
На самом деле с udev-118 и kernel-image-2.6.18-alt12 всё работает даже с хардлинками в initramfs. Пожалуйста, назовите точные версии ядра, udev, coreutils, mkinitrd, с которыми воспроизводится эта проблема.
Хардлинки, похоже, не при чём, а вот /lib/mkinitrd/udev/sbin/udevtrigger в udev-initramfs-126-alt3, похоже, сломан - это можно наблюдать при загрузке с break=mount.
(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 и т.п., по возможности с указанием рецепта его получения.
(In reply to comment #31) > Нет, udevtrigger не сломан, а вот в /etc/udev/initramfs-rules.d не хватает нужных правил, в > результате дополнительные модули в initramfs не грузятся (также не работает > загрузка firmware и, вероятно, ещё что-то). дополнительные модули не грузятся вообще или что то конкретное?
(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 пока не проверял).
(In reply to comment #32) > дополнительные модули не грузятся вообще или что то конкретное? Проверил udev-127-alt1 (0ee712a8dcdec2410f965d1848e72f6073b296b8) - теперь загрузка дополнительных модулей из initramfs работает; также заработала загрузка с корнем на md, заданным через UUID (в версии 126 это тоже было сломано).
значит выкладываю
(In reply to comment #35) > значит выкладываю e6282b011d88172bfc7ff8abfee5eb2c7257a394 - /lib/firmware/$(uname -r) для будущих ядер добавлять будем?
вообще надо. ща сделаю alt3
(In reply to comment #29) > На самом деле с udev-118 и kernel-image-2.6.18-alt12 всё работает даже с хардлинками в initramfs. > Пожалуйста, назовите точные версии ядра, udev, coreutils, mkinitrd, с которыми > воспроизводится эта проблема. Назвать могу, но, похоже, в этом нет смысла. Это был missconfiguration в конкретном ядре:( Кроме того, с udev-12x даже с симлинками перестало работать.
(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 без дополнительных патчей).
(In reply to comment #39) > Т.е., для изначальной формулировки этого бага получается RESOLVED/WORKSFORME? Если учтено http://bugzilla.altlinux.org/show_bug.cgi?id=16959 (Comment #3) - тогда да
(In reply to comment #40) > Если учтено http://bugzilla.altlinux.org/show_bug.cgi?id=16959 (Comment #3) - тогда да В mkinitrd-3.0.8-alt1 учтено с сохранением совместимости со старыми версиями udev, не имевшими утилиты udevadm.
