LINUX.ORG.RU
ФорумAdmin

Помогите добавить UEFI boot на старом VPS от Scaleway

 , , , ,


0

2

Добрый день. Имеется инстанс VC1S от Scaleway, созданный на базе их образа x86_64-ubuntu-xenial, и использующий bootscript для старта системы. Один раз настроенный, VPS этот служил верой и правдой много лет, и я туда даже не заглядывал. Однако, недавно приходит от хостера письмо счастья, где радостно сообщается, что для моего удобства они прекращают поддержку bootscript, и во избежание получения незагружаемого кирпича надо поменять режим загрузки с bootscript на local boot. К письму прилагается инструкция: https://www.scaleway.com/en/docs/compute/instances/troubleshooting/bootscript-eol/
Из инструкции становится ясно, что режим local boot (по-видимому появившийся намного позже чем мой инстанс) требует от используемого образа ОС наличия поддержки UEFI boot. При этом у меня на диске нет никаких признаков загрузочного раздела:

root@cp:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            993M     0  993M   0% /dev
tmpfs           200M   36M  164M  18% /run
/dev/vda         46G   39G  5.4G  88% /
tmpfs           998M     0  998M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           998M     0  998M   0% /sys/fs/cgroup

root@cp:~# fdisk -l
Disk /dev/vda: 46.6 GiB, 50000000000 bytes, 97656250 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

root@cp:~# lsblk
NAME MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda  253:0    0 46.6G  0 disk /

root@cp:~# file -s /dev/vda
/dev/vda: Linux rev 1.0 ext4 filesystem data, UUID=be3af23a-455e-4a92-a7b9-e60c40716e12 (needs journal recovery) (extents) (large files) (huge files)

Равно как не наблюдается и ядра:

root@cp:~# apt list --installed | grep linux-image

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

root@cp:/# ls -a /boot
.  ..

Итого получается, что этот их bootscript выполняет загрузку по сети, при этом ядро физически отсутствует на диске виртуалки.

Подскажите пожалуйста, могу я как-то без потери данных и работоспобности привести систему к состоянию, когда она будет запускаться в локальном режиме с помощью UEFI загрузчика? Сам я догадываюсь, что нужно как минимум создать EFI раздел, установить ядро, grub и подправить соответствующие конфиги, но чёткого понимания последовательности действий у меня нет.
На VPS живёт впн и вебсервер с кучкой сайтов, которые не то чтобы критичные, но свалить их в оффлайн надолго будет неприятно. Я же в линуксе не особо силён, настраивал этот VPS в своё время сам при помощи гугла и такой-то матери, но убить его сейчас экспериментируя с разделами как-то не хочется. Поэтому, если можно, то советы и инструкции лучше давать максимально подробные :)

Сначала нужно сделать бекап.

В инструкции хостера не разобрались или не смотрели?

Для уточнения информации выполните uname -a и ls /.

P.S. Как вариант напишите в раздел Job. «Да» это будет стоить денег, но Вы найдёте специалиста, а не просто анонимуса с ЛОРа.

master_0K
()
Последнее исправление: master_0K (всего исправлений: 1)

Подумать, надо оно тебе так изгаляться, или лучше спокойно заново настроить другой VPS, мигрировать на него, а этот отправить на покой. Если все же надо, то:

  1. Сделать бэкап данных традиционным способом, на полностью запасной случай.
  2. Загрузиться в recovery mode (будет даунтайм) и снять полный бэкап vda при помощи dd.
  3. Положить его на три разных устройства, чтобы наверняка не запороть.
  4. Приготовить виртуалку с поддержкой загрузки через UEFI
  5. Экспериментировать хоть до упаду с виртуалкой или guestfish или чем удобно. «Нужно как минимум создать EFI раздел, установить ядро, grub и подправить соответствующие конфиги» звучит почти правильно, единственное что, у тебя ФС на голом диске и нет таблицы разделов вообще, поэтому её надо создать, создать разделы, а твой /dev/vda накатить на раздело (/dev/?da2).
  6. Записать инструкцию, проверить, что она работает.
  7. Загрузиться в recovery, вытянуть ещё раз свежие данные.
  8. Либо залить готовый поправленный образ диска обратно, либо повторить все шаги прямо в recovery, тут какую инструкцию составишь.
