Bug 15348

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 днями

повешенная на этот счёт бага поможет не забыть, кстати