При новой установке Ubuntu Server 13.10 (x64) возникают проблемы с загрузкой из корневого тома, расположенного в md + lvm. На данный момент я приготовил решение, но я хотел бы больше узнать о том, что происходит, и о том, какие решения могут быть лучше.
Поскольку цель этой машины - экспериментировать с Xen (чтобы лучше понять коммерческий хостинг виртуальных машин), машина собрана из частей, которые мне нужны, а именно: Q6600 + Asus P5QL Pro, 1 ТБ и 500 ГБ SATA-дисков. (хотя диск на 500 ГБ все еще используется в других местах, он будет добавлен позже.)
Диск емкостью 1 ТБ имеет три раздела: sda1 соответствует размеру sdb1 на диске 500 ГБ, sda2 - swap, а остаток - sda3. md0 - это том RAID1 [1], состоящий из sda1 + sdb1, и это единственный PV, доступный для LVM.
Ubuntu установлен на двух LV (dom0_root и dom0_homes) в этом VG (vg_mir), а / boot находится в dom0_root.
Конкретная проблема проявляется в следующих сообщениях сразу после инициализации дисков:
kernel: [ 3.003506] md: bind<sda1>
kernel: [ 3.007705] md/raid1:md0: active with 1 out of 1 mirrors
kernel: [ 3.007768] md0: detected capacity change from 0 to 499972440064
kernel: [ 3.047284] md0: unknown partition table
kernel: [ 3.124709] device-mapper: table: 252:0: linear: dm-linear: Device lookup failed
kernel: [ 3.124759] device-mapper: ioctl: error adding target to table
kernel: [ 3.125156] device-mapper: table: 252:1: linear: dm-linear: Device lookup failed
kernel: [ 3.125196] device-mapper: ioctl: error adding target to table
После паузы он сдается и переходит в оболочку initramfs. Выдача команды lvm vgchange -ay LVM успешно инициализируется, / dev / mapper заполняется должным образом, и система загружается нормально после нажатия ^ D.
Сделав копию /lib/udev/rules.d/85-lvm2.rules в / etc и вставив sleep 1 как показано здесь:
SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_FS_TYPE}=="lvm*|LVM*", \
RUN+="watershed sh -c 'sleep 1; /sbin/lvm vgscan; /sbin/lvm vgchange -a y'"
(и перестройка initramfs) теперь система загружается без посторонней помощи, но это довольно ужасное решение. Я пробовал возиться с rootwait=, lvmwait= и scsi_mod.scan=sync параметры ядра, как описано в различных трекерах ошибок и сообщениях в блогах, но все, что я пробовал, не сработало. Несколько страниц предполагают, что проблема с evms, но она, похоже, не установлена. Другие предлагают тайм-ауты на нерелевантных блочных устройствах, и я даже отключил DVD-привод.
Похоже, что между md и lvm существует какое-то состояние гонки, и lvm вызывается udev до того, как md0 готов. Эти аргументы ядра, кажется, вставляют задержку после lvm запущен, поэтому никакое ожидание не поможет, потому что LV никогда не будут готовы, потому что vgchange уже был запущен (и не прошел).
На этом я дошел до проблемы. Может ли кто-нибудь предложить лучшее решение или предложить, как углубиться, чтобы найти больше проблемы?
[1] поскольку sdb1 на данный момент отсутствует, этот том raid вручную настроен как RAID1 с 1 устройством, потому что Ubuntu не любит загрузку с деградированного тома.
У меня была такая же проблема, очевидно, с тем же типом оборудования и свежей установкой 13.10 x64. Будучи менее опытным, я потратил пару дней на поиски возможных отсутствующих модулей ядра и т. Д., Но после прочтения вашего отчета я обнаружил, что vgchange -ay в приглашении initramfs busybox действительно делает систему загрузочной. Я еще не пробовал описанный вами обходной путь 1-секундной задержки (буду), но я также отмечаю следующий отчет об ошибке Debian, который может быть связан:
У меня была такая же проблема, и после поиска я обнаружил, что это решение работал у меня. Мне просто пришлось переименовать все /dev/md/* устройства для /dev/md* устройства в /etc/mdadm/mdadm.conf и беги update-initramfs -u для обновления initramfs.