Посещая наш сайт, вы соглашаетесь с нашей политикой конфиденциальности в отношении файлов cookie, статистики отслеживания и т. д.

Главная » Вопросы и ответы » Системное администрирование и сети

RHEL leapp обновление не удается при перезагрузке

На чтение 11 мин Опубликовано
Содержание
  1. Вопрос или проблема
  2. Ответ или решение
  3. Проблема
  4. Логи
  5. Возможные причины
  6. Решение проблемы
  7. Заключение

Вопрос или проблема

Я пытаюсь обновить несколько физических серверов с RHEL 7.9 до RHEL 8.6 в оффлайн-режиме. Пока процесс прошел успешно на одном сервере. На сервере, с которым у меня возникла проблема, все работает нормально, но после перезагрузки сервер заходит в режим аварии. Перезагрузка из аварийного режима позволяет мне вернуться к текущей операционной системе сервера (RHEL 7.9).
Запуск:
leapp preupgrade --no-rhsm --enablerepo local1 --enablerepo local2
проходит без ошибок.
После этого я запускаю:
leapp upgrade --no-rhsm --enablerepo local1 --enablerepo local2
и он завершается без проблем. Я осуществляю перезагрузку, и после выбора “Upgrade RHEL 8 initramfs” попытка выполнить обновление завершается неудачей.
Вот последняя часть leapp-upgrade.log

