Booting up in VirtualBox not possible - i686 only

[philmmanjaro]

Beginning with addition of the new toolchain it seems not to be possible to boot any i686 ISO properly in VirtualBox, at least on my Ryzen system. Using Boxes it works.

[ThanosApostolou]

@philmmanjaro On an i686 live image I did these:

sudo pacman -S xorg
sudo systemctl restart lightdm

and then the session started fine!

So, my guess is that there is some needed package from the xorg group in multilib which is missing on the i686 images. Can you take a look at it?

[oberon-manjaro]

When you install xorg group you could simply check if any of the packages does not have the hint "reinstalling" during installation...?

[oberon-manjaro]

My other guess is that it's really about restarting lightdm service in your scenario. Maybe during initial startup just something takes to long and then lightdm gets timed out.
What happens if you only restart the service without reinstalling anything?
Also if something wouldn't have been installed successfully in the first place you'd have to see an error in your buildlog.

[ThanosApostolou]

I did over 20 tests and my findings are these:

1. Just restarting lightdm doesn't work. Running sudo pacman -Rnsc lightdm, then sudo pacman -S lightdm-gtk-greeter and restarting lightdm doesn't work either.

2. Running sudo pacman -S --needed xorg on both i686 and x64 live images lists the same 48 packages, so there's no difference on installed packages from the group xorg.

3. However, installing the group xorg and then restarting lightdm solves the problem on i686!

That's really weird. Maybe some package is needed for i686 which is irrelevant on x64????

@Oberon2007 can you try it on your i3 i686 live image where you had the same problem?

[oberon-manjaro]

My question is still:
When you run sudo pacman -S xorg, do you see
warning: foo-xxx-x is up to date -- reinstalling for each of the packages during installation?
Because there you would see immediately if a package is gettings installed only then for the first time.

[ThanosApostolou]

Yep same packages are installed and uninstalled on both i686 and x64:

[ThanosApostolou]

Ok, I think I understood why this works.

startx gives this error:

So, when I run cat /var/log/Xorg.0.log
I see this:

So, if I understood correctly how this works, the problem is that module vboxvideo cannot be loaded but by installing the xorg group then it uses fbdev or vesa as alternatives solutions. So, we need to understand why vboxvideo module cannot be loaded.

[ThanosApostolou]

I see the same errors on x64 so that doesn't explain it either....

[ThanosApostolou]

Just to confirm, installing either xf86-video-vesa or xf86-video-fbdev fixes the problem (don't need to install them both).

So, maybe these packages should be included at live images, at least as a workaround for now. Later today or tomorrow I will try to build an ISO with those packages included only in the live session and try to do an installation on virtualbox to find out if those packages need to be included on the installed system as well or if they just affect live session.

[ThanosApostolou]

Sorry for "spamming" this, last comment and I leave it for you to figure this out 😛

I compared the 17.0.2 and the 17.0.1 Xorg.0.log. After LoadModule fbdev and vesa fail (because the packages aren't included by default), then the problem seems to be at the kernel.

17.0.2 error:

17.0.1 booting fine:

I believe the important difference is that in 17.0.1 we get: using drv /dev/dri/card0, while in 17.0.2 we get open /dev/dri/card0: No such file or directory. I lost too many hours trying to figure this out (and failing...) so now I leave it up to you 😛

[philmmanjaro]

Well, On Boxes it boots up just fine. So your theory with the VirtualBox-Drivers might be correct. Try to add xdriver=vesa to the grub menu and mhwd will install vesa on that session. This means, we simply remove the virtualbox drivers from the live-session on i686 as x86_64 is fine.

[ThanosApostolou]

Digging a bit more it seems to be related with... surprise surprise... gcc7 again...

Trying to load vboxvideo module I saw these errors:

Then I found this:
https://bugs.archlinux.org/task/54252
which leads to this:
https://www.virtualbox.org/ticket/16772#comment:8

So, yeah better not use at all vboxvideo at i686 for now because it might take several time to get fixed upstream (the 2nd link mentions some fixes but I don't know if it's easy to include them or if it's too much trouble).

[oberon-manjaro]

Awesome! 🤣
Great research @ThanosApostolou , thank you!
So basically one would need to compile vbox 32bit with an older compiler version - which I guess will just not be possible to achieve, right @philmmanjaro ? Or is it? We love compiling vbox @philmmanjaro , don't we? 😆

[oberon-manjaro]

Ah. In the arch bugreport there is a solution posted!
Basically we'd need to patch only the 32bit guest module for linux49...

[oberon-manjaro]

At the bottom of the vbox link:

Fix is part of the most recent repository, also the latest available 5.1.x test builds have the fix. The changes are in r67293, r67294, r67295, r67296, r67297 and r67298.

So we could theoretically build one of these snapshots already ...

[oberon-manjaro]

If at all we want to go that route, I think 'fixing' the guest module with someones workaround is not a good idea, because then the ISOs might again conflict with vbox as soon as it gets updated with the official fix.
So I think the only clean way would be to use a newer vbox snapshot.

[oberon-manjaro]

Something to consider also is maybe: For whom is the issue actually a problem? Well only for bleeding edge systems based on gcc7 - meaning just Archbased and probably something like Fedora ... ?

[ThanosApostolou]

Fedora 26 has indeed the same issue (I tried with it 2-3 days ago and I had the same problem). Tumbleweed does have a vbox_fix_for_gcc7.patch (https://build.opensuse.org/package/show/openSUSE%3AFactory/virtualbox) but I don't know if it's about this issue or maybe about something else.

@philmmanjaro better revert the latest commit (manjaro/iso-profiles@e8b7840) since it's better to solve it with a new virtualbox snapshot. If this hasn't been solved until the final release, then we just need to encourage people to use Boxes instead of virtualbox if they want to try the i686 image in the forum announcements.

[oberon-manjaro]

I will try building the latest vbox testbuild-version - can't resist 😉 It will take a little while but later tonight I can say if that really fixes it, ok?

[Ste74]

But this suggest another question : how is important for us 32bit arch ?

[oberon-manjaro]

although it will only fix it for Manjaro hosts of course ... ... 😜

[oberon-manjaro]

Yes @Ste74 that's absolutely the question.
But I guess building vbox once until the next update arrives would be ok.

[philmmanjaro]

I added now the function to disable VirtualBox drivers if needed: manjaro/manjaro-tools@965de2f

[oberon-manjaro]

Working on the PKGBUILD for vbox svn version... I'll upload the 64bit package to someplace and let you know when it's ready.

[oberon-manjaro]

Or would you like to build it on your Ferrari maybe, @philmmanjaro ? In that case I'l just send you the PKGBUILD in a moment... 😉

[Ste74]

Not ferrari.. bmw m6 gt3 :D

[oberon-manjaro]

chrchr never mind - I'm nearly done with svn checkout - that alone already takes forever ... 😆 then I can just let it run - given that the build works as expected 😉

[philmmanjaro]

@Oberon2007: I've uploaded the ISOs now with VB-drv disabled on i686. As soon as we have the working version, we an switch back. The features is now added to manjaro-tools, so we may disable it again, when there is no fix or some broken. Seems gcc7 is again the key 😄

[oberon-manjaro]

we're just ahead of time... 😛

[philmmanjaro]

This is now fixed and committed to all branches 😸