перенос centos 7 из virtualbox на hyper-v

Я так понимаю проблема с grub и он не может диск по uuid

Проблемы с Grub у тебя нет grub - это загрузчик и раз он у тебя показывает меню и далее передаёт управление ядру в первом пункте или втором, то значит с ним всё в порядке.

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

Возможно, чего-то ещё.

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

Ну либо выставить в настройках виртуальной машины такой же контроллер жёстких дисков, что был и на старой виртуальной машине, по крайней мере, что бы он обслуживался тем же модулем (драйвером).

Т.е. при запуске с первого пункта меню ядро попросту не видит жёсткий диск.

Сравни вывод команды

lspci -l

В новой виртуальной машине и строй.

В принципе ты можешь использовать загрузку и со второго пункта меню постоянно, но некоторые пишут, что загруженный при старте системы initramfs впоследствии не выгружается, поэтому initramfs меньшего размера лучшее решение.

Но я сам не проверял. По крайней мере об этом писали те, кто использует Suse Linux и вроде бы новую Ubuntu.

при вводе данной команды lspci -l пишет что неверная команда и выводит справку, там наверное ключ не l нужен а другой?

-k

дракатом надо обновить инитрамфс, в гугле есть поподробнее если искать именно по переносу по виртуалкам:

https://access.redhat.com/solutions/3465011

ах да, это-ж платный редхет, просто хотел немного ненависти к платным чинилкам вызвать :-)

я вот по этой логике перетаскивал ол8 недавно с vmware на vb: https://portal.nutanix.com/page/documents/kbs/details?targetId=kA032000000TTizCAG

Всем огромное спасибо за помощь, что не бросили в беде и откликнулись на помощь. Решение проблемы оказалось гораздо проще, я просто зашел в систему в режиме восстановления и сделал обновление системы командой yum update после обновления у меня создался новый пункт загрузки с новым ядром(обновленным), после чего система начала загружаться по умолчанию именно с ним.

Решение проблемы оказалось гораздо проще …

Ну ты же понимаешь, что тебе просто повезло, что было новое ядро. При установке пакета с которым вызываются сценарии создания initramfs. По сути тебе просто нужно было вызвать те же команды, что вызываются при установке пакета с ядром, что бы пересоздать заново Initramfs.

Разбираться как это сделать и как это всё работает - дело твоё.

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

Если тебя это устраивает - можешь поставить галочку, что решил проблему и забыть.

Пока не столкнёшься опять с проблемой.

В таких случаях проще загрузится с ISO Centos и переустановить ядро с загрузчиком. Для этого загружаемся в rescue-режиме, поднимаем сеть и выполняем chroot в смонтированную корневую директорию. Затем:

 yum install grub2 kernel 

я не с порю, с линуксом я на вы, я работаю веб программистом и мне нужно было просто протестировать конфигурацию нашего облачного сервера который сконфигурировали на сервере сами админы облачной системы, так как они обещали большую производительность под сайт на битрикс, и я хотел эту конфигурацию потестировать на сервере кампании. А образ они выдают только в формате qcow2, вот у меня и была задача переконвертировать образ под hyper-v и развернуть его.

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

можно подумать кто-то сразу взял и подумал «ааа точно, моё основное ядро не стартует при полностью рабочем рекавери не из-за ядра/конфига загрузчика, а из-за того что какой-то там дракат не может сам себе помочь и зачем-то ломает весь процесс запуска там, где он должен его наоборот облегчать» :-)

В таких случаях проще загрузится с ISO Centos

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

«моё основное ядро не стартует»

Оно-то как раз стартует, оно не может найти свой корень, потому что, а вот почему читай моё первое сообщение в теме: перенос centos 7 из virtualbox на hyper-v (комментарий)

а из-за того что какой-то там дракат не может сам себе помочь

dracut - это набор скриптов для генерации initramfs. Если в Initramfs нет модуля с драйвером для доступа к диску, то как он себе поможет?

и зачем-то ломает весь процесс запуска там, где он должен его наоборот облегчать» :-)

Он его и облегчает.

