Ubuntu 18 Guest freezes after guest additions install

[d_sa]

Doing a fresh install of Ubuntu 18.04 in my guest with a Windows 10 host. After installing the Guest Additions and rebooting the guest freezes. I tried this with the same results in both 5.2.20 and 5.2.22. I've seen various internet postings that seem related but they focus in on 3D acceleration which is not enabled on my system.

[d_sa]

I have reproduced this on two different host machines. Both were windows 10 based hosts.

The reproduction is simple:

• - download/install current VirtualBox (5.2.22)
  - download Ubuntu 18.04 ISO
  - Create new virtual machine (I only change the memory to 4096 and virtual disk size to 128G)
  - Once installation is complete, let the Ubuntu OS go through its automatic updates. A 'uname -r' reports 4.15.0-39-generic.
  - install tools for guest addition use (gcc)
  - "Device->Insert Guest Additions CD image..."
  - follow prompt to install guest additions
  - reboot
  - die

[d_sa]

Some additional observations:

If I don't install gcc, make, and perl before running the guest additions installation I get the warning message about the system is currently not setup to build kernel modules but it seems to continue and creates and update-initramfs. After reboot I'm able to use the clipboard between host/guest.

But, if I install gcc, make, and perl, and rerun the guest additions installation it will build the kernel module and on reboot the system hangs as previously reported.

Question:

Are there more items that need to be installed on a virgin system to handle the full installation of the guest additions (outside of the gcc, make, and perl)?

Should I enter a bug ticket on this since it seems so easily reproduce-able?

[socratis]

Should I enter a bug ticket on this since it seems so easily reproduce-able?

First start by providing a complete VBox.log, from a complete VM run:

• Start the VM from cold-boot (not from a paused or saved state) / Observe error / Shutdown the VM (force close it if you have to).
• With the VM completely shut down (not paused or saved), right-click on the VM in the VirtualBox Manager and select "Show Log".
• Save only the first "VBox.log", ZIP it and attach it to your response. See the "Upload attachment" tab below the reply form.

In the meantime, I'm (re)installing my Ubuntu 18.04 to see if I can reproduce it.

[d_sa]

attached is the requested log

[socratis]

VirtualBox VM 5.2.20 r125813 win.amd64 (Oct 15 2018 15:10:47) release log
00:00:02.168583   Oracle VM VirtualBox Extension Pack (Version: 5.2.22 r126460; VRDE Module: VBoxVRDP)

You have a mismatch between the ExtPack and the main VirtualBox. You need to address that, pronto.

00:00:02.167684 Host RAM: 8097MB (7.9GB) total, 389MB available
00:00:02.326015 RamSize  <integer> = 0x0000000040000000 (1 073 741 824, 1 024 MB)
00:00:02.326272 VRamSize <integer> = 0x0000000001000000 (16 777 216, 16 MB)

There's no way that this VM will start. You are assigning memory to your guest, that you do not have available. Either close some applications on the host, or buy more RAM for the host.

I would seriously look at where your host is using all that RAM, increase the guest RAM to 1536 MB and the VRAM to at least 64 MB. And you could afford 2 CPUs for your guest from the 4 that your host has.

Finally, to answer your original question, "sudo apt-get install gcc make perl" is all that's needed to install the GAs. Which you have installed.

[d_sa]

I'm not sure how that is happening with respect to the .20 vs .22. I did drop back to a 5.2.20 version of VirtualBox to see if that changed anything and it didn't. This current view represents everything done from a .20 version of virtualbox. Now maybe the install of 5.2.20 didn't clean up the new extension pack. But to be clear, this problem was first identified on the 5.2.22.

As for the memory, yes, that can be a challenge but this VM came up and allowed me to do all the stuff I said. Then power down and reboot it... I suspect that the host OS will spill the memory needs to a cache file on the local disk to allow this to work. And it will fail every time I install the full extensions where it appears to be rebuilding some kernel driver. If I revert back to a snapshot before doing this it will run fine.

When I get a break, I will ensure the 20 vs 22 is all the same version...