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

oxidan · January 11, 2024, 9:47am

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

Questions:
-I used https://wiki.archlinux.org/title/Rsync#Full_system_backup 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!

Nomad · January 11, 2024, 12:39pm

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?

SCORPION2000 · January 11, 2024, 1:51pm

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)

https://discovery.endeavouros.com/category/system-rescue/

oxidan · January 11, 2024, 7:34pm

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.

oxidan · January 11, 2024, 7:35pm

Thanks for your answer, but I already did that.

moxdrox · January 13, 2024, 2:33pm

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

mke · January 24, 2024, 8:41am

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.

moxdrox · January 24, 2024, 9:07am

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

mke · January 24, 2024, 9:42am

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

moxdrox · January 24, 2024, 10:17am

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

mke · January 24, 2024, 12:51pm

It happened again.

I will try to collect some logs tonight.

mke · January 24, 2024, 5:51pm

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

Update using yay: yay bash-protocol
reboot produces black screen, no boot-menu
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
nvme1n1
├─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
nvme0n1
└─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
b71208daa80a47f2925d918b8d36a967

[https://0x0.st/HG_c.txt] 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
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

new installation on nvme0n1p4 ext4
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
nvme0n1                                                                  
├─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
nvme1n1                                                                  
└─nvme1n1p4 /Backup backup_1p4      79126ccb-c961-4725-9b1c-ca9fb908ae6d 7b83a717-5be2-4fb9-9cae-3bbc9bbc9358

dalto · January 24, 2024, 5:54pm

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.

mke · January 24, 2024, 7:09pm

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.

oxidan · January 25, 2024, 5:48pm

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!

mke · January 25, 2024, 10:58pm

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!

system · January 27, 2024, 10:58pm

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