15426 2008-04-21 19:24:39 +0400 init: udev* 2008-09-02 18:09:54 +0400 1 1 4 Development Sisyphus mkinitrd unstable all Linux CLOSED FIXED P2 normal --- 1 led mike icesik led mike shrek silicium vsu qa-sisyphus oldest_to_newest 68744 0 led 2008-04-21 19:24:39 +0400 Не является ли udevd udevtrigger udevsettle вместо /sbin/udevd /sbin/udevtrigger /sbin/udevsettle тщательно (или нечаянно) расставленными граблями (в /init)? 68745 1 mike 2008-04-21 20:11:27 +0400 Иными словами, у нас в initrd имени ltsp-mkbootiso вылезли штуки четыре /bin/sh: неполучаетсянайти udevsettle /bin/sh: неполучаетсянайти udevtrigger 68777 2 mike 2008-04-22 13:57:29 +0400 Здесь страньше. С 2.6.22 и сизифным udev (см.тж. Bug #15427) -- наблюдаются две проблемы. С тем же 2.6.22 и M40-ным udev -- всё в порядке. 2 led: похоже, я вчера не переписал образ, сгенерированный с сизифным udev, тем, который был собран с udev/mkinitrd из бранча. Это помимо того, что сказал "работает", загрузившись по PXE %). Так что давай сегодня более спокойно и без отвлечений проверим -- пока мне кажется, что пакеты из бранча (mkinitrd, udev, busybox? и ядро led-tc) в сумме ездят адекватно. Патчик-то привесь, в любом разе. 68780 3 led 2008-04-22 14:13:01 +0400 (In reply to comment #2) > Так что давай сегодня более спокойно и без > отвлечений проверим -- пока мне кажется, что пакеты из бранча (mkinitrd, udev, > busybox? В Сизифе только udev новый, mkinitrd и busybox - AFAIR те же > и ядро led-tc) в сумме ездят адекватно. > > Патчик-то привесь, в любом разе. Нету у меня "патчика" 68783 4 vsu 2008-04-22 14:38:16 +0400 (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 везде... 68784 5 led 2008-04-22 14:45:20 +0400 (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/ проблем и не возникает, а с "неявными" - возникают. 68785 6 led 2008-04-22 14:54:29 +0400 (In reply to comment #5) > Ну так вот: с явными /sbin/ проблем и не возникает, а с "неявными" - возникают. Справедливости ради, надо отметить, что проблемы начали вылазить после обновления udev до 118. Но ИМХО лучше перестраховаться от таких обновлений, тем более, что такая "перестраховка" ничего не стОит. 68965 7 icesik 2008-04-25 17:57:26 +0400 (In reply to comment #5) > Ну так вот: с явными /sbin/ проблем и не возникает, а с "неявными" - возникают. Споткнулся об эту же проблему. После правки /lib/mkinitrd/initramfs-base/init проблема ушла. 68979 8 vsu 2008-04-25 19:37:34 +0400 (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 исправляет ситуацию? 68980 9 led 2008-04-25 19:43:06 +0400 (In reply to comment #8) > Явное выставление PATH: > http://git.altlinux.org/people/vsu/packages/?p=mkinitrd.git;a=commitdiff;h=4744aec09e354a8c04a0922747dddbaf8d48a3d6 > исправляет ситуацию? У меня не исправляло. Правда, я не помню, делал ли export 68981 10 led 2008-04-25 19:45:29 +0400 В порядке бреда: может это из-за того, что сейчас (118) утилиты udev* (в initrd) - это фактически хардлинки на один и тот же файл? 68982 11 vsu 2008-04-25 19:48:40 +0400 А с какими ядрами проявляется эта проблема - как обычно, исключительно с теми, которые отсутствуют на git.alt? 68983 12 led 2008-04-25 19:56:28 +0400 (In reply to comment #10) > В порядке бреда: может это из-за того, что сейчас (118) утилиты udev* (в > initrd) - это фактически хардлинки на один и тот же файл? Возможно. Как-то не подумал, что для того, чтобы исправить ошибки sh или скрипта, нужно патчить ядро:) Как бы то ни было, до udev-118 это не проявлялось ни на каких ядрах, даже на самых что ни есть "ванильных". 68984 13 led 2008-04-25 19:57:56 +0400 (In reply to comment #12) > Возможно. Как-то не подумал, что для того, чтобы исправить ошибки sh или > скрипта, нужно патчить ядро:) > Как бы то ни было, до udev-118 это не проявлялось ни на каких ядрах, даже на > самых что ни есть "ванильных". Это был ответ на #11 (или багзилла глюкнула, или я промахнулся...) 68987 14 dottedmag 2008-04-25 20:11:58 +0400 (In reply to comment #13) > Это был ответ на #11 (или багзилла глюкнула, или я промахнулся...) [выныривая] Багзилла не глючит, она фундаментально ошибается! :) [нырнул обратно в дебри Bugzilla/DB/Schema.pm] 76608 15 led 2008-08-30 01:36:24 +0400 (In reply to comment #10) > В порядке бреда: может это из-за того, что сейчас (118) утилиты udev* (в > initrd) - это фактически хардлинки на один и тот же файл? "Бред" подтвердился. Если заменить харлинки на симлинки и в mkinitrd сделать -Cp -aL /lib/mkinitrd/udev/* "$MNTDIR/" +Cp -a /lib/mkinitrd/udev/* "$MNTDIR/" неприятный эффект исчезает. 76706 16 ldv 2008-08-31 12:54:14 +0400 (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 файловая система? 76707 17 led 2008-08-31 13:34:48 +0400 (In reply to comment #16) > Тогда это ядерные штучки. Интересно, кстати, какая у этого initrd файловая > система? initramfs 76719 18 ldv 2008-08-31 23:25:02 +0400 (In reply to comment #12) > (In reply to comment #10) > > В порядке бреда: может это из-за того, что сейчас (118) утилиты udev* (в > > initrd) - это фактически хардлинки на один и тот же файл? > > Возможно. Как-то не подумал, что для того, чтобы исправить ошибки sh или > скрипта, нужно патчить ядро:) Увы, это вполне вероятно. > Как бы то ни было, до udev-118 это не проявлялось ни на каких ядрах, даже на > самых что ни есть "ванильных". Так или иначе, но добавлять полный путь к udevtrigger -- это лишь маскировать проблему. Ладно, как эту ошибку воспроизводить? 76720 19 led 2008-08-31 23:55:20 +0400 (In reply to comment #18) > > Возможно. Как-то не подумал, что для того, чтобы исправить ошибки sh или > > скрипта, нужно патчить ядро:) > > Увы, это вполне вероятно. Это в идеале. Но можно обойтись и без этого. > Так или иначе, но добавлять полный путь к udevtrigger -- это лишь маскировать > проблему. Добавление "полного пути", к сожалению, никоим образом не решает проблему. > Ладно, как эту ошибку воспроизводить? mkinitrd --extra <etherboot-module> ... ethernet-модуль должен загрузиться ещё при обработке в initrd 76721 20 ldv 2008-09-01 00:28:21 +0400 (In reply to comment #19) > (In reply to comment #18) > > > Возможно. Как-то не подумал, что для того, чтобы исправить ошибки sh или > > > скрипта, нужно патчить ядро:) > > > > Увы, это вполне вероятно. > > Это в идеале. Но можно обойтись и без этого. > > > Так или иначе, но добавлять полный путь к udevtrigger -- это лишь маскировать > > проблему. > > Добавление "полного пути", к сожалению, никоим образом не решает проблему. Это хорошо, ибо уменьшает вероятность ошибки вне mkinitrd/udev. А каким образом удаётся решить проблему? 76723 21 ldv 2008-09-01 00:35:24 +0400 (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 с хардлинками? 76725 22 led 2008-09-01 00:44:46 +0400 (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, считая их файлами с нулевым размером. 76726 23 ldv 2008-09-01 00:50:48 +0400 (In reply to comment #22) > Скорее, второе. Потому как с 2.6.25 - всё нормально. > Похоже, ядра до 2.6.25 (или 2.6.24?) некорректно обрабатывает хардлинки в initramfs, > считая их файлами с нулевым размером. Имеет ли смысл внедрять костыли в пакет udev-initramfs, или все актуальные ядра в Сизифе уже исправлены? 76733 24 led 2008-09-01 01:01:32 +0400 (In reply to comment #23) > Имеет ли смысл внедрять костыли в пакет udev-initramfs, > или все актуальные ядра в Сизифе уже исправлены? 1) Ядра не исправлены. 2) Мне кажется, что "костыли" - это то, что в udev-initramfs сейчас. Потому как в документации к udev ничего про хардлинки не говорится, а говорится как раз о симлинках на udevadm Также на костыль смахивает текущее Cp -aL /lib/mkinitrd/udev/* "$MNTDIR/" в mkinitrd. Зачем здесь разименовывать симлинки? 76740 25 ldv 2008-09-01 01:33:35 +0400 (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/, то разыменовывать не надо. 76741 26 led 2008-09-01 01:41:03 +0400 (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/, > то разыменовывать не надо. Об этом я и говорю. 76742 27 ldv 2008-09-01 02:23:21 +0400 (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 я убрал это разыменование ссылок. 76745 28 led 2008-09-01 02:29:53 +0400 (In reply to comment #27) > В 3.0.6-alt1-1-gfe2c662 я убрал это разыменование ссылок. Для /lib/mkinitrd/klibc/ не стоило этого делать 76768 29 vsu 2008-09-01 14:19:56 +0400 На самом деле с udev-118 и kernel-image-2.6.18-alt12 всё работает даже с хардлинками в initramfs. Пожалуйста, назовите точные версии ядра, udev, coreutils, mkinitrd, с которыми воспроизводится эта проблема. 76770 30 vsu 2008-09-01 15:11:13 +0400 Хардлинки, похоже, не при чём, а вот /lib/mkinitrd/udev/sbin/udevtrigger в udev-initramfs-126-alt3, похоже, сломан - это можно наблюдать при загрузке с break=mount. 76780 31 vsu 2008-09-01 16:42:58 +0400 (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 и т.п., по возможности с указанием рецепта его получения. 76784 32 shrek 2008-09-01 16:56:08 +0400 (In reply to comment #31) > Нет, udevtrigger не сломан, а вот в /etc/udev/initramfs-rules.d не хватает нужных правил, в > результате дополнительные модули в initramfs не грузятся (также не работает > загрузка firmware и, вероятно, ещё что-то). дополнительные модули не грузятся вообще или что то конкретное? 76787 33 vsu 2008-09-01 17:27:54 +0400 (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 пока не проверял). 76810 34 vsu 2008-09-01 18:43:10 +0400 (In reply to comment #32) > дополнительные модули не грузятся вообще или что то конкретное? Проверил udev-127-alt1 (0ee712a8dcdec2410f965d1848e72f6073b296b8) - теперь загрузка дополнительных модулей из initramfs работает; также заработала загрузка с корнем на md, заданным через UUID (в версии 126 это тоже было сломано). 76828 35 shrek 2008-09-01 19:53:50 +0400 значит выкладываю 76832 36 vsu 2008-09-01 20:19:45 +0400 (In reply to comment #35) > значит выкладываю e6282b011d88172bfc7ff8abfee5eb2c7257a394 - /lib/firmware/$(uname -r) для будущих ядер добавлять будем? 76836 37 shrek 2008-09-01 20:45:00 +0400 вообще надо. ща сделаю alt3 76890 38 led 2008-09-02 15:32:29 +0400 (In reply to comment #29) > На самом деле с udev-118 и kernel-image-2.6.18-alt12 всё работает даже с хардлинками в initramfs. > Пожалуйста, назовите точные версии ядра, udev, coreutils, mkinitrd, с которыми > воспроизводится эта проблема. Назвать могу, но, похоже, в этом нет смысла. Это был missconfiguration в конкретном ядре:( Кроме того, с udev-12x даже с симлинками перестало работать. 76893 39 vsu 2008-09-02 15:52:04 +0400 (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 без дополнительных патчей). 76894 40 led 2008-09-02 16:15:21 +0400 (In reply to comment #39) > Т.е., для изначальной формулировки этого бага получается RESOLVED/WORKSFORME? Если учтено http://bugzilla.altlinux.org/show_bug.cgi?id=16959 (Comment #3) - тогда да 76898 41 vsu 2008-09-02 18:09:53 +0400 (In reply to comment #40) > Если учтено http://bugzilla.altlinux.org/show_bug.cgi?id=16959 (Comment #3) - тогда да В mkinitrd-3.0.8-alt1 учтено с сохранением совместимости со старыми версиями udev, не имевшими утилиты udevadm.