LINUX.ORG.RU

Debian 3.2 перенос рабочей системы на виртуальную машину. Проблема с загрузкой

 , ,


0

1

Есть довольно таки старый компьютер под linux debian. На нем установлен софт для работы печатного оборудования, к софту идет физический usb ключ. Появилась необходимость перенести систему на более новое железо, наиболее простой способ, как мне показалось, перенести на виртуальную машину. Установил VMware Workstation, с помощью Paragon Virtualization Manager сделал образ ssd не которой была установлена система. После запуска образа в vmware система ругалась на GRUB. Поправилось командами

set prefix=(hd0,2)/boot/grub
insmod normal
normal

Дальше при загрузке выдает ошибку fsck died with exit status 8 В логе следующее:

GNU nano 2.2.6 File: checkfs

Log of fsck -C -R -A -a
tue Apr 25 16:05:18 2023

fsck from util-linux 2.28.1
fsck.ext4: Attempt to read block from filesystem resulted in short read while t$|
ould this be a zero-length partition?

fsck died with exit status 8

tue Apr 25 16:05:18 2023

Как поправить не понимаю, может ли быть проблема в том что на исходном компьютере был еще жесткий диск по мимо ssd и теперь система его не видет?

Просто из личного опыта, мимокрокодил.
Скопируй через dd образ диска, закинь его на новый ПК.
Запусти, типа так:
kvm -drive file=/home/$USER/debian_old_image,format=raw -m 4096 --enable-kvm
При показе GRUB выбери recovery mode загрузись в него и отредактируй /etc/fstab убрав точку монтирования несуществующего более диска.

Я как-то так делал, но с боолее новым дебианом правда. VMware видел только на картинках. После манипуляции можно ещё раз попробовать в нём запустить если прям вмваря нужна.

LINUX-ORG-RU ★★★★★
()
Последнее исправление: LINUX-ORG-RU (всего исправлений: 2)

из серии арфы нет возьмите бубен: через виртуалбоксовскую консоль когда-то дампил vdi на физический винт. скорее всего можно и наоборот сделать. может тогда checkfs не заругается.

flant ★★★★
()

с помощью Paragon Virtualization Manager сделал образ ssd

Создайте образ с помощью dd. Например так:

sudo dd if=/dev/sda of=/mnt/debian3.img bs=8M status=progress

Чтобы создать образ диска, загрузитесь с лайфсиди на этой старенькой машине.

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

sudo dd if=/mnt/debian3.img of=/dev/sda bs=8M status=progress

Потом уже грузите виртуальную машину с диска. Ошибок файловой системы быть не должно. Отдельно посмотрите

/etc/fstab
несуществующие точки монтирования удалите.

к софту идет физический usb ключ

Не знаю как в вмваре, но в qemu/kvm usb порт перенапрявляется легко.

старый компьютер под linux debian

Погуглите например «How to create dd image linux drive» или так «How to migrate linux in virtual machine», помочь может также несколько роликов на ютуб.

sfedosenko
()

Дальше при загрузке выдает ошибку fsck died with exit status 8 В логе следующее:

Как ты смог скопировать лог если оно не запускается? И откуда там «GNU nano checkfs»?

firkax ★★★★★
()

похоже что ваш парагон что-то прогнал не так…

short read - это скорее всего superblock не нашёл

загрузитесь с «cd» в режиме rescue (демьян любой может быть с версией больше чем целевая) и скажите mke2fs -n ваш_раздел

потом запустите fsck [-fy] -b любой-другой-superblock-из-списка кроме первого ваш-раздел

о! только сейчас увидел, что у вас fsck.ext4 - вот это как раз может и быть источником проблем - откуда в debian 3.2 вдруг взялась EXT4? и версия какая-то странная - я такой не помню. вуди был 3, сарж - 3.1. а 3.2 - это кто? эч уже 4ой версией был. кстати ext4 в массы пошёл одновременно с эчем, году в 2008 где-то.

раньше его просто не было…

