Cannot Boot after running `eos-update --aur`, Blackscreen after BIOS splash

The Problem:
After the update and rebooting the BIOS Splash shows up and I can boot windows from another disk or the live ISO from a stick without problem, however my EOS install just goes to a black screen. The monitor receives a signal since it does not go into auto standby.

What I tried:

  • boot live, mount the linux partition to /mnt and the boot partition to /efi (another try was to /boot) and
    – downgrade linux linux-headers to various earlier versions
    – reisntall-kernels
    – run yay, eos-update --nvidia, etc.
    – look at journalctl but it did not register any of the non working boot attempts
    – bootctl install

  • restoring a backup which i made beforehand using rsync → folder → .tar.7z
    – onto the old system
    – a fresh install on another drive but the same system
    — the fresh install worked fine but i think i might not know how to restore the backup correctly.

  • not sure what else I did since I tried to restore until deep into the night, because I could not stop trying.

None of the actions above yielded any change in behaviour. I am very new to linux and have been using EOS since christmas.

Some notes:

  • I have a windows nvme in the system
    – during a fresh install i have to remove the boot and efi flags from the windows boot partition to prevent the fresh install not booting.
    – I suspect I should have done that too during the update of the EOS install

-I used to backup my system. How do I restore it properly?
– On a fresh install: Do I need to chroot into it or can I boot the fresh install and rsync using reversed dest and source?
– Can I restore my old install (which already is a bit beaten up by my rescue attempts, namely running rsync of my backup on the root filesystem without chrooting)

  • Is there a proper way to recover such a system? I might have jumped the gun with a few things and I want to learn how to recover properly, but ended up googling and just nilly willy trying out the search results from this forum and arch wiki entries.
    – Can I still recover my system?

Thanks for reading!

Do you mean after the recent update with the dbus-broker or dbus-daemon option? Did it occur after choosing one of these? If yes, which did you choose?

I would reinstall Linux and Linux-headers from chroot with the Live USB that should repair your system.

Ther is a guide on that in Discovery(wiki)

I chose dbus-broker (labelled as 1 in the terminal). However I remember in my downgrading and reinstalling and reupdating craze I also chose the latter when I was prompted again. Neither worked.

Thanks for your answer, but I already did that.

Had the same problem. I tried a lot of things, nothing worked.
So i ended up with a fresh install.

In the future i will make more system backups :slight_smile:

I also had this problem several times in the last weeks. I did a lot of new installations in different partitions, mostly EOS-Kde with systemd-boot. after following updates the black screen appears instead of the boot-menue. Only live boot ISO from a stick works after that. But I was not able to repair the boot mechanism with arch-chroot etc, everything looked correct for me. Following method always helped me:

boot live ISO.
resize a partition to make little space
create a small new partition e.g. 20GB
new installation into the new partition
reboot after that as with any new installation

The boot-menue appears again and all entrys can be selected as before, be happy.

I have the impression, that the black screen is because the boot is trying to start from a wrong drive. The new installation repairs that somehow.

Next time the new installation into the same small partition is more easy.

Next time i will try that. Or only completely recreate the EFI partition? but my linux skills are not that high.
At the moment I’m a little bit afraid to install Updates :slight_smile:

I tried that in the past, also restored ESP-backup. Sometimes that worked, sometimes not. When the kernel has changed, its at least dangerous.

really strange. hopefully the cause can be tracked down in the future.

It happened again. :rage:

I will try to collect some logs tonight.

So its running again after new help-installation. Here is, what happened:

  1. Update using yay: yay bash-protocol
  2. reboot produces black screen, no boot-menu
  3. boot live-iso-stick
liveuser@eos-2023.11.17 ~]$ lsblk -f
NAME        FSTYPE   FSVER            LABEL           UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
loop0       squashfs 4.0                                                                         0   100% /run/archiso/airootfs
sda         iso9660  Joliet Extension EOS_202311      2023-11-17-11-34-04-00
├─sda1      iso9660  Joliet Extension EOS_202311      2023-11-17-11-34-04-00                     0   100% /run/archiso/bootmnt
├─sda2      vfat     FAT16            ARCHISO_EFI     0354-96F3
└─sda3      ext4     1.0              data            6f57615b-2047-40af-8f66-849e9d34df9a
├─nvme1n1p1 vfat     FAT32            ESP             9FBD-DD52
├─nvme1n1p2 ext4     1.0              eos_kde_routine 04f8ac4a-b9cb-4f0c-af54-1d258c072b18
├─nvme1n1p3 swap     1                swap            555a62f4-d66e-4a2b-aaa9-5a1d4b3e52ef
└─nvme1n1p4 ext4     1.0              eos_kde_hilf    70c85352-a7fa-4e64-8c8b-35f2771d4eed
└─nvme0n1p4 ext4     1.0              backup_1p4      79126ccb-c961-4725-9b1c-ca9fb908ae6d

[liveuser@eos-2023.11.17 ~]$ sudo mount /dev/nvme1n1p2 /mnt
[liveuser@eos-2023.11.17 ~]$ sudo mount /dev/nvme1n1p1 /mnt/efi