dracut - это набор скриптов для генерации initramfs. Если в Initramfs нет модуля с драйвером для доступа к диску, то как он себе поможет?

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

Он его и облегчает.

забавно же что эта проблема выстреливает с дистрами с дракатом и не выстреливает, например, с дебианом :-)

Ты прочитал мое первое сообщение в теме? Целиком?

Прочти пожалуйста.

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

Т.к. все что загружено в память через initramfs так и остается в озу.

Т.к. все что загружено в память через initramfs так и остается в озу.

а всё что не запустилось из-за кривой ирфс вообще в озу не попадает - Э-экономия :-)
я не знаю как работает (кто и когда её пересобирает и что туда кладёт) ирфс на том-же дебиане, но когда я переношу с ним образ туда-сюда ничего не ломается, при это в нём нет «драката, призванного помочь с ирфс», а в системе где дракат есть - проблемы у всех, кто меняет одну виртуалку с lsi logic на другую виртуалку с lsi logic, и это вот все в дорого-богато-ентерпрайзной рхел/оракле пичальбида

п.с. я понимаю логику «сломал руками - чини руками» и в целом поддерживаю её, но нафига тогда вообще дракат нужен?

я не знаю как работает (кто и когда её пересобирает и что туда кладёт) ирфс на том-же дебиане, но когда я переношу с ним образ туда-сюда ничего не ломается

В каком режиме ты ставишь Debian? Видимо не в экспертном.

В экспертном режиме установки на этапе выбора ядра задаётся вопрос: «В initramfs помещать только модули необходимые для работы данной системы или все?».

В обычном режиме, видимо этого вопроса нет и ты даже не знаешь о такой возможности.

Так что в Debian абсолютно такое же поведение может быть.

В каком режиме ты ставишь Debian? Видимо не в экспертном.

ну так я и рхел/ол ставлю не в экспертном - яж не эксперт, к чему мне навязывать это принудительно? :-)

повторюсь - моя основная претензия к дракату в том, что он зачем-то есть, но почему-то не может сам разрузлить простую задачку: система не грузится с микро-ирфс, рядом лежит рабочая ирфс … но при этих вводных дракат допускает стоп всего сервака и ожидание пока хозяин нагуглит штаслучилось, вместо того что-бы подпихнуть резервно-рабочую и заспамить логи о том что вообще там пиндец-что-творится

вообщем только в каком-то параллельном энтерпрайзе от рхел, 20 метров экономии озу стоят отвала на ровном месте. надеюсь ойбиэм им там мозги вправит!111

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

А пока пойми что здесь написано и как работает.

Рядом лежит ядро и initramfs, с которого можно загрузиться и пересоздать основной Initramfs.

Хочешь только смеяться - дело твоё.

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

пфф, как-бы такими темпами редхэт не начал зарабатывать столько, сколько я :-)

А пока пойми что здесь написано и как работает.

я понимаю что это не работает, и понимаю что ты очень гордишься тем, что понимаешь почему не работает то, что должно работать всегда (по моему пониманию)

Хочешь только смеяться - дело твоё.

я скорее глумлюсь, расслабься :-)

понимаю что ты очень гордишься тем, что понимаешь почему не работает то

Я не то что бы горжусь этим, Я не понимаю такой позиции как у тебя. Есть подходы и они работают десятилетия. Любой администратор Linux, да и в целом пользователь должен разбираться как и что делается в используемом им дистрибутиве. И механизм решения данной проблемы есть.

По поводу экономии 20 мб, не соглашусь. Здесь видел тему, где человек арендует виртуалку с 256 Мб ОЗУ на Ubuntu и обновив её до последней версии не смог на ней загрузиться, потому что в Ubuntu в initramfs было до кучи модулей. Которые по сути были не нужны его системе, но загружались и памяти для запуска основной системы уже не хватило,

Конечно это другой вопрос, что зачем он использует виртуалки с 256 Мб рам. Или зачем он обновляет систему.

Но в целом Правильно настроенный Linux способен комфортно работать на 256 Мб и менее и выполнять задачи.

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

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

Ты поступай как хочешь.