Astra linux vmware kernel panic
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- VMware Technology Network
- :
- Desktop Hypervisor
- :
- VMware Workstation
- :
- VMware Workstation Pro Discussions
- :
- Kernel Panic at boot time, using Oracle Linux 6.7
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
ArturoGutierrez
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I’m trying to use a OEL virtual box, created in a Windows 8.1 Intel Core i7 4702MQ, with Workstation versión 12 to a new machine with Windows 10 on a Intel Core I7 8700, using the same Workstation versión.
This is the boot crash error:
Any idea how to resolve this problem?
bluefirestorm
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
From the looks of it, a part of DTrace is built-in to the kernel. https://oss.oracle.com/projects/DTrace/
It is composed of three portions, an in-kernel core, a userspace utility, and a type storage library used by these.
The kernel portion is built into the UEK kernels and is also available on a public git tree.
So your VM might not have the DTrace tools but it could still be in the kernel. You could try the steps to outlined here to remove the DTrace kernel bits although it is for a different issue.
for package in `rpm -qa | grep dtrace-modules`; do yum remove -y $package; done
On a Crystal Well (Haswell) Macbook Pro with Fusion 8.5.10, the vmware.log shows the following vpmc capabilities even though the virtualised performance counters is not enabled in the Windows 10 VM.
| vmx| I125: Capability Found: vpmc.numGenCtrs = 0x4
| vmx| I125: Capability Found: vpmc.fixedWidth = 0x30
| vmx| I125: Capability Found: vpmc.genWidth = 0x30
| vmx| I125: Capability Found: vpmc.version = 0x3
| vmx| I125: Capability Found: vpmc.microarchitecture.haswell = 0x1
| vmx| I125: Capability Found: vpmc.genctr.0 = 0x1
| vmx| I125: Capability Found: vpmc.numFixedCtrs = 0x3
I would think you would find similar entries in the vmware.log of the OEL VM on the i7-4702MQ host. For now, I am thinking that the DTrace kernel bits, given its functionality/purpose, might be assuming performance counters from the virtual CPU to be present but are not there and therefore the OEL VM is crashing on the boot-up.
The rest seem to be OK (for example, the TSX-NI capabilities are found)
vmx| I125: Capability Found: cpuid.RTM = 0x1
vmx| I125: Capability Found: cpuid.HLE = 0x1
Other things you could do although I don’t think it will make any difference on the Coffee Lake host making the OEL VM successfully power up.
Update Workstation Pro to 12.5.9 (it is a free update), 12.1.0-build-3272444 you use is quite old and does not have the necessary security fixes (including exposing the Spectre microcode to VMs).
Upgrade the OEL VM hardware compatibility from version 11 to 12 (from VM menu — Manage)
Kernel panic в гостевой генте
Самосборное ядро в VMware упорно не хочет грузить систему.
/dev/sda1 — /
/dev/sda2 — /home
/dev/sda3 — swap
Загрузчик — grub. Корневым разделом указан hd(0,0). root=/dev/sda1
В ядро жёстко вкомпилено всё, что только может понадобиться VMware — IDE/ATA, SCSI, SATA, ext2 (все разделы, кроме свопа, на ext2).
И что за unknown-block(8,1)? Откуда (8,1)?
Извини за оффтопик, но — окошко у тебя больно клевое! Не поделишься рецептом, как запилить себе такой же интерфейс?
grep "CONFIG_IDE\|CONFIG_ATA\|CONFIG_EXT" /usr/src/linux/.config
Почему он долбится в какой-то блок 8,1. Что syslinux, что grub. Тупизм какой-то.
Должно быть включено CONFIG_ATA и выключено CONFIG_IDE
У тебя, наверное, и с хоста не загрузится с таким рутом. Попробуй загрузиться с живого диска, узнать uuid раздела и в грубе прописать его.
Device Drivers ---> ATA/ATAPI/MFM/RLL support (DEPRECATED) --->
Device Drivers ---> Serial ATA and Parallel ATA drivers --->
Вы знаете перевод слова DEPRECATED ?
Почему он долбится в какой-то блок 8,1. Что syslinux, что grub. Тупизм какой-то.
Конечно тупизм! Ты ведь даже не догадываешься, что ни syslinux, ни grub, ни какой бы то ни было другой загрузчик в принципе не может иметь никакого отношения к ошибке с твоего скриншота.
Вы знаете перевод слова DEPRECATED ?
Я не знаю, каких лосей навертели разрабы vmware.
Хоть что-то обнадёживает. А что имеет отношение?
Выключил IDE. Всё равно паника:
У тебя, наверное, и с хоста не загрузится с таким рутом
При чём здесь vmware, при конфигурировании ядра через
Напротив указанного параметра ядра написано DEPRECATED — означает устаревший.
Точно не помню, но ещё со времён 2.6.38 это параметр включать нельзя, а использовать CONFIG_ATA (Serial ATA and Parallel ATA drivers) подсистема libata она поддерживает и Parallel ATA (IDE) и Serial ATA (SATA), видимо вы давно ядро не конфигурировали.
grep DEVTMP /usr/src/linux/.config
Вы используете initrd или нет ?
подсистема libata она поддерживает и Parallel ATA (IDE) и Serial ATA (SATA)
Ну если она и древние чипсеты поддерживает, то ладно.
Вы используете initrd или нет ?
cd /usr/src/linux genkernel ramdisk
Какие вы опции включали в
Device Drivers ---> Serial ATA and Parallel ATA drivers --->
kostik87 ★★★★★ ( 20.11.12 10:07:13 MSK )
Последнее исправление: kostik87 20.11.12 10:09:00 MSK (всего исправлений: 1)
Очень не хочется — загрузка долгая с ним.
Я уже всё там повключал. И в SCSI тоже (vmware эмулирует scsi для виртуальных жёстких дисков).
grep CONFIG_ATA_PIIX /usr/src/linux/.config
Ядро как бы намекает, что на sda нет партиций. root=/dev/sdb1
Если включить все модули SCSI/ATA/SATA подряд, они же не могут мешать друг другу?
Ядро как бы намекает, что на sda нет партиций
Это как ещё? fdisk партиции видит, syslinux — тоже. Почему ядро не видит?
Хоть что-то обнадёживает. А что имеет отношение?
Ядро. Задача загрузчика — загрузить ядро в память, передать ему параметры запуска и запустить. И всё. Раз у тебя ядро уже загрузилось, значит загрузчик сделал своё дело правильно. Неспособность ядром смонтировать корневую ФС никак не связана с загрузчиком.
FACEPALM
/dev/sda в самом деле каким-то хреном превратилось в /dev/sdb
Теперь система грузится, в загруженной системе fdisk -l выдаёт вот что:
Собери ядро с initramfs (ЕМНИП, в gentoo для этого используется genkernel) и попробуй запустить. Оно хотя бы вывалится в busybox и ты сможешь посмотреть что именно у тебя происходит с дисковой подсистемой.
И ещё: не нужно собирать «минимальное ядро», «в котором только то, что нужно» и т.п. Это уже давно не имеет смысла за пределами встраиваемых систем. И не даёт ничего кроме проблем.
/dev/sda в самом деле каким-то хреном превратилось в /dev/sdb
У устройств sd? нет стабильной схемы нумерования by design. В общем случае буква может быть любой. Почему именно получилось sdb, хотя диск всего один — фиг знает. Возможно это баг, но совсем не обязательно.
Для точного указания устройств используй UUID’ы или метки файловых систем.
Deleted ( 20.11.12 10:40:06 MSK )
Последнее исправление: Deleted 20.11.12 10:40:42 MSK (всего исправлений: 1)
Почему именно получилось sdb, хотя диск всего один — фиг знает
Ещё интереснее, откуда появился восьмимегабайтовый /dev/sda
Видимо, чудил какой-то модуль. Выкинул из ядра всё лишнее, система нормально грузится с /dev/sda1
Re: FACEPALM
Это тестовый драйвер, для отладки. Не помню, как называется, я его тоже как-то случайно включил где-то в районе ATA devices.
Kernel Panic When Booting in RedHat Linux under VMWare Fusion : Filesystem Not Found
Environment
I am running Red Hat Enterprise Linux Server (2.6.18-194.3.1.el5PAE) under VMWare Fusion Version 3.1.0 (261058) running on a MacBook Pro with OS X v10.5.8 running a 2.8 GHz Intel Core Duo processor with 4GB 1067 MHz DDR3 memory. The virtual machine is allocated 2 processor cores and 2048 MB of memory. The VM hard disk setting points to the file «Red Hat Enterprise Linux 5.vmdk» with «Bus Type» set to «SCSI», «Disk Size» set to 40Gb and «Split into 2Gb Files» option checked. When I use the following /boot/grub/menu.lst file, everything works perfectly except that it boots into the wrong kernel (2.6.18-194.3.1.el5PAE instead of 2.6.34):
# grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00 # initrd /initrd-version.img #boot=/dev/sda default=1 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title Red Hat Enterprise Linux Server (2.6.34) root (hd0,0) kernel /vmlinuz-2.6.34 ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.34.img title Red Hat Enterprise Linux Server (2.6.18-194.3.1.el5PAE) root (hd0,0) kernel /vmlinuz-2.6.18-194.3.1.el5PAE ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.18-194.3.1.el5PAE.img title Red Hat Enterprise Linux Server (2.6.18-194.el5PAE) root (hd0,0) kernel /vmlinuz-2.6.18-194.el5PAE ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.18-194.el5PAE.img
When I use the following file (with the last lines commented out and a couple other small edits), it attempts to boot the correct kernel but the boot fails with the kernel panic described above:
# grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00 # initrd /initrd-version.img #boot=/dev/sda default=1 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title Red Hat Enterprise Linux Server (2.6.34) root (hd0,0) kernel /vmlinuz-2.6.34 ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.34.img savedefault boot #title Red Hat Enterprise Linux Server (2.6.18-194.3.1.el5PAE) # root (hd0,0) # kernel /vmlinuz-2.6.18-194.3.1.el5PAE ro root=/dev/VolGroup00/LogVol00 rhgb quiet # initrd /initrd-2.6.18-194.3.1.el5PAE.img #title Red Hat Enterprise Linux Server (2.6.18-194.el5PAE) # root (hd0,0) # kernel /vmlinuz-2.6.18-194.el5PAE ro root=/dev/VolGroup00/LogVol00 rhgb quiet # initrd /initrd-2.6.18-194.el5PAE.img
I don’t understand how, in one case, it can figure out VMWare’s filesystem just fine while in the other case, it cannot. What am I missing? Is there some special VMWare-related compile option I should be choosing? Is there something on the VMWare Fusion side that I need to change? I can’t figure this out! Any and all suggestions are greatly appreciated!
Ubuntu 18.04.1 on VMware Fusion 11 results in kernel panic with Packer
I am trying to create a VMware virtual machine using Packer, with Ubuntu Server 18.04.1 as guest OS. However, creation of the VM fails after having sent the boot command. The specific error seems to be related to APIC, although the boot command contains noapic . Also, setting acpi=off does not change anything. See the following screenshot for the detailed error message: The Packer configuration looks like this:
< "type": "vmware-iso", "vmx_data": < "numvcpus": "2", "memsize": "2048" >, "http_directory" : "http", "boot_command": [ "", "", "", "/install/vmlinuz", " auto", " console-setup/ask_detect=false", " console-setup/layoutcode=us", " console-setup/modelcode=pc105", " debconf/frontend=noninteractive", " debian-installer=en_US", " fb=false", " initrd=/install/initrd.gz", " kbd-chooser/method=us", " keyboard-configuration/layout=USA", " keyboard-configuration/variant=USA", " locale=en_US", " netcfg/get_domain=vm", " netcfg/get_hostname=vagrant", " grub-installer/bootdev=/dev/sda", " noapic", " preseed/url=http://>:>/preseed.cfg", " -- ", "" ], "boot_wait": "10s", "disk_size": 10000, "guest_os_type": "ubuntu-64", "headless": false, "iso_url": "http://cdimage.ubuntu.com/releases/18.04.1/release/ubuntu-18.04.1-server-amd64.iso", "iso_checksum": "e8264fa4c417216f4304079bd94f895e", "iso_checksum_type": "md5", "ssh_username": "guest", "ssh_password": "guest", "ssh_timeout": "30m", "shutdown_command": "echo 'packer' | sudo -S shutdown -P now" >
Any ideas of what might be the problem, and how to fix this?
PS: The exact same configuration works perfectly when using VirtualBox instead of VMware Fusion.