t184256 ★★★★★
()
Ответ на: комментарий от master_0K

Инструкцию хостера детально изучил конечно-же. Все их рекомендации сводятся к созданию нового инстанса на базе образа ОС, поддерживающего local boot, и переноса туда данных тем или иным способом (инструментами Scaleway или вручную). Старый инстанс (давно убранный из прайса) предлагается удалить, а на новом по сути настраивать всё с нуля. При этом цена подходящего конфига будет примерно в три раза выше, чем я плачу сейчас. Подозреваю, что именно ради этого данное «улучшение» и задумывалось.
Что касается бекапа, то это само собой, данный пункт плана как раз единственный, в котором я уверен наверняка :)

root@cp:~# uname -a
Linux cp.mydomain 4.14.33-mainline-rev1 #1 SMP Sun Apr 8 12:34:15 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

root@cp:~# ls /
backup  boot  etc   lib    lost+found  mnt  proc  run   srv  tmp  var
bin     dev   home  lib64  media       opt  root  sbin  sys  usr
uberfox
() автор топика
Ответ на: комментарий от t184256

Подумать, надо оно тебе так изгаляться, или лучше спокойно заново настроить другой VPS, мигрировать на него, а этот отправить на покой.

Миграция на другой VPS это мой план «б», а пока пытаюсь оценить масштаб и сложность задачи. Вообще, хотелось бы оставить этот по причине, обозначенной уже выше - цена подходящего VPS в новой тарифной модели Scaleway будет сильно выше. Рассматриваю переход на OVH для сохранения уровня затрат, но если можно спасти старый VC1S от Scaleway, то такой вариант предпочтительней.
P.S. Времени на решение вопроса у меня до 15 мая.

uberfox
() автор топика
Ответ на: комментарий от t184256

Если я правильно понял пункты плана, то говоря максимально упрощенно, предлагается вытащить образ диска VPS из облака к себе на компьютер и далее мучать его под виртуалкой пока всё не заработает как надо. Далее по отработанной схеме выполнить нужные действия непосредственно на VPS, либо залить исправленный образ диска назад в облако. Так или в чем-то ошибаюсь?
Еще хотелось бы по п.5 более подробно, если можно. Самое интересное, таблицу разделов и сами разделы получится создать без потери данных, непосредственно преобразовав часть голого диска в раздел? Или для этого надо взять новый чистый диск такого-же размера, создать там таблицу и сами разделы, и только потом накатить /dev/vda на уже существующий раздел?

uberfox
() автор топика
Ответ на: комментарий от uberfox

Ну вот ядро хотя бы формально определили. Возможно есть в архиве убунту есть «близкий» образ. «Такого именно, точно нет» © Он может потребоваться.

offtop

При этом цена подходящего конфига будет примерно в три раза выше, чем я плачу сейчас. Подозреваю, что именно ради этого данное «улучшение» и задумывалось.

Эта «технология» довольно древняя по современным меркам. Уже и сложно вспомнить, где её еще не применяли.

master_0K
()
Ответ на: комментарий от master_0K

Ну вот ядро хотя бы формально определили.

У Scaleway на старых инстансах ядро задается этим самым бутскриптом, поддержку которого они прекращают. В админке хостера ядро выбиралось из довольно большого списка, и за время жизни VPS я его несколько раз менял по их рекомендации. Последний раз, кажется, после паники с Meltdown & Spectre уязвимостями.
Кстати, возможно это поможет. У меня есть там еще один более свежий инстанс STARDUST1-S c поддержкой UEFI boot. Он всю жизнь проработал на бутскрипте с ядром mainline 4.4.182 rev1. Вчера, после переключения в режим загрузки local boot, он благополучно завёлся и работает с локальным ядром 4.15.0-197-generic. Изменилось, правда, название сетевого интерфейса и пришлось подправить некоторые конфиги, но в остальном переход прошел безболезненно. Но там изначально в образе уже были (хотя и не использовались) EFI раздел, grub и ядро в /boot.

