В новой UDEV-ной версии пропагатор не ждёт инициализации USB-устройств и ругается, что диск не найден.
fixed in 20080301-alt4
Формально оно closed :) Но есть такие мысли. Я использую для загрузки USB-устройств сильно урезанный по составу список modules, только необходимые модули - оно вроде и побыстрее грузится, и потенциально больше шансов загрузиться на системах со странными контроллерами (кстати, правильно я понимаю, что noload= больше не работает?). Так вот с этим modules, когда дело доходит до проверки наличия /sys/module/usb_storage, этой директории, судя по всему, еще нету. Выручает sleep(1) перед этой проверкой.
Created attachment 2574 [details] Мой список модулей, достаточных для загрузки с USB.
То есть, этот sleep(1) нужен при урезанном modules и не нужен при обычном ? и да, noload больше не работает -- можно подкладывать в initramfs /etc/modprobe.d/blacklist-local какой-нибудь.
(In reply to comment #4) > и да, noload больше не работает -- можно подкладывать в > initramfs /etc/modprobe.d/blacklist-local какой-нибудь. Боюсь, это не очень хороший вариант на местности... суппорт застрелится.
(In reply to comment #4) > То есть, этот sleep(1) нужен при урезанном modules и не нужен при обычном ? Получается, что так. Хотя, учитывая, что машинки могут быть очень разные, я бы сказал так, что могут быть ситуации, когда usb_storage не успевает загружаться до проверки. > и да, noload больше не работает -- можно подкладывать в > initramfs /etc/modprobe.d/blacklist-local какой-нибудь. Функциональность noload была иногда затребована народом, по крайней мере, на старом пропагаторе. Отсюда же и мой урезанный modules. А initramfs - это же пересобирать initrd надо, да? Не end-user решение :)
про noload: это был кривопридуманный и кривосделанный хак, мне его не жалко. внедрение udev в propagator имело целью обеспечить одинаковое с установленной системой поведение при обнаружении устройств. если считается, что подобная возможность нужна -- предлагаю доказывать это майнтайнеру udev, не мне.
по поводу урезанного modules -- я не вижу в этом смысла. ощутимо быстрее оно не будет, а разговоры о потенциально бОльших шансах загрузиться и т.д. хорошо бы проиллюстрировать примером. бишь, покажите мне проблему -- и мы её решим :)
(In reply to comment #8) > по поводу урезанного modules -- я не вижу в этом смысла. > ощутимо быстрее оно не будет, а разговоры о потенциально бОльших > шансах загрузиться и т.д. хорошо бы проиллюстрировать примером. Ну лично я видел один такой компьютер видел где-то в июле - на нём не смог загрузиться liveCD четвёртого десктопа - какой-то модуль из разряда sata/piix пытался минут сорок чего-то сделать, больше я не выдержал. Тогда так и не одолел. Сейчас к этому компу уж не знаю, попаду ли когда-нибудь. Надо еще будет спросить людей, которые noload пользовались. > бишь, покажите мне проблему -- и мы её решим :) ок :) приберегу пока этот патчик для себя, любимого. :)
Кстати, в свете всяких там usb-storage-zerowait в новых ядрах, возможно будет интересна "мягкая" задержка для инициализации: http://git.altlinux.org/people/prividen/packages/?p=propagator.git;a=summary
идея понятна. привлекательным было бы использовать uuid, имена устройств имеют свойство прыгать.
(поразмыслив) скорее label
(In reply to comment #11) > идея понятна. > привлекательным было бы использовать uuid, имена устройств > имеют свойство прыгать. > OMG, на это еще не тестировал (потенциально еще один плюс сокращённого modules). Ну в большинстве случаев, флешка получается sda. Однако тогда надо сначала поддержку label в параметрах, чтобы propagator умел находить загрузочное устройство по метке.
libata и прочие прелести прогресса увеличивают вероятность того, что hd* вообще в сиссеме не будет, сплошной sd*. не хотелось бы загибать пальцы на руке, вычисляя, какая же циферька выпадет флешке. в общем, мне подождать патча или самому что-то выпиливать ?
(In reply to comment #10) > Кстати, в свете всяких там usb-storage-zerowait в новых ядрах Это вообще-то хак^H^H^Hэксперимент -- не думаю, что стоит на него закладываться.
(In reply to comment #14) > libata и прочие прелести прогресса увеличивают вероятность того, > что hd* вообще в сиссеме не будет, сплошной sd*. > не хотелось бы загибать пальцы на руке, вычисляя, > какая же циферька выпадет флешке. Во-во... Может, добавить новый method usb? > в общем, мне подождать патча или самому что-то выпиливать ? боюсь, ниасилю :(( Я си вообще не знаю. И смогу что-то посмотреть не ранее, как через неделю. Кстати: по UUID тоже можно. Нету никаких проблем нарисовать скриптик для сотворения загрузочной флешки (usb-hdd), который бы узнавал uuid нужной партиции и учитывал его в syslinux.cfg. Насколько я понимаю, с UUID будет гораздо проще, чем с label (/dev/disk/by-uuid/)
(In reply to comment #15) > (In reply to comment #10) > > Кстати, в свете всяких там usb-storage-zerowait в новых ядрах > Это вообще-то хак^H^H^Hэксперимент -- не думаю, что стоит на него закладываться. Как раз задержка на 5 секунд - это хак. Хотя, не исключено, что без этого хака что-то не будет работать (но мне такое не попадалось)
(In reply to comment #8) > по поводу урезанного modules -- я не вижу в этом смысла. > ощутимо быстрее оно не будет, а разговоры о потенциально бОльших > шансах загрузиться и т.д. хорошо бы проиллюстрировать примером. > бишь, покажите мне проблему -- и мы её решим :) Ну вот проблемка и вылезла - с ядром 2.6.24-std-def-alt8 на ноуте на место sda радостно влезает винчестер вместо флешки. Пока нету поддержки label, спасаюсь урезанным modules.
оки, сделаю label/uuid днями
повешенная на этот счёт бага поможет не забыть, кстати