[liveuser@eos-2023.11.17 ~]$ sudo cat /mnt/etc/fstab
# /etc/fstab: static file system information.
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=9FBD-DD52                            /efi           vfat    fmask=0137,dmask=0027 0 2
UUID=04f8ac4a-b9cb-4f0c-af54-1d258c072b18 /              ext4    noatime    0 1
UUID=555a62f4-d66e-4a2b-aaa9-5a1d4b3e52ef swap           swap    defaults   0 0
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0
UUID=79126ccb-c961-4725-9b1c-ca9fb908ae6d /Backup        ext4    defaults
[liveuser@eos-2023.11.17 ~]$ sudo arch-chroot /mnt

[root@EndeavourOS /]# cat /etc/machine-id

[] inxi -Fxxc0z | eos-sendlog)

journalctl -k -b -0 | eos-sendlog (no entries)

journalctl -k -b -1 | eos-sendlog

[root@EndeavourOS mike]# lsblk -o name,type,size,PTTYPE,FSTYPE
loop0       loop   2.2G
sda         disk  29.8G
├─sda1      part   2.3G
├─sda2      part   119M
└─sda3      part   9.3G
nvme1n1     disk 953.9G
├─nvme1n1p1 part  1000M
├─nvme1n1p2 part 908.7G
├─nvme1n1p3 part  14.9G
└─nvme1n1p4 part  29.3G
nvme0n1     disk 476.9G
└─nvme0n1p4 part 388.5G
[root@EndeavourOS mike]#

eos-sendlog cat pacman.log

  1. new installation on nvme0n1p4 ext4

  2. reboot
    Now the systemd-boot-menu is back again.
    All entries are bootable again.

What me wonders is the naming/sequence of the disks are different in the live-iso-system:

ID-1: /dev/nvme0n1 vendor: Samsung model: MZVLW512HMJP-000L2 size: 476.94 GiB
ID-2: /dev/nvme1n1 vendor: A-Data model: SX8200PNP size: 953.87 GiB

and in the normal booted EOS-systems:

ID-1: /dev/nvme0n1 vendor: A-Data model: SX8200PNP size: 953.87 GiB
ID-2: /dev/nvme1n1 vendor: Samsung model: MZVLW512HMJP-000L2
lsblk -o name,mountpoint,label,uuid,partuuid
NAME        MOUNTPO LABEL           UUID                                 PARTUUID
├─nvme0n1p1 /efi    ESP             9FBD-DD52                            068ad604-36b2-4307-ad51-71cc9cfd22a8
├─nvme0n1p2 /       eos_kde_routine 04f8ac4a-b9cb-4f0c-af54-1d258c072b18 00609fd3-91a7-44cc-8b29-dc3bbdb21bf2
├─nvme0n1p3 [SWAP]  swap            555a62f4-d66e-4a2b-aaa9-5a1d4b3e52ef 5ac25f5a-283a-4415-af0c-a632fc24271d
└─nvme0n1p4         endeavouros     f7da7029-31a9-49a7-bcb6-1f06b0003a3a 2fe69f81-a501-4785-97b3-412d9fd0f27b
└─nvme1n1p4 /Backup backup_1p4      79126ccb-c961-4725-9b1c-ca9fb908ae6d 7b83a717-5be2-4fb9-9cae-3bbc9bbc9358

You received an error when writing to the EFI partition. Most likely this means it was full, the filesystem was corrupt or you have a failing disk.

Do you mean this:
Fehler: konnte nicht in Weiterleitung schreiben (Datenübergabe unterbrochen (broken pipe))


I do not understand this. I think, all data are written, 
otherwise it shold be not bootable after all.

KDE-Partitionsverwaltung: SMART-Statusbericht
Datum: 	24.01.24 19:43
Programmversion: 	23.08.4
Backend: 	pmsfdiskbackendplugin (1)
KDE-Frameworks-Version: 	5.112.0
System: 	Linux selfix 6.7.1-arch1-1 #1 SMP PREEMPT_DYNAMIC Sun, 21 Jan 2024 22:14:10 +0000 x86_64
Prüfen und reparieren von Partition „/dev/nvme0n1p1“ (1.000,00 MiB, Fat32)
Operation: Das Dateisystem auf der Partition „/dev/nvme0n1p1“ wird überprüft.
Befehl: fsck.fat -a -w -v /dev/nvme0n1p1
Das Dateisystem auf der Partition „/dev/nvme0n1p1“ wird überprüft.: Erfolgreich
Operation: Dateisystem auf „/dev/nvme0n1p1“ wird maximiert, sodass es die Partition ausfüllt.
Das Dateisystem auf der Partition „/dev/nvme0n1p1“ hat bereits die gewünschte Länge von 2.048.000 Sektoren.
Dateisystem auf „/dev/nvme0n1p1“ wird maximiert, sodass es die Partition ausfüllt.: Erfolgreich
Prüfen und reparieren von Partition „/dev/nvme0n1p1“ (1.000,00 MiB, Fat32): Erfolgreich

I can not see any error.
space ist still available.

In a private message, @moxdrox linked me this potential solution by @TheGreenkey, who also answered in another thread I made.

Disabling CSM (compatibility support module) in the BIOS fixed it for me.

Thanks everyone for helping by posting replies!

Thank you for the message!
In fact CSM was enabled on my machine. I just changed it to disabled, will see whether it solves the problem for me too.

After todays update to EOS 6.7.2-arch1-1 I belive the problem is solved for me too.
Many thanks! :+1: :white_check_mark:

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.