Как правильно клонировать систему c выпиленным lilo на другой HDD (или в виртуалку)?

Question

[Алекс]

Имеется древняя непубличная linux система (на базе RedHat/CentOS, ядро 2.4.21), которая грузится с HDD (в реальности флэшка пром.исполнения с SATA интерфейсом) посредством LILO. Скрипты инициализации в процессе загрузки перемещают необходимое для работы системы в ОЗУ и делают pivot_root/chroot. Система практически ничего не пишет кроме текущего лога (живет до перезагрузки) и необходимого для ее работы, поэтому для того, чтобы ни мучить флэшку понапрасну, всё и работает в ОЗУ. Запись на HDD (флэшку) требуется только в случае изменения каких-то настроек системы. В самой системе всё типичное для linux дистрибутивов, но не требующееся для работы, выпилено, например бинарник lilo и даже lilo.conf удалены. По сути на загрузочном HDD кроме загрузчика имеются лишь 1) ядро (Micro2), 2) образ initial ram disk (initrd.gz), 3) образ корневой FS (ramroot.img), в которую делается chroot. Вот все, что есть:

spoiler

[root@rescue /]# ls -Rla /mnt
/mnt:
total 57068
drwxr-xr-x 3 root root 4096 Nov 9 12:26 .
drwxr-xr-x 18 1000 users 360 Nov 9 12:25 ..
drwxr-xr-x 3 1000 users 4096 Mar 29 2023 boot
-rw-r--r-- 1 1000 users 58368000 Nov 9 10:56 ramroot.img

/mnt/boot:
total 1972
drwxr-xr-x 3 1000 users 4096 Mar 29 2023 .
drwxr-xr-x 3 root root 4096 Nov 9 12:26 ..
-rw-r--r-- 1 root root 1015869 Mar 29 2023 Micro2
drwxr-xr-x 2 1000 users 4096 Mar 29 2023 boot
-rw-r--r-- 1 1000 users 975486 Nov 1 10:59 initrd.gz

/mnt/boot/boot:
total 76
drwxr-xr-x 2 1000 users 4096 Mar 29 2023 .
drwxr-xr-x 3 1000 users 4096 Mar 29 2023 ..
-rw------- 1 root root 38912 Mar 29 2023 System.map
-rw-r--r-- 1 1000 users 512 Jul 14 2011 boot.b
-rw-r--r-- 1 1000 users 23108 Aug 4 2006 message

Требуется клонировать все это на новый HDD, но также интересен вариант переноса системы в вируталку. Использование Acronis, Clonezilla, в том числе, в режиме посекторного копирования отрабатывает без проблем, но при попытке загрузиться с нового HDD грузится ядра, и далее, вероятно, на этапе монтирования initial ram disk стабильно получаю kernel panic. Также пробовал использовать dd с аналогичным неудачным результатом. Вот скриншот этого при попытке запустить всё на виртуалке, на реальном железе ситуация аналогична:

spoiler

Предположение, что проблема связана с использованием LILO, который оперирует цилиндрами/головками/секторами HDD, и требуется обновить System.map для него, тем более размер/геометрия нового HDD отличаются от старого. Как это сделать правильно, т.к. все, что касается LILO из исходной системы выпилено.? Я пробовал загрузиться с PLD RescueCD - один из старых LiveCD, где еще имеется LILO и даже нужной 23-й версии. Далее смонтировал содержимое старого HDD, с него распаковывал и смонтировал, как loop устройство файл initrd.gz (или мне нужен ramroot.img ?), затем сделал bind папок /proc, /sys и /sbin (её решил добавить, т.к. в исходной системе от бинарников LILO ничего нет) с PLD RescueCD. Затем сделал chroot и пытался выполнить команду /sbin/lilo (пусть, пока даже не создавая lilo.conf). Получил сообщение об отсутствии одного или двух .so файлов, которые, тоже выпилены из исходной системы. Мне нужно еще и папку /lib с этим(и) фалом bind-ить тоже? Я вообще в правильном направлении двигаюсь? И надо ли bind-ить папку /dev, которая в исходной системе уже имеется и не пустая? Может, это клонирование как-то проще делается, а я перемудрил?
Дополнительно: на реальной системе в BIOS для SATA контроллера установлен режим IDE Compatable. В этом случае, насколько я понимаю, важно не менять SATA порты подключения HDD, завязанные на maijor, minor номера устройств. Разумеется, я обращаю на это внимание и при попытке переноса на виртуалку (virtual device node) и на реальном железе при попытке грузиться с нового клонированного HDD.