uberfox
() автор топика
Ответ на: комментарий от t184256

Итак, потренировавшись на кошках на ВМ, я составил примерный план действий. В качестве образца я использовал структуру разделов другого своего инстанса, поддерживающего UEFI boot:

sudo fdisk -l
Disk /dev/vda: 9.3 GiB, 10000000000 bytes, 19531250 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: -

Device      Start      End  Sectors  Size Type
/dev/vda1  227328 19531216 19303889  9.2G Linux filesystem
/dev/vda14   2048    10239     8192    4M BIOS boot
/dev/vda15  10240   227327   217088  106M EFI System

Дано: копия диска VPS (/dev/sdb) где занято примерно 39гб из 46гб, и чистый диск такого-же размера (/dev/sdc)
Задача: получить аналогичную (см.выше) структуру разделов с сохранением данных VPS

sudo fdisk -l /dev/sdb
Disk /dev/sdb: 46.58 GiB, 50000000000 bytes, 97656250 sectors
Disk model: VBOX HARDDISK   
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

  1. Немного уменьшаем размер файловой системы на голом диске VPS
sudo e2fsck -f /dev/sdb
sudo resize2fs /dev/sdb 45G
  1. На чистом диске создаем таблицу разделов gpt, а затем разделы bios, EFI и linux
sudo fdisk /dev/sdc
g w

sudo fdisk /dev/sdc
n 14 enter(2048) +4194K t 14 4 w

sudo fdisk /dev/sdc
n 15 enter(10240) +106M t 15 1 w

sudo fdisk /dev/sdc
n 1 enter(227328) enter(97656216) w
  1. Раздел EFI форматируем в fat32
sudo mkfs.vfat -F 32 /dev/sdc15
  1. Копируем первые 45гб файловой системы диска VPS в linux раздел чистого диска
sudo dd if=/dev/sdb of=/dev/sdc1 bs=4M count=11520
  1. Увеличиваем размер файловой системы на весь linux раздел скопированного диска
sudo e2fsck -f /dev/sdc1
sudo resize2fs /dev/sdc1

В результате получаем /dev/sdс с требуемой структурой разделов, где /dev/sdc1 является копией голого диска VPS:

sudo fdisk -l /dev/sdc
Disk /dev/sdc: 46.58 GiB, 50000000000 bytes, 97656250 sectors
Disk model: VBOX HARDDISK   
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: -

Device      Start      End  Sectors  Size Type
/dev/sdc1  227328 97656216 97428889 46.5G Linux filesystem
/dev/sdc14   2048    10239     8192    4M BIOS boot
/dev/sdc15  10240   227327   217088  106M EFI System

Собственно вопрос. Я ничего не упустил? Допускаю, что способ решения не самый оптимальный, но главное чтобы данные с голого диска перенеслись в раздел без потерь.

uberfox
() автор топика
Ответ на: комментарий от t184256

Насколько я понимаю, загрузиться с этого виртуалка не сможет т.к. в образе отсутствуют загрузчик и ядро. Ядро наверное можно было установить до снятия образа, а вот загрузчику для установки всё равно нужен EFI раздел.
У меня по этому поводу появилась следующая идея. Если VPS в режиме загрузки bootscript грузится с голого диска, то теоретически он должен точно так же загрузиться и с его клона с добавленной таблицей разделов. В таком случае можно будет установить ядро и загрузчик непосредственно на VPS. Жизнеспособная идея?
P.S. UUID файловой системы на голом диске и в разделе совпадают, но файл /etc/fstab в образе пустой.

uberfox
() автор топика
Ответ на: комментарий от t184256

чрутнись в неё, поставь ядро и загрузчик.

Спасибо, не знал что так можно.

Дано: диск /dev/sdс с данными VPS и правильной структурой разделов из поста выше
Задача: добавить ядро и загрузчик, подправить конфиги, убедиться что виртуалка загружается с полученного образа

  1. Монтируем нужные файловые системы и меняем корневой каталог
