General > Security & Bug Fixes
VirtualBox Update Bug Linux Lite
trinidad:
Unfortunately removing the package from the terminal will not collect the dependencies broken or unbroken to fix correctly, so yes you are probably better off to reinstall.
Yep. Tracked down the beginning of the problem. V-box updates for guest additions are from the 18.04 Ubu repos. Don't bother with them as they are buggy and have several ongoing issues. HOLD v-box updates unless you are on at least 4.13 HWE running Intel or 4.15 kernel. Also policy kit is out of date as well in LTS. Best to hold for now and wait. I think it would be best to just hold them back for now in the restricted repo for LL or people installing/running VMs are going to continue crashing them with updates. I didn't think of it immediately but it would be nice to see the install log from someone with a crashed vm. Here I think on the vm os /var/log/vboxadd-setup.log
TC
ch289:
So good to come here and see you all already figuring out exactly the problem I was having ;)
Am I correct in understanding then that the only solution for now is to abandon any VMs that had the update without those packages being held?
Thanks for all your work on this excellent distro
trinidad:
@ralphy
The v-box packages are definitely the issue but its frustrating to try to track any known bugs. It may be the kernel vrs. package repo involving the qt5 lib, given that v-box uses the one from Ubu 16.10 even though it's listed the same in 16.04. It may also be the v-box login message application, which may be deprecated relative to lightdm. I am leaning toward a combination of factors that are causing the issue in the v-box updates. In any case I have an updated v-LL 3.8 running on my Deb machine again.
For now your method works for installation.
1) Do NOT install updates during installation, or third party software.
2) Do NOt select autologin during installation.
3) After the system reboots and is up and running HOLD the three v-box packages BEFORE running updates.
TC
ralphy:
@Edgewood - virtualbox updates is what's causing the issue for the most part. As long as these updates are not installed there will be no issues with the VM. Tested on VMWare Workstation Pro 14, VMWare Fusion and ESXi.
Also during updates I kept all original files when prompted (/etc/issue, etc/release and so on.) I installed every single update with VNC enabled and disabled, no vmware-tools installed and also no open-vm-tools installed just to make sure it was not a conflict between packages.
So, I would certainly hold those packages and wait for the next update and test again, but for now, if installed on a VMWare VM it will kill it. As I mentioned before, it seems to prevent policykit-1-gnome from launching which basically gives you a blank screen... lightdm/session cannot authenticate due to the missing authentication agent.
--- Code: ---sudo apt-mark hold virtualbox-guest-dkms
sudo apt-mark hold virtualbox-guest-utils
sudo apt-mark hold virtualbox-guest-x11
--- End code ---
OR
--- Code: ---sudo apt-mark hold virtualbox-guest-dkms virtualbox-guest-utils virtualbox-guest-x11
--- End code ---
Which of the three packages is the one actually killing it, I didn't test between those three because they pretty much depend on each other, so by default users will be prompted to install at least two of the tree packages due to their mutual dependency. I might run some tests later. And it makes sense after all because other users have reported having issues after installing virtualbox updates (here in the forum - recent days).
Another thing I noticed, is that policykit failed to autostart when the primary user is set to auto-login during installation. It did the same for me twice, whether I installed updates or not during the installation process. virtualbox packages do not get updated during installation though, so there are two different scenarios in which we can end up with a blank screen VM or a VM that doesn't launch applications that requires administrative privileges due to the broken authentication agent.
Finally, I tested Install Updates (https://github.com/linuxlite/litesoftware/blob/master/usr/scripts/updates-gui#L177) and in the case of these packages they are defaulting to keep the original file, so users shouldn't have had any issues because of the non-interactive install.
That's what I've found during my tests. Maybe someone else wants to try to replicate this.
ralphy:
I've installed LL 5 times already to pinpoint exactly why it is breaking... I think I'm getting closer.
So far what I can say that broke in previous install is policykit-1-gnome... it fails to authenticate against session and hence apps won't launch, which make it look like everything is broken when in fact the authentication agent is what fails to start.
After I complete my fifth installation which is what I'm testing now, I believe that what's happening is that somehow the agent is failing when the primary sudoer account is created and set for auto-login during installation.
I'm running updates right now to see if it breaks again. If it doesn't break my previous description is certainly what causes the problems in the previous four installs.
It has been the authentication agent all along nevertheless.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version