ISO 18.1.5 - VirtualBox loading time - 'black screen of death'

I'll give it a try with the minimal one, but something seems to be wrong with the regular ISO.
During that 5 minutes, there is like 0 cpu usage for at least 4 minutes.

edit minimal also takes ages. maybe something with my machine then? will try an older ISO just to see.

edit 2 XFCE 18.1.4 comes up within 30 seconds...

Watching water boiling you realize how long it takes.

There is definetely something wrong - the minimal Xfce ISO has now been loading for +4 minutes without any progress - 4m45s - to load - that is wrong.

Using the same virtual machine - using PacBang 2020.01 ISO - boots to X in 25s.

(Both using kernel 5.4)

1 Like

I split this to a separate topic

1 Like

Tested KDE 18.1.5 minimal: Also affected
Gnome minimal seems to be ok though.

I just recalled a link posted earlier to a article on kernel 5.5 and problems when snapd support is enabled. We could try disabling snap support in the kernel commandline. I just have to locate the post :slight_smile:


Update 2: Building an ISO using Openbox profile exhibit same - insane - ISO loading time. (manjaro-openbox-18.1.5-unstable-minimal-200104-linux54.iso)

This ISO is build using manjaro-tools-git r2852-699d178-1 and unstable branch.

Something is definitely wrong!

Tried that. Same thing.

Now looking into the logs it seems there is an issue with the notifications service.
It fails to start twice and service_start_timeout=120000ms, so we are 4 minutes.

