У меня есть небольшой сервер (HP ProLiant MicroServer Gen8) под управлением Ubuntu 18.04 64 бит с последнее универсальное ядро HWE (5.4.0.74.83~18.04.67); у него есть два диска SATA, разделенные на разделы GPT, но загружающиеся в устаревшем режиме BIOS. Оба диска разделены следующим образом:
- раздел 1 (1 МБ): «теневой» загрузочный раздел для кода GRUB;
- раздел 2 (несколько ТБ): BtrFS, содержащий
@ подтом для / и @дом подтом для /дом; /ботинок действительно находится под /@/ботинок
- раздел 3 (4 ГБ): подкачка
Разделы BtrFS на двух дисках связаны вместе в зеркальной конфигурации BtrFS.
Через несколько дней отключилось электричество, и NAS так и не восстановился. При загрузке я только что получил ужасное «спасение личинки», в котором говорилось, что он не может найти целевой раздел (я думаю, указанный с помощью GUID тома BtrFS). Пытаюсь сделать лс (hd0,gpt2) (или действительно, любой другой раздел) сказал мне «неизвестная файловая система» (хотя insmod btrfs вроде работает корректно).
Думая, что с GRUB что-то не так, я загрузился с установочным ключом сервера Ubuntu 18.04 и попытался восстановить GRUB следующим образом:
смонтировать /dev/sda2 /mnt (/dev/sda2 раздел BtrFS); Я вижу, что все данные все еще там;mount --bind /dev /mnt/@/dev; то же самое для /dev/pts, /прок, /sys, /бег (иначе DNS, управляемый resolvconf как в действующей системе, так и в «сломанной» системе, не будет работать)chroot/mnt/@- внутри chroot я сделал
смонтировать /dev/sda2 / -o subvol=@ в противном случае личиночный зонд/установка grub запутался бы; вне chroot, переделал привязку, так как это было затенено перемонтированием;
гора -а
Затем (с нескольких попыток) я попробовал несколько вещей:
- переустановил GRUB на
/dev/sda (grub-установить /dev/sda); пытался с --перепроверить и без, пробовал grub-mkdevicemap (удаление вручную ключевого USB-устройства из сгенерированного карта устройства файл);
- воссоздал конфигурацию GRUB (
обновление-личность);
- обновил ядро, на самом деле не думая, что это большая проблема с версией ядра, но чтобы убедиться, что (1) я пытаюсь загрузить что-то, что точно не повреждено, и (2) чтобы иметь только что созданный initrd
- проверил, все ли файлы ядра/initrd доступны для чтения (например, с помощью
sha1sum /загрузка/*), так как сообщения GRUB об этом были пугающими — см. позже;
- понизил GRUB (последняя версия 2.02, доступная в репозиториях) до нескольких исправлений ранее, поскольку я подозревал, что потеря мощности не имеет к этому особого отношения, но вместо этого это было какое-то обновление, которое сломало его.
- бег
btrfs проверить /dev/sda2 и btrfs проверить /dev/sdb2; оба запускались без ошибок, единственная проблема (отмеченная для обоих) заключалась в кеше свободного места одного блока (позже я смонтировал /dev/sda2/ с очистить кэш вариант на всякий случай)
Результаты всей этой ерунды были далеко не обнадеживающими: когда все сделано правильно, эта ерунда всегда снова приводит меня к спасение личинки, но на этот раз с более интересным поворотом:
- Это может читал немного том BtrFS, но, так сказать, еле-еле; делает
лс (hd0,gpt2)/ показывает подобъемы, но оба лс (hd0,gpt2)/@ и ls (hd0,gpt2)/@дома показывать пустые каталоги (поэтому он не может найти (hd0,gpt2)/@/загрузка/ а затем все необходимое для перехода в нормальный режим);
- самое интересное, что есть и другие подтома, а именно три снимка, сделанные сценарием обновления версии Ubuntu; те вместо этого подтомы может быть прочитан GRUB; мало того: если я приспособлю
префикс, корень и Ко. чтобы указать внутри подтомов снапшота, я могу умудриться перейти в "обычный" режим GRUB и, снова подкорректировав пути в пунктах меню, загрузить старое ядро, которое было в снапшоте (единственная проблема в том, что оно не может найти модули, поскольку я загружаю более старую версию ядра, которая больше не установлена в текущей корневой файловой системе, но, учитывая, что они на самом деле не используются, загружается очень хорошо).
Однажды (когда я, вероятно, что-то напортачил в вышеупомянутом устанавливать пляски в chroot) мне удалось перезагрузиться и получить сразу нормальный режим, но GRUB всегда находил что-то плохое для всех записей в меню загрузки: в частности, для каждой записи он не мог загрузить ни ядро, ни initrd, давая пугающее сообщение об ошибке «inode not found» (или, в другом случае, «не удалось найти дескриптор блока»; у обоих нет совпадений в Google, кроме самих исходников GRUB, что всегда является плохим признаком); обратите внимание, что, как я сказал выше, во время живого USB-сеанса все они были читаемы.
Дополнительные мысли:
- на материнской плате сервера есть странная проблема с контроллером SATA - кажется, что перечисление дисков занимает много времени, что привело к этой ошибке при обновлении до 18.04. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1752961; единственное (печальное) исправление состояло в том, чтобы добавить
спать 5 в initrd перед сканирование btrfs; это также приводит к тому, что второй диск /dev/sdc в некоторый живых USB запускается, но это не имело значения (когда это произошло, я также изменил имя файла в /dev, что, похоже, не имело особого отношения к результату);
- Я думал о плохом ОЗУ, хотя это казалось маловероятным, потому что (1) после загрузки система работает нормально и (2) это ОЗУ ECC, и я ожидал, по крайней мере, какое-то сообщение об ошибке в случае; во всяком случае, я запустил MemTest, и уже несколько часов он работает без ошибок;
iLO сообщает об ошибке самопроверки при загрузке, которая, однако, кажется не связанной. позже ошибка была устранена обновлением прошивки до последней версии и очисткой NVRAM; как и ожидалось, это не имело никакого значения, но, по крайней мере, экран POST стал немного чище.
Моя текущая догадка примерно такая: ядро HWE использует версию BtrFS с некоторыми функциями, несовместимыми с «обычной» версией Ubuntu 18.04 GRUB, поэтому все файлы/каталоги, которые записываются «сейчас», потенциально проблематичны для чтения GRUB; действительно, я видел, что между GRUB 2.02 и текущей версией (2.06) была некоторая работа над материалом BtrFS, хотя для сжатия zstd это не включено на моих дисках. Может быть, попытка более свежего GRUB может решить проблему? Но есть ли упакованная сборка GRUB 2.06, которая работает для 18.04?
Короче говоря: есть идеи, в чем может быть проблема и как ее исправить?