05 сен 04:15:52 localhost systemd[1]: Достигнута цель Системное обновление.
05 сен 04:15:52 localhost systemd[1]: Запуск системного обновления...
05 сен 04:15:52 localhost upgrade[1543]: запуск хука обновления
05 сен 04:15:52 localhost upgrade[1543]: /bin/upgrade: строка 19: /sysroot/var/tmp/system-upgrade.state: Нет такого файла или каталога
05 сен 04:15:52 localhost upgrade[1546]:   ПРЕДУПРЕЖДЕНИЕ: locking_type (4) устарел, используется --sysinit --readonly.
05 сен 04:15:52 localhost upgrade[1546]:   Разрешение активации с --readonly --sysinit.
05 сен 04:15:52 localhost upgrade[1546]:   ПРЕДУПРЕЖДЕНИЕ: Не удалось найти устройство с uuid qGbnBb-LLqH-seg7-NEX3-NPTD-veJk-KLA3SK.
05 сен 04:15:52 localhost upgrade[1546]:   ПРЕДУПРЕЖДЕНИЕ: VG rhel отсутствует PV qGbnBb-LLqH-seg7-NEX3-NPTD-veJk-KLA3SK (последнее записано в /dev/sdi1).
05 сен 04:15:52 localhost upgrade[1546]:   Отказано в активации частичного LV rhel/root. Используйте '--activationmode partial', чтобы переопределить.
05 сен 04:15:52 localhost upgrade[1546]:   Отказано в активации частичного LV rhel/data. Используйте '--activationmode partial', чтобы переопределить.
05 сен 04:15:52 localhost upgrade[1546]:   0 логических томов в группе томов "rhel" теперь активны
05 сен 04:15:52 localhost upgrade[1546]:   Разрешение активации с --readonly --sysinit.
05 сен 04:15:52 localhost upgrade[1546]:   2 логических тома в группе томов "vg01" теперь активны
05 сен 04:15:52 localhost upgrade[1567]: Создание контейнера sysroot в /sysroot.
05 сен 04:15:52 localhost upgrade[1567]: Нажмите ^] трижды в течение 1 секунды, чтобы завершить контейнер.
05 сен 04:15:52 localhost kernel: EXT4-fs (md0): монтирование файловой системы ext2 с использованием подсистемы ext4
05 сен 04:15:52 localhost kernel: EXT4-fs (md0): смонтирована файловая система без журнала. Опции: (null)
05 сен 04:15:52 localhost kernel: XFS (dm-1): Монтирование файловой системы V5
05 сен 04:15:52 localhost kernel: XFS (dm-1): Завершение чистого монтирования
05 сен 04:15:52 localhost upgrade[1570]: mount: специальное устройство /dev/mapper/rhel-data не существует
05 сен 04:15:52 localhost kernel: scsi 11:0:0:0: Прямой доступ     CiscoVD  Гипервизор            PQ: 0 ANSI: 6
05 сен 04:15:52 localhost kernel: sd 11:0:0:0: Присоединен scsi generic sg8 тип 0
05 сен 04:15:52 localhost kernel: sd 11:0:0:0: [sdi] 124727295 512-байтовых логических блоков: (63.9 ГБ/59.5 ГиБ)
05 сен 04:15:52 localhost kernel: sd 11:0:0:0: [sdi] Защита от записи отключена
05 сен 04:15:52 localhost kernel: sd 11:0:0:0: [sdi] Режим Sense: 17 00 00 00
05 сен 04:15:52 localhost kernel: sd 11:0:0:0: [sdi] Кэш записи: отключен, кэш чтения: включен, не поддерживает DPO или FUA
05 сен 04:15:52 localhost kernel:  sdi: sdi1
05 сен 04:15:52 localhost kernel: sd 11:0:0:0: [sdi] Присоединен съемный диск SCSI
05 сен 04:15:59 localhost upgrade[1585]: ==> Обработка фазы `InitRamStart`
05 сен 04:15:59 localhost upgrade[1585]: ====> * remove_upgrade_boot_entry
05 сен 04:15:59 localhost upgrade[1585]:         Удалить загрузочную запись для Leapp предоставленного initramfs.
05 сен 04:15:59 localhost upgrade[2048]: Процесс Process-192:
05 сен 04:15:59 localhost upgrade[2048]: Обратный вызов (последний вызов был последним):
05 сен 04:15:59 localhost upgrade[2048]:   Файл "/usr/lib64/python2.7/multiprocessing/process.py", строка 258, в _bootstrap
05 сен 04:15:59 localhost upgrade[2048]:     self.run()
05 сен 04:15:59 localhost upgrade[2048]:   Файл "/usr/lib64/python2.7/multiprocessing/process.py", строка 114, в run
05 сен 04:15:59 localhost upgrade[2048]:     self._target(*self._args, **self._kwargs)
05 сен 04:15:59 localhost upgrade[2048]:   Файл "/usr/lib/python2.7/site-packages/leapp/repository/actor_definition.py", строка 72, в _do_run
05 сен 04:15:59 localhost upgrade[2048]:     actor_instance.run(*args, **kwargs)
05 сен 04:15:59 localhost upgrade[2048]:   Файл "/usr/lib/python2.7/site-packages/leapp/actors/__init__.py", строка 290, в run
05 сен 04:15:59 localhost upgrade[2048]:     self.process(*args)
05 сен 04:15:59 localhost upgrade[2048]:   Файл "/usr/share/leapp-repository/repositories/system_upgrade/common/actors/removeupgradebootentry/actor.py", строка 20, в process
05 сен 04:15:59 localhost upgrade[2048]:     remove_boot_entry()
05 сен 04:15:59 localhost upgrade[2048]:   Файл "/usr/share/leapp-repository/repositories/system_upgrade/common/actors/removeupgradebootentry/libraries/removeupgradebootentry.py", строка 41, в remove_boot_entry
05 сен 04:15:59 localhost upgrade[2048]:     '/bin/mount', '-a'
05 сен 04:15:59 localhost upgrade[2048]:   Файл "/usr/lib/python2.7/site-packages/leapp/libraries/stdlib/__init__.py", строка 188, в run
05 сен 04:15:59 localhost upgrade[2048]:     result=result
05 сен 04:15:59 localhost upgrade[2048]: CalledProcessError: Команда ['/bin/mount', '-a'] завершилась с кодом выхода 32.
05 сен 04:15:59 localhost upgrade[1585]: ==========================================================================================================
05 сен 04:15:59 localhost upgrade[1585]: Актер remove_upgrade_boot_entry неожиданно завершился с кодом выхода: 1 - Пожалуйста, проверьте вышеуказанные детали
05 сен 04:15:59 localhost upgrade[1585]: ==========================================================================================================
05 сен 04:15:59 localhost upgrade[1585]: Отладочный вывод записан в /var/log/leapp/leapp-upgrade.log
05 сен 04:15:59 localhost upgrade[1585]: ============================================================
05 сен 04:15:59 localhost upgrade[1585]:                            ОТЧЕТ
05 сен 04:15:59 localhost upgrade[1585]: ============================================================
05 сен 04:15:59 localhost upgrade[1585]: Отчет был сгенерирован по адресу /var/log/leapp/leapp-report.json
05 сен 04:15:59 localhost upgrade[1585]: Отчет был сгенерирован по адресу /var/log/leapp/leapp-report.txt
05 сен 04:15:59 localhost upgrade[1585]: ============================================================
05 сен 04:15:59 localhost upgrade[1585]:                        КОНЕЦ ОТЧЕТА
05 сен 04:15:59 localhost upgrade[1585]: ============================================================
05 сен 04:15:59 localhost upgrade[1585]: Файл ответа был сгенерирован по адресу /var/log/leapp/answerfile
05 сен 04:15:59 localhost kernel: XFS (dm-1): Размонтирование файловой системы
05 сен 04:15:59 localhost upgrade[1567]: Контейнер sysroot завершился с кодом ошибки 1.