Comments

[pfg21]

м-м-м, переделать на груб ??
груб оперирует тем же ядром и инитрамфс.

[Алекс]

pfg21, Может быть, но...
1. Задача все же стоит именно клонировать, как есть
2. В этом случае мы просто заменяем задачу правильной установки/настройки lilo на аналогичную для grub
3. Здесь нет инитрамфс, используется его предшественник init ramdisk

[shurshur]

Либо надо после переноса загрузиться с другого носителя и из chroot вызвать lilo, либо таки уже мигрировать на нормальный загрузчик. Если даже не grub, то можно хоть DOS загрузить и из него взвести систему с помощью loadlin (ему нужны будут ядро, initrd и правильные параметры), или через pxelinux...

initrd трогать не нужно! и вызывать lilo из другой системы тоже. Нужно lilo именно правильной формы от нужной системы. Вообще lilo сильно завязан на конкретный диск с его разметкой, там по сути статические адреса блоков прям в boot record пишутся. Поэтому-то в старых линуксах после пересборки ядра надо было переставлять lilo. Крутость grub как раз и была в своё время в том, что в нём есть stage2, который уже умеет работать с файловыми системами и находить файлы по именам (хотя там могут быть тоже проблемы, если файловая система побилась, даже если это легко восстанавливается по журналу при обычной загрузке).

Неужели другой загрузчик никак не поставить? В принципе, lilo и grub даже совместно можно исхитриться завести.

[Алекс]

shurshur,
да, я именно и пытаюсь "загрузиться с другого носителя и из chroot вызвать lilo", но пока не завершил процесс (см.подробности в 1м посте). Во что именно мне следует делать chroot? Ведь, как таковой корневой ФС в исходной системе нет. Есть ее образ в виде ramroot.img. Мне следует монтировать его, как loop и chroot-иться в него? А недостающие для манипуляций с lilo бинарники и so-файлы взять/подмонтировать из папок /bin и /lib в системе LiveCD ?

Ну и установка grub - возможный следующий шаг. Хотя, повторю, в этом случае одна задача (установка/восстановление lilo) заменяется другой (установка grub). Возможно, с grub это только будет проще, чем с lilo.

[pfg21]

Алекс, ramroot.img где/в чем лежит ?? или у тебя просто три отдельных файла ??
по идее всех лайв-систем все бинари, библиотеки и все прочее необходимое для жизни системы лежит внутри образа рутового раздела, твой рамрут.имг.
к нему идет файл ядра и инитрамфс для загрузки (и то при "прямых руках" инитрамс исключается).

[shurshur]

Алекс, то есть всё же система в рамдиске? Тогда придётся её пересобирать, да. Но система, в которой устанавливали lilo, в таком случае может отличаться.

Например, можно было сделать /boot, в него положить ядро и ramdisk, настроить и установить lilo, а потом систему, из которой всё это делалось, полностью снести.

Но в целом если там не перемудрили, то можно взять ядро и ramdisk и загрузить их любым другим загрузчиком, в том числе grub.

[Алекс]

pfg21,

ramroot.img где/в чем лежит ?? или у тебя просто три отдельных файла ??

в корне раздела загрузочного исходного HDD, как и написал в своем 1м посте. Ok, т.е. мне необходимо делать chroot в подмонтированное куда-нибудь содержимое ramroot.img. Повторю вторую часть вопроса: недостающие для манипуляций с lilo бинарники и so-файлы взять/подмонтировать из папок /bin и /lib системы LiveCD, т.к. в ramroot.img этого ничего нет ?

[Алекс]

shurshur,

то есть всё же система в рамдиске?

да, я это писал в самом 1м посте.

Тогда придётся её пересобирать

- так не из чего же, она - непубличная и без исходников.

можно было сделать /boot, в него положить ядро и ramdisk, настроить и установить lilo, а потом систему, из которой всё это делалось, полностью снести