ТС - вы уверены что у вас именно Debian 3.2 да ещё и ext4? вы точно на машине времени не путешествовали?

технически ещё лучше выяснить в чём проблема до действий с mke2fs/fsck, примерно так:

dmesg|egrep -e ‘(Sense|CDB|Read|sector|block)’ и вывод обычно показателен

mumpster ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

можно библии все подложить
главное ещё вуди-саржевые найти ;)
я недавно хотел под одну тему временно старый бук поставить на раздачу пиксы. споткнулось всё дело на моменте, что надо соответствующие старые tftp и т.п. :-)

PS: там был эч кстати. или даже уже лени.

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

да разное бывает.

сейчас очень много людей впервые столкнувшихся с линуксом не как пользователи (судя по Парагону - как раз тот случай). так что может просто не понимать отчего, кто виноват и что делать.

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

и да, не надо грузиться с live-cd чтобы создать образ диска

достаточно в RO / перевести и спокойно можно лить через dd на целевое хранилище

примерно так:

#mount -remount -o remount,ro / #dd if=/dev/ROOT-PARTITION bs=512k |ssh пользователь@целевой-компьютер:/путь

после переноса fsck обязателен, но он и так запустится из-за флага

mumpster ★★★★★
()

Всем спасибо за ответы. Помогло отключение fstab. Софт перенести сложно, он работает только под определенной версией debian, причем разработчики что-то там допиливали в самом линуксе, ключ не дружит с более новыми версиями программы… и т.п., так что перенос на виртуалку самое простое) В рекавери мод система загружалась, так что просто fstab открыл в nano и подправил.

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

Ручной remount-ro (не тот что при ошибках) почти сломан, по крайней мере на новых ядрах. Так что надо заранее грузиться с ro.

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

Ручной remount-ro (не тот что при ошибках) почти сломан

да ладно? ;-)
5.10.0-20-amd64

mount |grep usr

/dev/md1 on /usr type ext2 (ro,relatime)

sudo mount -o remount,rw /usr

mount |grep usr

/dev/md1 on /usr type ext2 (rw,relatime)

sudo mount -o remount,ro /usr

mount |grep usr

/dev/md1 on /usr type ext2 (ro,relatime)

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

Не знаю, может как-то повлияло что он у тебя до этого в ro был. У меня, когда я в разные времена несколько раз пытался это сделать, выдавало то ли device busy то ли что-то похожее, и ни разу успехом это не увенчалось. Возможно, из-за того что какие-то проги там файлы успели открыть в rw режиме, а ключа чтобы у них этот режим отнять - нет (-f не помогает).

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

device busy то ли что-то похоже

о! дык это всегда было! например, в 2002 на 2.2 и 2.4 ядрах.
и совершенно не зависит от свежести ядра у нас был большой опыт с RO рутом, так что я в курсе чокаво ;)

просто какой-то процесс мешает, вот и всё.

у меня часто после обновления такое случается. и я раз методично искал, нашёл причину, прибил и перевёл в RO. и васякот!

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

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

о! дык это всегда было! например, в 2002 на 2.2 и 2.4 ядрах.

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

прибил и перевёл в RO. и васякот!

А надо без прибивания - когда remount-ro делает ядро по своей инициативе (из-за ошибок), ему открытые дескрипторы не мешают. Просто при следующей попытке в них записать процессам ошибка вернётся.

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

я так не думаю. когда ядро RO делает - обычно уязвимые процессы авост делают.

полагаю, что там из-за удалённых файлов проблема (типично для обновлений- всё совпадает). процесс держит открытым fd на уже удалённый файл => нельзя сделать RO без последствий.

так что или рыбку ешь, либо на ёлку лезб. в смысле, или процессы руби эти или терпи и жди .)))

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

ro всегда можно сделать, просто кто-то поленился реализовать. Даже реализовывать почти ничего не надо, уже есть готовый код для аварийного ro. sync + его и норм.

firkax ★★★★★
()