Все физические диски сообщают об исправной работе, все группы томов сообщают об исправной работе, а все логические тома сообщают об исправной работе после перехода на нормальную загрузку.
Даже отсутствующий PV qGbnBb-….. смонтирован после нормальной загрузки. Можете ли вы помочь мне решить указанную выше проблему, поскольку она очень критична для моего клиента?
Если вам нужны какие-либо дополнительные журналы или вывод любой команды, я буду рад предоставить их.

[Изменение]
Результат pvs -o +uuid

  /dev/md1   vg01 lvm2 a--  <438.52g <348.52g o2821Q-5Re1-UiCZ-V2LJ-f7Qg-hwpX-CqD1ib
  /dev/sdc1  rhel lvm2 a--  <447.13g       0  Iq1PHS-zOk5-2uCw-Ga9A-uo4F-DjkQ-WqpU5S
  /dev/sdd1  rhel lvm2 a--  <447.13g       0  5co7Pi-YiaO-wPyH-Fd3N-rDyC-UPjc-1FJNYx
  /dev/sde1  rhel lvm2 a--  <447.13g       0  46oNJ3-sf3n-5Lqc-6ZZv-dN3U-guzA-5s7ZRa
  /dev/sdf1  rhel lvm2 a--  <447.13g       0  U2iWT4-c7lP-7Zp8-ZNTJ-EtF3-mcyQ-nDgU6A
  /dev/sdg1  rhel lvm2 a--  <447.13g       0  R9vj56-XNvi-xEUu-DXLs-fPU3-MnIC-gtbZXY
  /dev/sdh1  rhel lvm2 a--  <447.13g       0  WCcfjx-Ffzp-OwLz-BHGX-HIpo-qtFC-HuMPVp
  /dev/sdi1  rhel lvm2 a--   <59.47g       0  qGbnBb-LLqH-seg7-NEX3-NPTD-veJk-KLA3SK

[Изменение 2]
Результаты vgs -o +devices

  VG   #PV #LV #SN Attr   VSize    VFree    Devices
  rhel   7   2   0 wz--n-   <2.68t       0  /dev/sdi1(2424)
  rhel   7   2   0 wz--n-   <2.68t       0  /dev/sdc1(0)
  rhel   7   2   0 wz--n-   <2.68t       0  /dev/sdd1(0)
  rhel   7   2   0 wz--n-   <2.68t       0  /dev/sde1(0)
  rhel   7   2   0 wz--n-   <2.68t       0  /dev/sdf1(0)
  rhel   7   2   0 wz--n-   <2.68t       0  /dev/sdg1(0)
  rhel   7   2   0 wz--n-   <2.68t       0  /dev/sdh1(0)
  rhel   7   2   0 wz--n-   <2.68t       0  /dev/sdi1(0)
  vg01   1   2   0 wz--n- <438.52g <348.52g /dev/md1(0)
  vg01   1   2   0 wz--n- <438.52g <348.52g /dev/md1(12800)