Jan 04 15:51:12 manjaro tlp[1146]: Setting battery charge thresholds...done.
Jan 04 15:51:12 manjaro systemd[1]: Started TLP system startup/shutdown.
Jan 04 15:51:12 manjaro audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj==unconfined msg='unit=tlp comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jan 04 15:51:12 manjaro systemd[1]: Startup finished in 6.859s (kernel) + 12.811s (userspace) = 19.670s.
Jan 04 15:51:12 manjaro systemd[1]: NetworkManager-dispatcher.service: Succeeded.
Jan 04 15:51:12 manjaro audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj==unconfined msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=succes>
Jan 04 15:51:31 manjaro systemd[1]: systemd-hostnamed.service: Succeeded.
Jan 04 15:51:31 manjaro audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj==unconfined msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jan 04 15:51:31 manjaro kernel: kauditd_printk_skb: 11 callbacks suppressed
Jan 04 15:51:31 manjaro kernel: audit: type=1131 audit(1578153091.813:59): pid=1 uid=0 auid=4294967295 ses=4294967295 subj==unconfined msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? t>
Jan 04 15:53:11 manjaro dbus-daemon[1118]: [session uid=1000 pid=1118] Failed to activate service 'org.freedesktop.Notifications': timed out (service_start_timeout=120000ms)
Jan 04 15:53:11 manjaro dbus-daemon[1118]: [session uid=1000 pid=1118] Activating via systemd: service name='org.freedesktop.Notifications' unit='xfce4-notifyd.service' requested by ':1.7' (uid=1000 pid=1284 comm="notify-send VB>
Jan 04 15:53:11 manjaro systemd[1098]: Starting XFCE notifications service...
Jan 04 15:53:11 manjaro xfce4-notifyd[1293]: Unable to init server: Could not connect: Connection refused
Jan 04 15:53:11 manjaro xfce4-notifyd[1293]: cannot open display:
Jan 04 15:53:11 manjaro systemd[1098]: xfce4-notifyd.service: Main process exited, code=exited, status=1/FAILURE
Jan 04 15:53:11 manjaro systemd[1098]: xfce4-notifyd.service: Failed with result 'exit-code'.
Jan 04 15:53:11 manjaro systemd[1098]: Failed to start XFCE notifications service.
Jan 04 15:55:11 manjaro dbus-daemon[1118]: [session uid=1000 pid=1118] Failed to activate service 'org.freedesktop.Notifications': timed out (service_start_timeout=120000ms)
Jan 04 15:55:11 manjaro dbus-daemon[1118]: [session uid=1000 pid=1118] Activating via systemd: service name='org.gtk.vfs.Daemon' unit='gvfs-daemon.service' requested by ':1.16' (uid=1000 pid=1110 comm="xfce4-session " label="unc>
Jan 04 15:55:11 manjaro systemd[1098]: Starting Virtual filesystem service...
Jan 04 15:55:11 manjaro dbus-daemon[1118]: [session uid=1000 pid=1118] Successfully activated service 'org.gtk.vfs.Daemon'
Jan 04 15:55:11 manjaro systemd[1098]: Started Virtual filesystem service.
Jan 04 15:55:11 manjaro kernel: fuse: init (API version 7.31)
Jan 04 15:55:11 manjaro kernel: *** VALIDATE fuse ***
Jan 04 15:55:11 manjaro kernel: *** VALIDATE fuse ***
Jan 04 15:55:11 manjaro systemd[1]: Mounting FUSE Control File System...
Jan 04 15:55:11 manjaro systemd[1]: Mounted FUSE Control File System.
Jan 04 15:55:11 manjaro dbus-daemon[1118]: [session uid=1000 pid=1118] Activating via systemd: service name='org.a11y.Bus' unit='at-spi-dbus-bus.service' requested by ':1.19' (uid=1000 pid=1110 comm="xfce4-session " label="uncon>
Jan 04 15:55:11 manjaro systemd[1098]: Starting Accessibility services bus...
Jan 04 15:55:11 manjaro dbus-daemon[1118]: [session uid=1000 pid=1118] Successfully activated service 'org.a11y.Bus'
Jan 04 15:55:11 manjaro systemd[1098]: Started Accessibility services bus.
Jan 04 15:55:11 manjaro at-spi-bus-launcher[1353]: dbus-daemon[1359]: Activating service name='org.a11y.atspi.Registry' requested by ':1.0' (uid=1000 pid=1110 comm="xfce4-session " label="unconfined")
Jan 04 15:55:11 manjaro at-spi-bus-launcher[1353]: dbus-daemon[1359]: Successfully activated service 'org.a11y.atspi.Registry'
Jan 04 15:55:11 manjaro at-spi-bus-launcher[1353]: SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry
Jan 04 15:55:11 manjaro systemd[1098]: Started GnuPG cryptographic agent and passphrase cache.

I don't think the notify daemon is at fault here - but I have no idea where else to look.

The funny thing is, that this daemon is starting properly with VMSVGA.
So actually I do suspect it is because of that. (The timing would fit also, like the additional 4 minutes...)

Might not be the root cause though...

Retesting using VMSVGA

  • the same Openbox which took minutes to load - now loads within 30s.
  • the same goes for Xfce

The available driver for VBoxSVGA don't work anymore.

And that is strange because using Arch - it works using VBoxSVGA - but not Manjaro.

So after all - it is a VBoxSVGA vs VMSVGA issue or at least related.

1 Like

same for me

How exactly would one go about replicating this issue?

Host

❯ inxi -SCG --no-host
System:
  Kernel: 4.19.92-1-MANJARO x86_64 bits: 64 Desktop: Openbox 3.6.1 
  Distro: Manjaro Linux 
CPU:
  Topology: Quad Core model: Intel Core i5-4570 bits: 64 type: MCP 
  L2 cache: 6144 KiB 
  Speed: 798 MHz min/max: 800/3600 MHz Core speeds (MHz): 1: 801 2: 819 
  3: 805 4: 801 
Graphics:
  Device-1: Intel Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics 
  driver: i915 v: kernel 
  Display: x11 server: X.Org 1.20.6 driver: intel 
  unloaded: fbdev,modesetting,vesa resolution: 1920x1080~60Hz, 1920x1080~60Hz 
  OpenGL: renderer: Mesa DRI Intel Haswell Desktop v: 4.5 Mesa 19.3.1 

VBox VM guest

  • 2 VCPU
  • 2 GB RAM
  • 128M graphics
  • EFI

ISOs used

Switching between VBoxSVGA and VMSVGA (no installation)

  • VBoxSVGA takes +4m to load
  • VMSVGA is ready in less than 30s

Arch based PacBang load times do not change significantly - the only difference between the graphic modes is screen resizing.

There is definitely some off with VirtualBox in general. For Linux they recommend VMware graphics and the other VGAs are for Windows only. We may test an ISO with linux419 as kernel.

Maybe it's viable to combine my virtualmachine mhwd fixes with my one line guest modules screen-resize fix (I already tested that combination. Works great with vmsvga). I doubt upstream will adopt the latter for the reasons outlined in the third comment.

Can you also reproduce this with my mhwd fixes ISO? I've tried your settings and I can't reproduce it using my ISO. I'll download the XFCE ISO in the meantime.

That one is ok. Comes up immediately.

1 Like

Yep I can reproduce that with the XFCE ISO, but not with my mhwd-fixes kde ISO. I'll build an XFCE ISO with mhwd fixes for testing this.

1 Like

My xfce ISO with mhwd fixes which were merged doesn't seem to have this problem. I don't know why, maybe just a slightly broken ISO?

I am experiencing this problem too.
I've shared details here:

We will have those fixes in our 19.0 releases.

3 Likes

Forum kindly sponsored by