sudo mount /dev/sdc1 /mnt
sudo mkdir /mnt/boot/efi
sudo mount /dev/sdc15 /mnt/boot/efi
sudo mount -o bind /sys /mnt/sys
sudo mount -o bind /proc /mnt/proc
sudo mount -o bind /dev /mnt/dev
sudo chroot /mnt
  1. Устанавливаем ядро
apt install linux-image-generic
  1. Исправляем название сетевого интерфейса
# в файле /etc/network/interfaces строки с eth0 заменяем на:
auto ens2
iface ens2 inet dhcp
  1. Добавляем созданные разделы
# узнаём UUID для /dev/sdc1 и /dev/sdc15
blkid
# в файл /etc/fstab добавляем строки
UUID=[uuid sdc1]    /          ext4    defaults        0 1
UUID=[uuid sdc15]   /boot/efi  vfat    umask=0077      0 1
  1. Устанавливаем UEFI загрузчик. Виртуалка при этом должна быть с поддержкой EFI, иначе будет ошибка или (как в моем случае) установится legacy загрузчик
apt install grub-efi efibootmgr
grub-install /dev/sdc
  1. Исправляем конфиг grub. Если этого не сделать, то при запуске полученного образа под ВМ можно долго (как я) смотреть на черный экран, и не понимать что происходит
# в файле /etc/default/grub меняем строку
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
# на
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0"
  1. Обновляем конфиг grub и выходим из chroot
update-grub
exit
  1. Размонтируем систему и запускаем полученный образ под ВМ
sudo umount --recursive /mnt

По итогу данных манипуляций у меня установилось ядро 4.4.0-210-generic. Хотя провайдерский bootscript загружает 4.14.33-mainline-rev1. По этому поводу надо переживать и пытаться обновить ядро до 4.14.33?

ls /boot
config-4.4.0-210-generic  initrd.img-4.4.0-210-generic
efi                       System.map-4.4.0-210-generic
grub                      vmlinuz-4.4.0-210-generic

Виртуалка с полученного образа грузится, появляется приглашение вида:

Ubuntu 16.04.6 LTS mydomain.su tty1
user login:

После успешной авторизации появляется сообщение о последнем логине в систему, и дальше ничего не происходит. На экране мигает курсор, позволяющий набирать текст, но никак не реагирующий на команды. Учитывая, что это сервер для VPS, то может это и нормально.
Собственно вопрос. Результат можно считать успешным, и переходить с этим планом действий непосредственно к VPS?

uberfox
() автор топика
Ответ на: комментарий от uberfox

Да, вроде того. Я бы не трогал название интерфейса и конфиг grub, а проверил бы, что на ttyS0 можно логиниться. В QEMU это просто, но я не знаю, что ты используешь. Ещё бы заюзал grub fallback boot, чтобы если efibootmgr заартачился, оно все равно потом грузилось.

t184256 ★★★★★
()
Ответ на: комментарий от t184256

Я использую оракловский виртуалбокс. Это критично, проверить именно на ttyS0?

У меня получилось пофиксить вот эту проблему:

После успешной авторизации появляется сообщение о последнем логине в систему, и дальше ничего не происходит. На экране мигает курсор, позволяющий набирать текст, но никак не реагирующий на команды.

Оказалось, что данный эффект вызывает скрипт Scaleway, который на старте должен выводить в терминал характеристики VPS. Он походу просто виснет при попытке получения внешнего айпи в отсутствие соответствующего интерфейса. Если выпилить содержимое директории /etc/update-motd.d, то после авторизации по tty1, как и положено, открывается командная строка bash.

Ещё бы заюзал grub fallback boot, чтобы если efibootmgr заартачился, оно все равно потом грузилось.

Вот тут я как-то не понял. Если я правильно понимаю, механизм fallback позволяет задать в grub резервный вариант загрузки, который будет использоваться в случае неудачной загрузки варианта по умолчанию. Но у меня на VPS всего один диск, на котором установлена одна система. Что я могу прописать в fallback в такой ситуации?

uberfox
() автор топика
Ответ на: комментарий от uberfox

Это критично, проверить именно на ttyS0?

