Fix GNOME GUI Login After Upgrade to Debian 10 Buster (VirtualBox VM)
Hello!
Yesterday I upgraded my old Debian VirtualBox VM from Debian 9 stretch to Debian 10 buster.
After going through all the usual upgrade steps from the official documentation and rebooting, I found myself waiting for the GNOME user selection in order to log in. Except that it was stuck with the gray background and nothing except the mouse cursor was showing up or working.
I switched to a text-only terminal (Ctrl+Alt+F5) and logged in via command line. Looking at /var/log/syslog I found the following messages repeating over and over:
gnome-shell[1281]: Failed to set CRTC mode 1448x953: Invalid argument kernel: [ 192.917346] [drm:drm_crtc_helper_set_config [drm_kms_helper]] ERROR failed to set mode on [CRTC:29:crtc-0]
1448x953 is the resolution I am using for the VM.
This current VM was created back when Debian 7 wheezy was still current, and I knew that a more recently created VM (originally with Debian 9 stretch) was working fine after upgrading to 10, so I figured that the info about the resolution from gnome-shell might have something to do with the VM's settings.
Sure enough, I found out that there were about a handful of settings that were different, most likely because over time VirtualBox defaulted to slightly different settings depending on my hardware, the template for the OS I selected (different Debian major releases) and the VirtualBox release itself. A couple of VM starts and configuration changes later I narrowed the problem down to the following VM setting:
Display => Screen => Video Memory
I raised the original 12 MB to 16 MB and thankfully the next boot showed the GNOME login mask as per usual!
Surely this is a very edge case kind of scenario, but I am hoping that this might help you in case you come across the same problem. All the other search results I found regarding roughly the same error message in the logs were about different things.
Thanks for reading!
Adobe Premiere Pro CS5 and the Long Loading Splash
Hi!
If you have used Adobe Premiere Pro CS5 (or several other CS5 products as I've read), you might have encountered long waiting times during the program launching. In the case of Premiere Pro CS5, the splash screen shows "Loading ExporterQuickTimeHost.prm" and sticks with it for a couple of minutes (yes, minutes). This is not even a one-time thing or a once-per-Windows-session, it happens each and every program launch.
When I researched this, I quickly found the answer in Adobe's forums: Premiere CS5 takes 5 minutes to start up
In fact, what's causing this is not just the Adobe program, but rather the combination of a firewall and the Adobe program. If you are as restrictive in terms of Internet access as I am, you might have forbidden Adobe Premiere Pro.exe outgoing IP connections altogether. However, it is trying to establish a TCP connection to localhost / 127.0.0.1.
The fix is to allow outgoing TCP (I chose IP, which of course includes TCP) to 127.0.0.1 for the following executables:
- <Premiere Directory>\Adobe Premiere Pro.exe
- <Premiere Directory>\32\Adobe QT32 Server.exe
- <Premiere Directory>\32\dynamiclinkmanager.exe
with <Premiere Directory> of course being the path to your Adobe Premiere directory.
Note: Of course you can still stop every other outgoing traffic. Regard the 127.0.0.1 rule as an exception.
If you are trying to apply this fix to other Adobe programs, you are on your own to find out which .exes require 127.0.0.1 TCP connections. With modern firewalls, however, this shouldn't be that big of a problem. Just look at the prompts your firewall pops up and/or determine the .exes via logging.
I hope that helps you enjoy your respective Adobe program(s) all the more. 🙂
Good luck and, as always, thanks for reading.
Update (2010-03-28):
I recently found out that with my kind of firewall "Adobe Premiere Pro.exe" would prompt me again for a rule for outgoing traffic to addresses different from the localhost zone. If that happens to you, make sure you don't accidentally replace or override the localhost rule you added above. Rather add an additional rule for all the remaining outgoing traffic and forbid it (or allow it, depending on what you want).