- можно поподробнее по шагам?
1. на новом HDD создаю папку /boot и кладу в нее файлы ядра и init ramdisk. В корень раздела кладу ramroot.img/ Так? Это у меня это по сути уже сделано при посекторном клонировании HDD со старого на новый.
2.

настроить и установить lilo

- как именно?
Загружаюсь с подходящего LiveCD на железе с установленным новым HDD из п.1, верно?
3. Создаю файл lilo.conf и просто выполняю команду lilo? А какие ей скормить параметры, чтобы все установилось именно на новый HDD, а не на то устройство, с которого загружал LiveCD в п.2? Никакие chroot при этом не требуется делать?
4.....
В общем, по возможности, разжуйте подробнее для чайника, пожалуйста.

[CityCat4]

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

[Алекс]

CityCat4, в этом и сложности поддержки legacy, да еще и непубличного

[pfg21]

Алекс, chroot нужен только в загруженной системе. при запуске системы достаточно правильно смонтировать корневой раздел.
покажика свой lilo.config

> Повторю вторую часть вопроса: недостающие для манипуляций с lilo бинарники и so-файлы взять/подмонтировать из папок /bin и /lib системы LiveCD, т.к. в ramroot.img этого ничего нет ?

не всегда, ибо исполняемые файлы завязаны на окружение, версию ядра, версии системных билиотек и все прочее. мешать их в винегрет надо с осторожностью.
подключаемые /bin /lib точно выживут на системе ??
покажи плиз листинг корня рамрут.имг

[Дмитрий]

Попробуйте запустить систему в виртуализованном окружении, например в Virtualbox, пробросив флешку в виртуалку как физическое устройство. Как это сделать, описано например здесь - https://remontcompa.ru/virtualnye-mashiny/page,1,2...
Если получится, то далее с большой вероятностью получится средствами VirtualBox сделать образ диска, с которого можно будет успешно грузиться.

[Алекс]

pfg21,

покажика свой lilo.conf

- а нет его вовсе, как писал в самом 1м посте. Буду сам сочинять.
вот распакованный ramroot.img

spoiler

[root@rescue ramroot]# ls -lA /mnt/ramroot/
total 50
drwxr-xr-x 2 root root 1024 Sep 13 2013 bin
drwxr-xr-x 4 root root 35840 Jul 14 20:15 dev
drwxr-xr-x 17 root root 2048 Jul 14 20:15 etc
-rw-r--r-- 1 root root 0 Apr 9 2007 halt
drwxr-xr-x 2 root root 1024 Apr 9 2007 initrd
drwxr-xr-x 7 root root 2048 Sep 28 2018 lib
drwxr-xr-x 5 root root 1024 Oct 26 2010 mnt
dr-xr-xr-x 2 root root 1024 Apr 9 2007 proc
drwxr-x--- 3 root root 1024 Oct 26 2010 root
drwxr-xr-x 2 root root 1024 Nov 19 2013 sbin
drwxr-xr-x 5 root root 1024 Sep 27 2018 sysconf
drwxr-xr-t 2 root root 1024 Oct 26 2010 tmp
drwxr-xr-x 9 root root 1024 Apr 14 2010 usr
drwxr-xr-x 11 root root 1024 Sep 18 2007 var

[pfg21]

Алекс, ну вот, а ты боялся :) полностью вся система - папки /bin /lib уже внутри.
теперь осталось этот образ подсунуть в качестве корня :)
спробуй в виртуалке развернуть этот образ на отдельный раздел и передать его ядру через root=

либо изучить скрипты в инитрамс, коим образом там формируют корень системы.

[shurshur]

Алекс, делаем так: на HDD в отдельный раздел ставим любой другой линукс (можно какой-нить легковесный) с grub, затем в этот grub кладём указанные ядро и рамдиск. Если там не намудрили и не делали вообще явную защиту от таких ковыряний, то эта штука должна загрузиться и даже как-то найти свой HDD-раздел.

Как вариант, систему можно попробовать загрузить внешним загрузчиком с флешки или через PXE.

Как происходит загрузка Linux "на пальцах"?

1. В память грузится ядро и initrd.

2. В нужную область памяти помещаются параметры, включая адрес, где лежит initrd.

