Bug 9455

Я полагаю, что это опять udev'овский race.

Судя по всему нужно udev переносить в rc.sysinit.

А версия udev какая ?

(In reply to comment #3)
> А версия udev какая ?
> 

все самое свежее из сизифа

# rpm -qa | egrep "startup|udev"
libstartup-notification-0.8-alt2
udev-090-alt2
startup-0.9.8.4-alt1
udev_static-addon-0.1-alt1

правда udev-090-alt2 приехал сегодня, на нем я не проверял, имеет смысл
перегрузиться и проверить? или там ничего существенного, относительно
обсуждаемой темы, не изменилось?

Как раз на нём имеет смысл проверить - там была предпринята попытка поборосться
с race'ами

(In reply to comment #5)
> Как раз на нём имеет смысл проверить - там была предпринята попытка поборосться
> с race'ами
> 

проверил, результат тот же, предварительно пересоздал initrd(не знаю как сейчас,
но раньше mkinitrd не добавлял sd_mod при использовании sata_nv, из-за этого не
грузился рутовый раздели не только).
после создания устройства для device-mapper'а, идет проверка локальных fs, после
чего вываливаемся на их проверку из-за невозможности найти указанные устройства
/dev/sdc1 и т.д. затем спустя еще несколько процессов переходим в init3 или
init5, после чего стартует udevd...

я не спец-ядерщик, но по-моему проблема возникает еще до старта udev, возможно
либо статические устройства должны быть созданы заранее/либо надо дать больше
времени на инициализацию устройств...

rpm -qa|grep dev

2ldv: это вылезает из-за того, что udev запускается слишком поздно.. надо udev
start перенести в rc.sysinit

(In reply to comment #7)
> rpm -qa|grep dev
> 

# rpm -qa|grep -c dev
346

# rpm -qa|grep  ^dev
dev-3.3.1-alt13.1
dev86-0.16.17-alt3
dev86-devel-0.16.17-alt3

Проверьте с udev-091-alt3
или 092-alt1

(In reply to comment #10)
> Проверьте с udev-091-alt3
> или 092-alt1
> 

udev-091-alt3
проблема осталась на месте.

честно говоря, я не понимаю как может пакет udev повлиять на определение всех
носителей до старата сервиса, который запускается в 5ом ранлевеле, в то время
как определение носителей происходит из rc.sysinit.
если же ожидалось, что оставшиеся разделы будут смонтированы после старта
сервиса            udev, то этого не произошло.

тогда эта проблема не имеет отношения к udev

mount -a не ошибается.
Неужели не понятно, что это udev'ный race?

(In reply to comment #13)
> mount -a не ошибается.
> Неужели не понятно, что это udev'ный race?

Уважаемые, я не силен в том, откуда берутся устройства при загрузке, в момент
когда отрабатывает только initrd, но проблема именно в этом. именно на этом
этапе количество устройств по разделам дисков по каким-то причинам меньше, чем
есть на самом деле, возможно это проблема из-за скорости их определения,т.е.
процесс монтирования разделов начинается раньше, чем закончили создаваться
устройства для монтируемых разделов, потому mount и не видит указанный разделы.В
моих письмах есть перечень разделов при загрузке и после загрузки, сервис udev
стартует уже во 3,5 уровнях и к началу загрузки системы не имеет отношения,
поэтому , на мой взгялд, и надо смотреть на то, что происходит при стартапе.
Если количество разделов фиксировано на начальном этапе, то это количество надо
 увеличить, если оно создается динамически, то надо понять, почему создаются не
все устройства.

(In reply to comment #13)
> mount -a не ошибается.
> Неужели не понятно, что это udev'ный race?

Это не может быть udev'овским race'ом - mount -a выполняется намного раньше
сервиса udevd

Слушайте, пакет startup не занимается созданием устройств.
Пожалуйста, либо перевесьте проблему на тот пакет, который не создает требуемые
устройства, либо объясните, почему вы видите проблему в rc.sysinit и что вы
предлагаете в нём менять.

$ rpmquery -f /dev/sda9 /dev/sdb2 /dev/sdc1
dev-3.3.1-alt13.1
dev-3.3.1-alt13.1
dev-3.3.1-alt13.1

Reporter fails to explain how to reproduce the issue,
so I suspect that his problem is due to local misconfiguration.

(In reply to comment #17)
> $ rpmquery -f /dev/sda9 /dev/sdb2 /dev/sdc1
> dev-3.3.1-alt13.1
> dev-3.3.1-alt13.1
> dev-3.3.1-alt13.1
> 
> Reporter fails to explain how to reproduce the issue,
> so I suspect that his problem is due to local misconfiguration.

афигенная резолюция, так держать.
о какой ошибке в локальной конфигурации идет речь? мало той информации,что была
дана в самом начале 8 месяцев назад? присмотритесь внимательно к номерам и
количеству разделов до и после старта системы и не надо сваливать на конечного
пользователя, разбираться какой сервис в этом виноват - не моя забота, я
рапортовал о проблеме с максимально полным описанием, то что вы не можете
воспроизвести такую ситуацию по причине отсутствия такого количества разделов,
не говорит об отсутствии такой проблемы с таким количеством разделов.

не серьезный подход, пахнет стрелочниками.

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