Black screen at boot for 1 min before login screen

Hello,

This is my first post here because I've always found what I was searching for, but this time I just can't figure out what happens. The problem is a VERY long black screen after grub and before login page.

I've already disabled lvm2-monitor.service because it was slowing the boot and now my report looks like this

systemd-analyze blame         
           903ms lightdm.service
           604ms apparmor.service
           442ms snapd.service
           389ms systemd-logind.service
           350ms dev-sda3.device
           308ms upower.service
           244ms polkit.service
           218ms systemd-udevd.service
           205ms systemd-journald.service
           152ms NetworkManager.service
           115ms avahi-daemon.service
           106ms maia-console@tty1.service
            96ms tlp.service
            74ms systemd-journal-flush.service
            62ms systemd-udev-trigger.service
            51ms systemd-modules-load.service
            46ms ModemManager.service
            33ms user@1000.service
            22ms accounts-daemon.service
            20ms systemd-tmpfiles-setup.service
            12ms systemd-tmpfiles-setup-dev.service
             9ms ufw.service
             9ms snapd.apparmor.service
             8ms kmod-static-nodes.service
             7ms systemd-update-utmp.service
             6ms systemd-remount-fs.service
             6ms user-runtime-dir@1000.service
             6ms systemd-user-sessions.service
             6ms systemd-sysctl.service
             5ms dev-mqueue.mount
             4ms dev-hugepages.mount
             4ms systemd-random-seed.service
             2ms sys-kernel-debug.mount
             2ms sys-fs-fuse-connections.mount
             2ms sys-kernel-config.mount
             2ms tmp.mount
           476us snapd.socket
systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @1.870s
└─lightdm.service @966ms +903ms
  └─systemd-user-sessions.service @955ms +6ms
    └─network.target @954ms
      └─NetworkManager.service @801ms +152ms
        └─dbus.service @799ms
          └─basic.target @795ms
            └─sockets.target @795ms
              └─snapd.socket @794ms +476us
                └─sysinit.target @792ms
                  └─snapd.apparmor.service @783ms +9ms
                    └─apparmor.service @178ms +604ms
                      └─systemd-journald.socket @170ms
                        └─system.slice @153ms
                          └─-.slice @153ms
systemd-analyze               
Startup finished in 2.274s (kernel) + 1.870s (userspace) = 4.145s 
graphical.target reached after 1.870s in userspace

I've removed the 'quiet' in /etc/default/grub too, I just don't know what else to try...

Any help or tip is appreciated, have a nice day!

1 Like

Your system may be low on entropy at boot time. I would recommend installing haveged ─ if it doesn't help, then you can easily disable it again later.

You'll find the instructions in the article below... :arrow_down:

Welcome to the forum, by the way. :wink:

2 Likes

Fast, clear and nice answer, thank's a lot! Sadly it does not change anything. Only thing I've noticed is that, sometimes, instead of having a black screen with the report I originally posted, I get a completely different one with tons of services and a launch time around 3 mins according to systemd-analyse. If you want I can post it too but I guess maybe it's another problem that my computer does not always start the same way... sight

Well, it was worth a try, given that many people have reported the same issue, and in their case, it was down to not enough entropy being available at boot time.

I cannot comment about the 3-minute launch time, other than that it's exceptionally long. :astonished:

My machine here boots up from pressing Enter at the the GRUB menu to the SDDM login screen in only 9 seconds.

The appearance of all those services on your screen is because you've removed the quiet boot option, however.

Well, it may always happen that certain things are not initialized at the same tempo during the boot sequence due to a certain degree of randomness in the hardware, but it should never lead to such drastic symptoms.

Perhaps we might be able to offer more assistance if you were to provide us with more technical information regarding your system. Please post the output of the following commands...

inxi -Fxxxza
lsblk
1 Like

Yeah I agree, I mean everything is worth the try at this point. I've seen all the topics about this problem, but the thing is that every boot my systemd-analyse blame shows something different, but I always have a VERY long boot after the grub stuff. I know it has nothing to do with grub because the removed quiet showed the grub stuff, but after this I just have a long and painful black screen.

Here is the output of the commands:

inxi -Fxxxza
System:    Host: Shadow Kernel: 5.4.6-2-MANJARO x86_64 bits: 64 compiler: gcc v: 9.2.0 
           parameters: BOOT_IMAGE=/boot/vmlinuz-5.4-x86_64 root=UUID=a84239d8-1101-4fdc-8022-23a8f7344416 rw quiet apparmor=1 
           security=apparmor udev.log_priority=3 
           Desktop: i3 4.17.1 info: i3bar dm: LightDM 1.30.0 Distro: Manjaro Linux 
Machine:   Type: Desktop System: ASUS product: All Series v: N/A serial: <filter> 
           Mobo: ASUSTeK model: MAXIMUS VI HERO v: Rev 1.xx serial: <filter> BIOS: American Megatrends v: 1301 
           date: 12/20/2013 
CPU:       Topology: Quad Core model: Intel Xeon E3-1230 v3 bits: 64 type: MT MCP arch: Haswell family: 6 model-id: 3C (60) 
           stepping: 3 microcode: 27 L2 cache: 8192 KiB 
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 52816 
           Speed: 1000 MHz min/max: 800/3700 MHz Core speeds (MHz): 1: 1000 2: 1001 3: 1000 4: 1001 5: 1000 6: 1000 7: 1000 
           8: 999 
           Vulnerabilities: Type: itlb_multihit status: KVM: Split huge pages 
           Type: l1tf mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable 
           Type: mds mitigation: Clear CPU buffers; SMT vulnerable 
           Type: meltdown mitigation: PTI 
           Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via prctl and seccomp 
           Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization 
           Type: spectre_v2 mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling 
           Type: tsx_async_abort status: Not affected 
Graphics:  Device-1: NVIDIA GK104 [GeForce GTX 770] vendor: eVga.com. driver: nouveau v: kernel bus ID: 01:00.0 
           chip ID: 10de:1184 
           Display: x11 server: X.Org 1.20.6 driver: nouveau unloaded: modesetting alternate: fbdev,nv,vesa 
           compositor: compton resolution: 1920x1080~75Hz, 1920x1080~60Hz 
           OpenGL: renderer: NVE4 v: 4.3 Mesa 19.3.1 direct render: Yes 
Audio:     Device-1: Intel 8 Series/C220 Series High Definition Audio vendor: ASUSTeK driver: snd_hda_intel v: kernel 
           bus ID: 00:1b.0 chip ID: 8086:8c20 
           Device-2: NVIDIA GK104 HDMI Audio vendor: eVga.com. driver: snd_hda_intel v: kernel bus ID: 01:00.1 
           chip ID: 10de:0e0a 
           Sound Server: ALSA v: k5.4.6-2-MANJARO 
Network:   Device-1: Intel Ethernet I217-V vendor: ASUSTeK driver: e1000e v: 3.2.6-k port: f040 bus ID: 00:19.0 
           chip ID: 8086:153b 
           IF: eno1 state: up speed: 1000 Mbps duplex: full mac: <filter> 
Drives:    Local Storage: total: 1.82 TiB used: 9.82 GiB (0.5%) 
           ID-1: /dev/sda vendor: Samsung model: SSD 860 EVO 1TB size: 931.51 GiB block size: physical: 512 B logical: 512 B 
           speed: 6.0 Gb/s serial: <filter> rev: 1B6Q scheme: MBR 
           ID-2: /dev/sdb type: USB vendor: Western Digital model: WD10JMVW-11AJGS3 size: 931.48 GiB block size: 
           physical: 512 B logical: 512 B rotation: 5400 rpm serial: <filter> rev: 1065 scheme: MBR 
Partition: ID-1: / raw size: 398.15 GiB size: 390.90 GiB (98.18%) used: 9.82 GiB (2.5%) fs: ext4 dev: /dev/sda3 
Sensors:   System Temperatures: cpu: 29.8 C mobo: 27.8 C gpu: nouveau temp: 36 C 
           Fan Speeds (RPM): N/A gpu: nouveau fan: 1200 
Info:      Processes: 195 Uptime: 12m Memory: 15.58 GiB used: 1.03 GiB (6.6%) Init: systemd v: 242 Compilers: gcc: 9.2.0 
           Shell: zsh v: 5.7.1 running in: urxvtd inxi: 3.0.37
lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 931,5G  0 disk 
├─sda1   8:1    0   549M  0 part 
├─sda2   8:2    0 532,8G  0 part 
└─sda3   8:3    0 398,1G  0 part /
sdb      8:16   0 931,5G  0 disk 
└─sdb1   8:17   0 931,5G  0 part 
sr0     11:0    1  1024M  0 rom

Don't mind sdb, it is just an external HD.

I add that I already tried to do a fresh install, nothing changed, and I use the i3-Community edition, which does start very fast on my laptop (2 secs).

Thank's again for your time.

I see you're using the nouveau driver. Have you tried using the proprietary nVidia driver? It may offer better results. :thinking:

I will see what I can do with this, I give you an update tonight.

1 Like

Alright it doesn't change anything, at this point I am desperate I have no idea what else to try...

Maybe it has something to do with the kernel?

Yes, I was just thinking of that... I see that you've got apparmor enabled. Perhaps disabling that would make a difference? :thinking:

I thought about it, but isn't a bad idea? I've seen it has to do with security or something

It is indeed a security framework, but it's not something you absolutely need. It's not a mandatory thing to have in GNU/Linux in order for your system to be secure. It might be useful for servers and workstations in a corporate setting ─ it's similar to SElinux, which is enabled by default in RedHat and CentOS ─ but personally, I think it's overkill. :thinking:

AppArmor and SElinux are frameworks that harden the system by strictly policing what applications can do. But not all applications have been tuned to work flawlessly with either of those two frameworks, and it is not uncommon for something to go wrong with either of those frameworks enabled.

Alright, I'll give it a try. dev-sda3.service seems very long too, and I did not find anything about that, but I do not think I can disable it too. What do you think?

Taking a long time to mount a partition or secondary or network drive ?
(oops no .. thats your root)

I have no idea why that is, but it's the systemd service for mounting that partition. :thinking:

Yep ahah, that's why I don't want to disable it, but I do not get why it is taking that much time... And this fresh install worked really nice on my laptop so I don't think it has to do with it

Do you have TRIM enabled via systemd or via the discard mount option in /etc/fstab?

Here is my file, I don't know where to find this info

  1 # /etc/fstab: static file system information.                                   
  2 #                                                                               
  3 # Use 'blkid' to print the universally unique identifier for a device; this may 
  4 # be used with UUID= as a more robust way to name devices that works even if    
  5 # disks are added and removed. See fstab(5).                                    
  6 #                                                                               
  7 # <file system>             <mount point>  <type>  <options>  <dump>  <pass>    
  8 UUID=a84239d8-1101-4fdc-8022-23a8f7344416 /              ext4    defaults,noatime,discard 0 1
  9 tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0

Remove the discard from the mount options for your root filesystem and use the systemd fstrim.timer instead.

First remove that option from /etc/fstab and then remount your root filesystem...

sudo mount -o remount /

Then enable the timer...

sudo systemctl enable fstrim.timer --now

Alright, here we are now, flush seems to be the new problem... (I reactivated apparmor as it does not seem to be the pb)

systemd-analyze blame
     1min 1.433s apparmor.service
     1min 1.083s dev-sda3.device
      1min 877ms systemd-journal-flush.service
           876ms systemd-logind.service
           729ms lightdm.service
           702ms snapd.service
           321ms upower.service
           244ms systemd-journald.service
           226ms systemd-udevd.service
           188ms polkit.service
           142ms NetworkManager.service
           117ms tlp.service
           112ms avahi-daemon.service
           107ms maia-console@tty1.service
            64ms systemd-udev-trigger.service
            50ms systemd-modules-load.service
            40ms ModemManager.service
            36ms user@1000.service
            19ms accounts-daemon.service
            17ms systemd-tmpfiles-setup.service
            15ms systemd-tmpfiles-setup-dev.service
            14ms snapd.apparmor.service
             8ms ufw.service
             8ms sys-kernel-debug.mount
             8ms systemd-update-utmp.service
             7ms systemd-sysctl.service
             7ms kmod-static-nodes.service
             7ms user-runtime-dir@1000.service
             6ms systemd-remount-fs.service
             5ms systemd-user-sessions.service
             4ms systemd-random-seed.service
             2ms dev-hugepages.mount
             2ms sys-fs-fuse-connections.mount
             2ms dev-mqueue.mount
             2ms sys-kernel-config.mount
             2ms tmp.mount
           386us snapd.socket

Forum kindly sponsored by