3. Вызывается стартовый код ядра, который уже делает всё остальное.

При этом неважно, где лежат ядро и initrd до загрузки. Поэтому необязательно использовать lilo, на самом деле.

[Алекс]

pfg21, вероятно, я чего-то не понимаю:

развернуть этот образ на отдельный раздел

- просто скопировать все содержимое?

передать его ядру через root=

- как?? В процессе загрузки вызывать промпт lilo и вписывать это там?
Или как-то все вписать в lilo.conf и сформировать правильные stage1/stage2 и map-карту для lilo? Я это и пытаюсь сделать, но куча проблем, т.к. все выпилено.

изучить скрипты в инитрамс

- он более-менее понятен, вот его содержимое:

spoiler

#!/bin/bash

haltsystem() {
echo $1
echo "System halted!"
while [ 1 ]; do
[ 1 -eq 2 ] && break;
done
}

PATH=/bin:/sbin:/usr/bin:/usr/sbin
export PATH
mount /proc

mount -n /dev/flash1
rc=$?
[ $rc -ne 0 ] && haltsystem "Can't mount flash1 (check media and try again)!"

echo
echo "Extracting flash image"
dd if=/mnt/flash1/ramroot.img of=/dev/ram1 bs=1024 >/dev/null 2>&1
rc=$?
[ $rc -ne 0 ] && haltsystem "Error reading flash drive or media is bad!"

umount -n /mnt/flash1

mount -t ext2 -o rw /dev/ram1 /mnt/ramdisk 2>/dev/null 1>&2
mount -t ext2 /dev/flash2 /mnt/flash2 2>/dev/null 1>&2
cp -af /mnt/flash2/etc/inittab /mnt/ramdisk/etc/inittab 2>/dev/null 1>&2
cp -af /mnt/flash2/etc/rc.d/rc.card /mnt/ramdisk/etc/rc.d/rc.card 2>/dev/null 1>&2
umount /mnt/flash2 2>/dev/null 1>&2
umount /mnt/ramdisk 2>/dev/null 1>&2

mount -n -o ro /dev/ram1
rc=$?
[ $rc -ne 0 ] && haltsystem "Can't mount RAM-disk to perform pivot_root!"
cd /mnt/ramdisk

umount -n /proc
pivot_root . initrd
exec chroot . sbin/init dev/console 2>&1

Пояснения: /dev/flash1 и /dev/flash2 - это алиасы/линки для двух разделов на загрузочном HDD (/dev/hdc1, /dev/hdc2). В 1м хранится все необходимое для загрузки системы (см. 1й пост), на 2м - конфигурационные файлы для (пере)настройки системы, которые в процессе загрузки считываются в нужные места корневой ФС в ОЗУ.

[Алекс]

shurshur,

на HDD в отдельный раздел ставим любой другой линукс (можно какой-нить легковесный) с grub, затем в этот grub кладём указанные ядро и рамдиск. Если там не намудрили и не делали вообще явную защиту от таких ковыряний, то эта штука должна загрузиться и даже как-то найти свой HDD-раздел.

Отличная мысль! но, увы, не сработало. В итоге я получил тот же kernel panic с тем же сообщением "попытка убить init". Из всего этого, кмк, напрашиваются выводы:
1. Т.к. я вижу начало процесса загрузки и вывод в консоль кучу типичных сообщений, вероятно, собственно загрузка ядра и initial ramdisk проходят успешно.
2. После этого, кмк, управление д.б. передано скрипту/процессу init в initial ramdisk. Я распаковал и смонтировал его содержимое, в нем нет ничего похожего на init. Единственный скрипт - это linuxrc, лежащий в корне. Полагаю, он именно и начинает работать в качестве init. Содержимое его я здесь тоже привел в одном из ответов на комменты выше. В /etc ничего нет кроме fstab. Я пробовал полностью закомментировать все в скрипте linuxrc, но итог - тот же, kernel panic. Вероятно, проблема возникает еще раньше, до передачи управления этому скрипту. Когда именно?
3. Вероятно, все мои прежние предположения о связи проблемы с lilo и разной геометрией дисков ошибочны. Дело в чем-то другом.

[shurshur]

