Обновите до 12.04LTS дампы к busybox на начальной загрузке
Я просто обновил свой сервер от 10.04LTS до 12.04 LTS использование процесса обновления сервера, зарегистрированного здесь: https://help.ubuntu.com/community/PreciseUpgrades.
На начальной загрузке я теперь вывожусь к оболочке busybox (больше на этом через мгновение). Однако, если я загружаю ядро от предыдущего выпуска, все загружается прекрасный.
Единственная вещь, нечетная о моей конфигурации, состоит в том, что мое устройство загрузки является многодисковым устройством с помощью RAID1. Когда я добираюсь до оболочки busybox, ввод "монтируют, что корень/dev/md0 /" работает просто великолепно. Я попытался передать в rootdelay=30, и я вывожусь к оболочке в течение 5 секунд после начальной загрузки.
В отличие от вопроса, отмеченного здесь: Обновленный от 10,04 до 12,04 и личинка спадает до подсказки BusyBox без ошибки, которую я не загружал со всплеском или подавляю шумы опции, и я не получил жалоб на ухудшенный массив. Тем не менее, я попытался загрузиться с bootdegraded опцией ядра, и это не работало также.
Какие-либо мысли о том, что попробовать?
(И да, источник питания включается :-))
Информация о конфигурации:
Версия личинки: личинка (ЛИЧИНКА GNU 0.97)
Большая часть личинки menu.lst опции комментируется (для использования значений по умолчанию). Новое ядро, которое не работает:
title Ubuntu 12.04.2 LTS, kernel 3.2.0-51-generic-pae root (hd0,1) kernel /boot/vmlinuz-3.2.0-51-generic-pae root=/dev/md0 ro initrd /boot/initrd.img-3.2.0-51-generic-pae quiet
Новое ядро, которое действительно работает:
title Ubuntu 12.04.2 LTS, kernel 2.6.32-46-generic-pae root (hd0,1) kernel /boot/vmlinuz-2.6.32-46-generic-pae root=/dev/md0 ro initrd /boot/initrd.img-2.6.32-46-generic-pae quiet
информация о mdadm:
garrett@stargate:/boot/grub$ sudo mdadm --detail /dev/md0
/dev/md0:
Version : 0.90
Creation Time : Sat Dec 16 22:27:17 2006
Raid Level : raid1
Array Size : 57609024 (54.94 GiB 58.99 GB)
Used Dev Size : 57609024 (54.94 GiB 58.99 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Mon Sep 2 17:02:27 2013
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
UUID : 5c92f0d9:9cf5be95:03611c5e:a540b92f
Events : 0.24172972
Number Major Minor RaidDevice State
0 8 18 0 active sync /dev/sdb2
1 8 2 1 active sync /dev/sda2
Данные устройства Md, как замечено ядром:
garrett@stargate:~$ cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sda2[1] sdb2[0]
57609024 blocks [2/2] [UU]
unused devices: <none>
1 ответ
Это вызвано нечетной конфигурацией, а также изменением загрузочных скриптов.
Во-первых, зеркальное устройство / dev / md0 не имеет таблицы разделов. Он рассматривается как необработанное блочное устройство с файловой системой прямо на нем. В экстренных случаях это позволяет загружать устройство поддержки (/ dev / sda2 или / dev / sdb2) напрямую. Ранее в этом разделе была кратковременная установка LVM, но это было сочтено ненужным, поэтому устройство было повторно инициализировано как необработанное устройство ext3. Однако это не удаляло все следы LMV. Это приводит к тому, что утилита wait-for-root возвращает «LVM2_member» в качестве типа устройства. Он делал это все время.
Во-вторых, обновления загрузочного скрипта «scripts / local» изменили команду монтирования с:
mount ${roflag} ${ROOTFLAGS} ${ROOT} ${rootmnt} на:
mount ${roflag} ${FSTYPE:+-t ${FSTYPE} }${ROOTFLAGS} ${ROOT} ${rootmnt} Сбой монтирования теперь происходит из-за того, что мы форсируем тип файловой системы в команду монтирования. В этом случае тип 'LVM2_member' не работает вообще - вместо этого нам нужен ext3. Старая версия работала, потому что mount легко мог определить, что это файловая система ext3.
Краткосрочный обходной путь для этого заключается в передаче rootfstype = ext3 в строке загрузки ядра. Это игнорирует неправильно определяемый тип файловой системы и указывает ext3 для монтирования.