Ну, других у тебя не будет. Но, в отличие от сети, тут ты и не ломал ничего, авось заработает.

Если я правильно понимаю, механизм fallback позволяет задать в grub резервный вариант загрузки, который будет использоваться в случае неудачной загрузки варианта по умолчанию

Нет, по крайней мере я хотел сказать не про это а про прописывание граба по дефолтному EFI-пути. Если efibootmgr закапризничает и не даст тебе поправить ни одну EFI-переменную и создать запись в списке загрузки, то не надо будет с этим разбираться и результат все равно загрузится. Но это не самое важное, даже если это случится, а по дефолтному пути не пропишешь, можно граб и через EFI шелл загрузить первый раз, а там и починить.

t184256 ★★★★★
()
Последнее исправление: t184256 (всего исправлений: 1)
Ответ на: комментарий от t184256

Итак, докладываю, операция прошла успешно. Инстанс VC1S обучен грузиться в UEFI и благополучно переведен в local boot mode. Всем откликнувшимся спасибо за советы.

На случай, если кто-то из гугла забредет сюда с аналогичной проблемой, тезисно опишу окончание истории.
Поскольку на дешевых впс resize2fs и dd выполняются неприлично долго, для минимизации продолжительности даунтайма я использовал два временных block storage по 50GB и свободный STARDUST1-S инстанс, к которому их подключил. На первом диске поднял бекап голой файловой системы, а на втором сформировал нужную структуру со всеми разделами, ядром и загрузчиком - всё согласно приведенным выше двум инструкциям. Потом переключил полученный диск с UEFI boot на VC1S и проверил, что впс с него грузится. Далее, загрузившись с rescue image, скопировал содержимое block storage на local storage с помощью dd if=/dev/sdb of=/dev/vda bs=4M и переключил VC1S на local boot с этого диска. Временные block storage удалил.

Пара моментов, которые следует отметить:

  • Как и предупреждал t184256, при первом старте на впс (в отличие от виртуалки) загрузчик не запустился, открылся uefi shell, из которого пришлось вручную запустить grub:
FS0:
cd EFI
cd ubuntu
grubx64.efi

После загрузки системы, для решения этой проблемы копию файла /boot/efi/EFI/ubuntu/grubx64.efi я переименовал и поместил по пути /boot/efi/EFI/BOOT/bootx64.efi.

  • ttyS0 заработал сразу, а вот сеть только после правки конфига с eth0 на ens2 (всё-таки правильно я нагуглил в старом буржуйском мануале, что сетевой интерфейс этого инстанса при смене ядра изменится на ens2).
  • Возможно в конфигах и правилах iptables также понадобится исправить название сетевого интерфейса, и на этом всё.
uberfox
() автор топика
Ответ на: комментарий от uberfox

После загрузки системы, для решения этой проблемы копию файла /boot/efi/EFI/ubuntu/grubx64.efi я переименовал и поместил по пути /boot/efi/EFI/BOOT/bootx64.efi.

Надо бы как-то убедить саму систему устанавливать grub по этому пути, а то ты апдейты будешь ставить, а грузиться через старую копию.

В остальном хорошо, рад за тебя и твой успех.

t184256 ★★★★★
()
Ответ на: комментарий от t184256

Озаботился вопросом и понял, что загрузочная запись у меня не создавалась скорее всего из-за того, что grub был установлен под чрутом. Переустановил его на живой системе, и всё завелось:

grub-install /dev/vda
update-grub
efibootmgr -v
BootOrder: 0007,0000,0001,0002,0003,0004,0005,0006
...
Boot0007* ubuntu        HD(15,GPT,6efb523e-ed62-3348-b774-63457962d00e,0x4000,0x36000)/File(\EFI\ubuntu\grubx64.efi)
uberfox
() автор топика
9 августа 2023 г.
Ответ на: комментарий от uberfox

как оно в итоге там? С ценами и вообще. Может с тех пор есть более простой способ?

Вообще можно ли неограниченно играться с снапшотами и восстановлением с них?

praseodim ★★★★★
()
Последнее исправление: praseodim (всего исправлений: 1)
12 октября 2023 г.