Установка Linux не может найти первый раздел диска во время загрузки
Контакт 1 — V _ШИНА, +5 В. Возьми USB-кабель и ужасно его перекрути, чтобы вставить резистор 1 -Ом в линию с проводником контакт 1 .
Запустите рабочую нагрузку USB и измерьте падение напряжения на резисторе с помощью цифрового мультиметра или аналогичного прибора. V = I * Rи P = I * V, так что с R = 1милливольты вы читаете будет идентично миллиамперам, потребляемым устройством, и мощность будет в пять раз больше. Единичная нагрузка будет составлять около одной десятой ампера.
Если ваше устройство потребляет несколько единиц груза, вы можете рассмотрите возможность использования меньшего токоизмерительного резистора, возможно, десятая доля ома.
Для очень мощного устройства, питание компьютера через монитор Kill -a -Watt может быть эффективным методом измерения. Обратите внимание на мощность, потребляемую сначала при отключенном USB, затем во время выполнения рабочей нагрузки USB, и вычислить разницу.
Воссоздание файла initrd с помощью mkinitrd— правильное решение, только оно должно выполняться из системы, максимально приближенной к той, которая будет использоваться конечной целевой ОС. Это связано с тем, что mkinitrdвыполняет большое количество автоматических -обнаружений ядра и системы, из которой оно запускается , особенно в отношении модулей ядра, которые должны быть доступны для файла initrd. Вы воссоздали файл initrd из своей основной ОС, которая явно сильно отличается от вашей старой машины, поэтому mkinitrdсоздали неполный/несогласованный файл initrd.
Наилучшим подходом в таких ситуациях обычно является загрузка целевой машины с -по -с исходного дистрибутива с установочного CD/DVD/ISO , так как они обычно имеют " спасательный режим», которые пригодятся в этих случаях, чтобы воссоздать оттуда файл initrd. В вашем случае оказывается, что целевая ОС — это openSuSE 11.3, поэтому вы можете взять ее ISO , загрузить ее с любой qemuвиртуальной системой, на которую вы хотите настроить целевую ОС(-hdaили -device ahci. ] или даже SCSI/SAS, если вам так хочется ),выберите опцию «Rescue System», которая доступна в самом первом загрузочном меню -этого ISO, войдите в систему как rootи оттуда запустите:
~# mount /dev/sda1 /mnt
~# cd /mnt
/mnt# mount --rbind /dev dev && mount --make-rslave dev
/mnt# mount -t proc proc proc
/mnt# mount -t sysfs sysfs sys
/mnt# chroot.
<chrooted># mkinitrd
...
<chrooted># exit
/mnt# umount dev/pts dev/shm dev proc sys
/mnt# cd..
/# umount mnt
для воссоздания файла initrd.
После загрузки с настоящим исходным ядром (из openSuSE 11.3 ), работающим в реальной целевой qemuсистеме, простое mkinitrdбез параметров должно работать нормально.
Конечно, после описанной выше операции вы должны poweroffповторно запустить qemuс той же виртуальной системой, но без ISO-образа.
Вполне возможно воссоздать файл initrd из совершенно другой ОС, как вы пытались, но тогда нужно точно знать все требуемые драйверы, чтобы переопределить (неизбежно )неполное/несогласованное автоматическое -обнаружение, выполняемое mkinitrd.
В вашем случае я вижу, что в воссозданном файле initrd отсутствует драйвер sd_mod, который фактически необходим для обеспечения /dev/sd*дисковых устройств. Вероятно, он не был скопирован, потому что ваша хост-система ОС (, на которой вы воссоздали файл initrd ), не имеет этого драйвера в качестве sd_mod.koзагружаемого модуля, а скорее скомпилировала его в сам образ ядра. Это вполне возможно, потому что этот модуль в настоящее время стал стандартным по умолчанию, в то время как 10 лет назад его не было вообще, так как его аналог IDE(ide-disk.ko)был вполне стандартным (, т.е. скомпилирован -в )до некоторые ~15 лет назад, в то время как в настоящее время его часто полностью прекращают.
Таким образом, вы можете просто повторить те же операции, что и в вашей операционной системе, указав также sd_modи ata_piix, и все будет готово. Однако в таких случаях, например, если исходный установочный CD/DVD/ISO недоступен, более безопасной альтернативой является запуск mkinitrd -Aиз среды chroot на хост-ОС, поскольку этот аргумент указывает mkinitrdчтобы просто включить все возможные драйверы.Естественно, это требует гораздо больше дискового пространства вне файловой системы, в которой находится файл initrd, но после загрузки на диск целевой ОС вы, наконец, можете повторно -повторно -создать initrd с помощью простого mkinitrd(, т.е. без аргументов ). ], который перестраивает компактный файл initrd, созданный для новой аппаратной системы.
Мое первое предположение состоит в том, что контроллер хранилища в оригинальной системе отличается от того, который предоставляется qemu, поэтому файл initrd не содержит нужного модуля для запуска виртуального контроллера хранилища.
Контроллер системы хранения по умолчанию для qemu-system-x86_64похоже не AHCI, а классический контроллер Intel PIIX3 IDE. Для этого требуется модуль ядра ata_piix, который не нужен в initrd любой достаточно современной физической системы, использующей AHCI в качестве минимальной базовой линии.
В результате ядро вообще никогда не видит диск, а процесс загрузки никогда не переходит с initrd на настоящую корневую файловую систему.
GRUB прекрасно видит диск, потому что использует подпрограммы BIOS для доступа к диску... а поскольку BIOS предоставляется qemu, в BIOS, очевидно, есть именно те подпрограммы, которые подходят для этой работы.
Если вы можете получить доступ к командной строке виртуальной машины, попробуйте эту команду:
dmesg | grep -e piix -e ahci -e " sd"
Должны отображаться любые сообщения, связанные с обнаружением диска :, если ничего не отображается, то ваш (виртуальный )контроллер хранилища не обнаруживается, что делает обнаружение виртуального диска невозможным.
Чтобы исправить это, вам, возможно, потребуется получить доступ к образу диска в вашей обычной системе.:(Если /dev/loop0уже используется в вашей системе, вместо этого используйте устройство со свободной петлей)
losetup -P /dev/loop0 srv.sda
Затем смонтируйте /dev/loop0p1в подходящее временное место в вашей обычной системе:
mkdir /mnt/opensuse
mount /dev/loop0p1 /mnt/opensuse
Добавьте необходимые виртуальные файловые системы и chroot в файловую систему образа диска, аналогично тому, что вы можете сделать при загрузке физической системы с живого носителя Linux:
mount --rbind /dev /mnt/opensuse/dev
mount --bind /proc /mnt/opensuse/proc
mount --bind /sys /mnt/opensuse/sys
chroot /mnt/opensuse
Теперь вы сможете воссоздать файл initrd/initramfs в образе диска. Вы не указали версию системы OpenSUSE на образе,но классическая команда mkinitrdможет быть инструментом для использования -или может быть на самом деле псевдонимом совместимости для любого более нового инструмента (dracut, возможно? )может использоваться в более новых версиях.
Какой бы инструмент ни использовался для создания файла initrd в этой версии OpenSUSE, этот инструмент, скорее всего, будет иметь возможность принудительно включить определенный модуль ядра в initrd. Прочтите справочную страницу инструмента, чтобы узнать об этой опции, и используйте ее для создания нового initrd с включенным модулем ata_piix. (Сначала отодвиньте исходный файл initrd на всякий случай.)
После того, как вы успешно создали новый initrdфайл в нужном месте в /bootобразе, exitвне среды chroot, umountвсе монтирования, которые вы сделали ранее, и отсоедините петлевое устройство с losetup -d /dev/loop0. Теперь вы можете попробовать снова загрузить образ, надеюсь, успешно.
После комментария UUID, который я сделал.
Предполагая, что у вас есть доступ к диску (disk/image ), вы можете смонтировать его на хост-компьютере в соответствии с инструкциями, которые @telcoM дает выше.Оттуда вы можете запустить blkid, чтобы получить UUID
Затем вы можете обновить /etc/fstabна образе диска. Я предполагаю, что у него есть строка, которая выглядит примерно так
/dev/sda1 / ext4 defaults 1 1
закомментируйте эту строку и замените /dev/sda1на UUID=###, например
UUID=aaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa / ext4 defaults 1 1
Если возможно, сделайте то же самое в строке grub linux
grub> linux (hd0,msdos1)/boot/vmlinuz root=UUID=###