I’d like to use openSUSE Tumbleweed as a guest on a VirtualBox/Leap 42.1 host system. The installation went without further warning, but since the first reboot, right after the grub2-menu, I get the following screen: https://framapic.org/tmh9v4jWIcOY/nlDuBrPjxcpp.png
stating
"SMBus bas address uninitialized – upgrade BIOS or use force_addr=0xaddr
no valid rapl domains found in package 0
I don’t understand what this means, and I have no clue how to solve this. After a short time, this message diasappears, and I am left with a blinking curser and nothing more; I can’t find anything helpful neither in the host system logs nor in the VirtualBox logs.
Anyone here who could explain this to me?
That message is quite normal booting in VBox, but current Tumbleweed with Kernel 4.5.0.x has issues with current VirtualBox.
Maybe those are solved with the development VBox version 5.0.17 available from the Virtualization repo.
I was able to boot TW on the upstream VBox (from Oracle site) version 5.0.16 but installing Guest Additions version 5.0.17 (not a mistake…).
Maybe it’s easier to use other virtualization technologies, like KVM.
Ah… ok; That’s a pity.
In fact, I did not only want to see how TW works, but also how VirtualBox does. So okay, I’m going back to Quemu/Gnome-Boxes.
Anyway: Can I expect that waiting for the next (, next-to-next,…) snapshot of TW will improve here? Or is it a VB thing and will not be fixed this Leap cycle? In the former case, I could re-try in a month or so.
It’s a “VB thing” in that VB currently can’t run with the restricted access to the kernel memory space that kernel 4.5.x enforces.
AFAIK VB maintainers are addressing that and they might be successful sooner or later in the development version (currently 5.0.17).
If you see a new released version (5.0.18?) in the LEAP OSS repo maybe it’s worth a try.
As I said, Oracle rushed a 5.0.17 Guest Additions iso to address the issue after the VB 5.0.16 release, but the OpenSUSE packages come with the Guest addidions already packaged, which is easier to install but fails in this case…
I’m a bit confused now, sorry.
Afaik, the Guest Additions are to be installed inside the virtual machine (… guest…), aren’t they? How can I achieve that if my guest OS won’t boot? Or should I install them on the host (Leap)? With “5.0.17 Guest Additions iso” you meant an .iso of openSUSE-Tumbleweed with the latest 5.0.17stable Guest Additions, that can be downloaded from Oracle? If so, where could I find it? Up to now, I always used the .iso’s I got from the operating system vendor…
Or am I completely taking you wrong here?
Sorry for not being clear…
Yes, Guest Additions are to be installed inside the Guest and the 5.0.17 iso is available here https://www.virtualbox.org/download/testcase/VBoxGuestAdditions_5.0.17-106140.iso
I installed them in the 5.0.16 VBox from Oracle, not the OpenSUSE packaged version; somehow I managed to boot, maybe adding “iomem=relaxed 3” to the kernel command line to boot to single-user, CLI interface, and installed Guest additions from terminal; but I’m not sure and can’t check at the moment.
More in the afternoon, if I find something relevant.
Confirming that now I boot with the “iomem=relaxed” kernel option added to the boot command line and likely I first booted to single user (AKA “runlevel 3”) to install Guest Additions, according to the bash history still available on this VM:
**nohostname:~ # cd /run/media/<your username here>
nohostname:~ # cd VBOXADDITIONS_5.0.17_106140
nohostname:~ # ./VBoxLinuxAdditions.run**
Sorry, but I still can’t get through; Maybe I misunderstood you again, or maybe I’m simply not skilled enough. Here’s what I tried: During boot (of the guest system), I pressed ‘E’ to edit grub’s parameters, went to the line
linux /boot/vmlinuz-4.5.0-3-default root=UUID=... resume=... splash=...
and appended iomem=relaxed; Than pressed F10 to boot. Was that what you supposed? Unfortunately, it didn’t help.
OK, one last chance… as said, AFAIK** the plain VBox 5.0.10 currently on Leap repos simply does NOT work with current Tumbleweed guests**, so what we are discussing here is NO STANDARD procedure that might or might not work.
The current VBox video driver DOES NOT WORK with guests running kernel 4.5.0.x.
I was able to have one working but:
on the upstream (Oracle) VBox 5.0.16
with Guest Additions version 5.0.17.
Please note that Guest Additions version 5.0.17 MIGHT NOT BE COMPATIBLE with the current 5.0.10 OpenSUSE VBox, even if you manage to install them.
Please note also that to install the Oracle Guest Additions you need the module building environment setup in the guest OS (gcc, kernel-devel, kernel-default-devel …).
Anyway, even if you manage to boot, you are likely left with a “black screen” until you install the 5.0.17 Guest Additions unless… you boot to command line (apparently the basic framebuffer still works with kernel 4.5.0 guests).
To get there, my boot command line looks like:
linux /boot/vmlinuz-4.5.0-3-default root=UUID=xxx-yyy-zzz** iomem=relaxed 3 **resume=... splash=...
Once there, login as root; you have to setup the build environment (via “zypper in gcc kernel-devel …”) then mount the Guest Additions iso, cd there, run ./VBoxLinuxAdditions.run, hope for the best, reboot (still with “iomem=relaxed” but without “3” and … still with your fingers crossed )
Is it worth it? Frankly, I was in “testing mood” and I tried, but Tumbleweed on QEMU/KVM is much easier for the time being…
A shot in the dark, I’ve only seen “piix4” errors as non-critical errors (but very common). This has been discussed in the bugzilla, but I think maintainers have been reluctant to make changes because a guy in the Ubuntu world who did some research and published his results a year and a half ago seems to have disappeared leaving a number of underlying unanswerable questions…
I still am not sure whether that error is really a kernelspace error, I don’t see enough info to offer an analysis.
If you can’t boot into the Guest in Emergecy/Recovery mode, then you may need to mount the image from a LiveCD to apply the setting.
Note that in general “piix4” errors occur in <all> paravirtualized Guests, you will see the same error regardless whether you use VBox, VMware, KVM, Xen, etc. but as I described usually the errors are non-critical and usually ignored (just adds some extra seconds to bootup).
I recommend my script be run on every paravirtualized Guest as SOP.
Bottom line is this…
The displayed error in the OP post (rapl error, not actually the piix4 error) may be an error, but it’s only a non-critical error (according to the Ubuntu Forum poster).
It’s not related to the piix4 smbus error which typically is displayed before the “rapl” error is displayed, they’re two very separate errors (both non-critical).
To fix the piix4 error, you can blacklist the device using the script code I provided in my previous post (or just open the file and edit it as my script describes). You’ll save some seconds on every boot if you do this.
The rapl domain error is something that may not be avoidable for now, but I’ve found that at least on my machine it’s critical only on a Guest reboot(ie warm reboot). If you instead shutdown completely and restart (A cold boot), you should be able to login to your machine without a problem (of course the errors will still display).
)