Алекс, я бы посмотрел в запущенной успешно системе /proc/cmdline. Возможно, там надо правильные параметры ядру передать, в частности, правильный init.

Но в ramdisk в качестве init используется как раз /linuxrc

Надо запускаться с параметром init=/bin/bash и проверять наличие /dev/flash1, /dev/flash2.

[Алекс]

shurshur, это все уже пройдено и проверено. Явно до выполнения linuxrc не доходит. Я пробовал в нем оставить только строку запуска sh (см.выше), также пробовал передавать ядру параметр init=/bin/sh, система крашится раньше. Вероятнее всего, что-то не так с обращением к HDD. Драйвер для работы с ним, вероятно, нормально грузится, и сообщение об этом, фактически последнее, что выводится на экран.
Из последних экспериментов: сделал клонирование командой dd с исходного HDD на новый на самой исходной системе. Оба диска были подключены в соседние SATA порты. Загружался при этом с USB LiveCD. После замены старого HDD на новый в процессе загрузки получаю тот же результат - kernel panic. Это уже совсем ни в какие ворота не лезет. Из различий нового и старого HDD (они, разумеется, разных размеров, вендоров и пр.) обратил внимание, что в fdisk для исходного размер логического/физического секторов - 512 байт, для нового - 512/4096 байт, но собственно все склонировано абсолютно одинаково вплоть до идентификатора диска. Может ли это различие приводить к наблюдаемому результату? Если да, то можно ли изменить размер физического сектора на новом диске? Вроде можно указать эти размеры при создании таблицы разделов на нем вручную, но как потом корректно клонировать все данные (содержимое самих партиций, mbr и, если есть что-то между mbr и 1й партицией) на новый диск?

[shurshur]

Алекс, нет, размер сектора поменять нельзя. Можно попытаться поискать старый диск с сектором 512.

Можно на самом деле попытаться бутнуться с другим ядром, в который вкомпилить всё необходимое, чтобы от модулей ядра не зависеть.

[Алекс]

shurshur, fdisk (возможно, зависит от его версии, дистрибутива) все же позволяет указать размер сектора при создании таблицы разметки.

Можно попытаться поискать старый диск с сектором 512

я полагал, что размер сектора зависит прежде всего от размера диска, но меня удивило, что тут же в системе стоит 2й hdd (не загрузочный, для данных) размером 1Tb и для него fdisk размер сектора показывает 512 байт! Я пытался клонировать на диск размером 500Mb, для него fdisk показывает размер сектора в 4096 байт. Везде я говорю про размер "физического" сектора в терминах fdsik.

[Алекс]

Дополнено: получил в распоряжении фактически такой же загрузочный носитель, как и в исходной системе (SATA флэш диск) и почти таким же объемом. Почти, означает, что на исходном и для клонирования носителях одинаковая маркировка размера в 4Gb, а по факту мой на несколько Mb больше. Установил свой второй носитель в исходную систему, загрузил ее с внешнего LiveCD Clonezilla, выполнил посекторное клонирование, заменил исходный HDD на клонированный и получил kernel panic при загрузке. Клон не является клоном, увы. Я не понимаю, как такое получается. Система, как уже говорил, вероятно, крашится на этапе обращения к диску через драйвер или на этапе загрузки этого драйвера. Последнее сообщение ядра (см.мой 1й пост в теме) касается назначения адресов портов ввода/вывода и прерываний IDE контроллеру, затем краш. В исходной системе после этого (отделил желтым на скриншоте) выводится инфо об обнаруженных дисках, подключенных к контроллеру, их геометрии, разделах на них. Один диск - обычный HDD для данных и второй - собственно загрузочный.
Прошу помощи сообщества, что может быть не так?

spoiler

[Алекс]

Возникли подозрения, что клонирование не работает из-за защиты лицензионности. Например, встроена проверка на серйиный номер HDD.
Тему предлагается закрыть.

[pfg21]

Алекс, интересно в виртуальнике можно создать устройство с заранее прописанными идентификаторами...
антипиратские организации такое конечно прижмут, но возможно есть сторонние разработки.

[Алекс]

pfg21,

в виртуальнике можно создать устройство с заранее прописанными идентификаторами...

- я не в курсе, как, и нет 100% уверенности, что дело именно в этом