Проблема с запуском Arch [РЕШЕНО]

R.V.
1) При загрузке корень берётся из параметра root= ядра, а НЕ из fstab, потому что этот самый fstab, как нетрудно догадаться, находится в том самом корне, который ещё не найден и не смонтирован.
2) Указание раздела по UUID подразумевает, что этот UUID надо искать по ВСЕМ доступным на этот момент дискам. Собственно, UUID никак не привязан к диску и даже разделу, это внутреннее свойство записанной в разделе ФС или свапа.
3) Никакие другие разделы не мешают искать заданный UUID, если их UUID отличаются от него.
4) Искать раздел по UUID мешает отсутствие доступа к диску, на котором находится искомый раздел. Поскольку автор темы с самого начала показал, что диск с искомым разделом таки присутствует, но почему-то не виден на этапе initrd, становится очевидно, что причина – отсутствие у ядра на этом этапе драйвера для доступа к этому диску. Решение – на первый раз использовать fallback-сборку со всеми наличными модулями, а после успешной загрузки пересобрать наконец штатный initrd с включением в него нужных для загрузки именно на этой машине модулей.
5) Опыт это хорошо, но его ещё нужно осмыслить. В противном случае получается шаманство – подуть в трубу и протереть зеркало, тогда заведётся :)
R.V., рекомендую переименовать название файла /etc/fstab и загрузиться + поработать без fstab.
Ошибки не исчезают с опытом - они просто умнеют
Я тоже думаю, что скоро мы раскроем все секреты шаманов и даже интернет не нужен будет. Будем обмениваться мыслями и образами. :)
Отсутствия у ядра драйвера для доступа к диску на этапе загрузки системы приводит к вопросу, как же система тогда установилась?

В моей ситуации было три одновременно подключенных жестких диска. На два из них (определив их, как sda и sdb) установилась без проблем одна система. На третий диск sdc - вторая (тоже при установке определив его именно как sdc). Первая потом и работала без проблем, а вторая не загружалась и ругалась очень похоже, как и у автора темы. Последующий анализ показал, что уже уставленная вторая система определяет свой диск как тоже sda, а остальные как sdb и sdc, соответственно. Как-то я там с ними воевал и /etc/fstab сносил, но не получилось победить тогда.

Неожиданное решение. Буду осмысливать. :)
R.V., у меня в машине пять носителей, две ssd-шки и три винта, на 320, 500 и 1000 гиг, стоит Арч, Центось и вендовоз, ни разу не было никаких проблем. В fstab не смотрю, точки монтирования назначаю через gnome-disk-utility.

Centos 7 установлен на /dev/sde/.
In Tux We Trust
R.V., дык, дабы не было подобного бардака, разделу и присваивается уникальный идентификатор.

redix
у меня в машине пять носителей, две ssd-шки и три винта, на 320, 500 и 1000 гиг, стоит Арч, Центось и вендовоз
Жесть. Даже боюсь спрашивать зачем столько всего...
Три системы, каждая на отдельном носителе, терабайтник в качестве файлопомойки, на пятом ставлю опыты над пингвинами (по настроению).
In Tux We Trust
R.V.
Отсутствия у ядра драйвера для доступа к диску на этапе загрузки системы приводит к вопросу, как же система тогда установилась?
Драйвер всегда был, но чтобы его модуль был доступен на этапе загрузки, нужно было собрать новый initrd командой mkinitcpio -P, что очевидно, не было сделано.
При установке ядро грузится с "большим и толстым" initrd, аналогичным fallback-сборке, где есть сразу все драйверы, которые могут понадобиться для досутпа к дискам и ФС на различных машинах.
Aivar
дык, дабы не было подобного бардака, разделу и присваивается уникальный идентификатор.
Дык посмотрите, что у автора топика UUID e9e03b5c-a99b-4dc7-ab03-0e6c8a1d5929, например, в fstab помечен как sdd2, а blkid выдает, что это sda2. То же самое с sdd1 и sda1. Драйверы, оказывается...

redix
ни разу не было никаких проблем
Мои поздравления. Только системы мы устанавливали с Вами не в одно и тоже время и не с одних и тех же образов диска.
Omnia mutabantur, mutantur, mutabuntur.
Natrio, спасибо за подробное объяснение. Учтем... :)
 
Зарегистрироваться или войдите чтобы оставить сообщение.