[Изменение 3]
Результаты lvs --all -o +devices

  LV   VG   Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert Devices
  data rhel -wi-ao---- <2.63t                                                     /dev/sdc1(0)
  data rhel -wi-ao---- <2.63t                                                     /dev/sdd1(0)
  data rhel -wi-ao---- <2.63t                                                     /dev/sde1(0)
  data rhel -wi-ao---- <2.63t                                                     /dev/sdf1(0)
  data rhel -wi-ao---- <2.63t                                                     /dev/sdg1(0)
  data rhel -wi-ao---- <2.63t                                                     /dev/sdh1(0)
  data rhel -wi-ao---- <2.63t                                                     /dev/sdi1(0)
  root rhel -wi-a----- 50.00g                                                     /dev/sdi1(2424)
  root vg01 -wi-ao---- 50.00g                                                     /dev/md1(0)
  var  vg01 -wi-ao---- 40.00g                                                     /dev/md1(12800)

[Изменение 4]
Результаты команды lvscan

  ACTIVE            '/dev/rhel/root' [50.00 GiB] наследовать
  ACTIVE            '/dev/rhel/data' [<2.63 TiB] наследовать
  ACTIVE            '/dev/vg01/root' [50.00 GiB] наследовать
  ACTIVE            '/dev/vg01/var' [40.00 GiB] наследовать

Некоторые точки монтирования отсутствуют, проверьте, почему.

05 сен 04:15:52 localhost upgrade[1570]: mount: специальное устройство /dev/mapper/rhel-data не существует

И

05 сен 04:15:59 localhost upgrade[2048]: CalledProcessError: Команда ['/bin/mount', '-a'] завершилась с кодом выхода 32.

После долгих поисков в Google и тестирования я обнаружил следующее о том, что произошел баг:
https://bugzilla.redhat.com/show_bug.cgi?id=1927688
Обходное решение помогло мне справиться с проблемой, но привело к новой проблеме – неисправной конфигурации grub 2. Вот что я сделал, чтобы решить свою проблему.
После выполнения команды обновления leapp upgrade --no-rhsm --enablerepo local1 --enablerepo local2 я перезагрузил сервер, как было запрошено для завершения процесса обновления.
A) При перезагрузке и входе в меню grub2 я набрал e, когда был выбран RHEL 8 Upgrade Initramfs.
B) В конце CMDLINUX я добавил опцию rd.break=upgrade. Сохраните и продолжите.
C) После входа в режим однопользовательской загрузки я выполняю команды, описанные в вышеуказанной ссылке.

sed -i 's/locking_type = 4/locking_type = 1/' /etc/lvm/lvm.conf
lvm vgchange -ay --config ' global {locking_type=1} '
lvm vgck --updatemetadata rhel
sed -i 's/locking_type = 1/locking_type = 4/' /etc/lvm/lvm.conf
exit

D) Система загружается как ожидалось с initramfs обновления, и обновление завершилось успешно.
Однако при перезагрузке я попал в режим восстановления grub. Чтобы решить эту проблему, я использовал носитель RHEL 8.6, который у меня был, чтобы выполнить оффлайн-обновление и загрузиться с этого носителя.
E) После загрузки с вышеперечисленного носителя я выбрал восстановление установленной ОС и следовал подсказкам, чтобы получить доступ к нужной оболочке. Делая это, он автоматически выбрал, где был установлен мой grub (в моем случае /dev/md) и оттуда я восстановил мой grub с помощью:

grub2-mkconfig -o /boot/grub2/grub.cfg
grub2-install /dev/md
perезагрузка

И вот он, мой новый вариант загрузки RHEL 8.6. Я вошел в систему, как обычно.

Ответ или решение

Успешный переход на новую версию операционной системы Red Hat Enterprise Linux (RHEL) является критически важным для многих организаций, стремящихся к улучшению производительности и безопасности своих серверов. Однако иногда процесс обновления может вызывать проблемы, которые требуют внимания и вмешательства. В данной статье мы обсудим, как решить проблему неудачного обновления RHEL 7.9 до RHEL 8.6, которая приводит к возникновению режима аварийной загрузки.

Проблема

При попытке обновления системы с помощью утилиты Leapp, сервер иногда застревает в режиме аварийной загрузки после перезагрузки. В вашем случае, несмотря на то что команда leapp upgrade успешно завершилась, при перезагрузке система не загружается, а переходит в аварийный режим.

Логи

В приведенной вами части логов leapp-upgrade.log можно увидеть следующие ключевые моменты:

  • Ошибка при обращении к файлам: /sysroot/var/tmp/system-upgrade.state: Нет такого файла или директории.
  • Проблемы с активными томами: Предупреждения о неактивных логических томах в группе томов rhel.
  • Ошибки при попытке монтирования: mount: special device /dev/mapper/rhel-data does not exist, что указывает на проблемы с логическими томами.

Возможные причины

  1. Неактивные логические тома: Это может произойти, если некоторые устройства, указанные в конфигурации LVM, недоступны или неправильно распознаны во время процесса обновления.
  2. Некорректные параметры конфигурации LVM: Ошибка конфигурации может привести к отсутствию необходимых томов.
  3. Конфликтная информация о дисках: Если физические диски были неправильно настроены или произошел сбой в их работе, это могло стать причиной проблем.

Решение проблемы

Исходя из вашего опыта и приведенной информации о источниках проблемы, вам удалось обнаружить известную ошибку, связанную с поведением LVM во время обновления. Ниже приведены шаги, которые были предприняты для решения проблемы и их объяснение:

  1. Изменение параметров конфигурации LVM:

    • Вы добавили параметр rd.break=upgrade в конфигурацию загрузки, что позволило вам войти в режим однопользовательской загрузки.
    • Изменение конфигурации LVM с использованием команды sed для временного изменения locking_type на значение 1 позволило активацию томов.

  2. Запуск необходимых команд:

    • Команда lvm vgchange -ay --config ' global {locking_type=1} ' активировала все тома во время режима обновления.
    • После этого вы выполнили lvm vgck --updatemetadata rhel для обновления метаданных группы томов.

  3. Восстановление конфигурации:

    • После успешной активации и обновления метаданных вы восстановили параметр locking_type на его первоначальное значение 4 и перезагрузили систему.

  4. Ремонт загрузчика GRUB:

    • Возникновение ошибок при загрузке системы, которые приводят в режим восстановления GRUB, может быть решено с помощью загрузки с установочного носителя и использования утилит grub2-mkconfig и grub2-install для восстановления конфигурации загрузчика.

Заключение

Однако принятые меры позволили успешно завершить процесс обновления до RHEL 8.6. Все описанные действия не только исправили обнаруженные ошибки, но и обеспечили корректную работу сервера. Тем не менее, важно помнить о возможных рисках при проведении обновлений и всегда иметь резервные копии критически важных данных.

Если у вас есть дополнительные вопросы или необходима помощь по другим аспектам процесса обновления, не стесняйтесь обращаться.

rhel7 rhel8
Оцените материал
Добавить комментарий

Капча загружается...

© 2024 IZ6.RU
*В материалах сайта упоминаются социальные сети Фейсбук / Инстаграм, принадлежащие Meta Platforms Inc., деятельность которой запрещена на территории РФ в части реализации данных социальных сетей на основании осуществления ею экстремистской деятельности