• 0 Posts
  • 58 Comments
Joined 3 years ago
cake
Cake day: October 6th, 2023

help-circle


  • Did the problem begin right after a kernel upgrade? Slim chance, but only thing I can think of is maybe some module your boot process depends on is no longer built-in the kernel and needs to be added to initrd manually. I always have an LTS kernel installed as backup to be able to exclude these kind of fucky issues.

    If you don’t have an LTS kernel installed, you could try to boot a live usb, chroot into your EndeavourOS installation (don’t forget to do a mount -a inside the chroot environment to mount boot and efi partitions) and install the LTS kernel. If you’re able to reboot with an LTS kernel that makes debugging a whole lot easier. Best of luck.

    (The ‘shorter uuids’ are probably the vfat boot and efi partitions btw. Maybe you have access to lsblk or blkid in rescue mode to give some hints? You could compare them to live usb outputs of those commands)









  • Not a dig at you or the script author, but I’m kinda miffed we’re relegated to running some rando github user’s bash scripts to check if we’re affected. This is the direct opposite response one should have to this kind of attack. I feel the AUR maintainers should have been more forthcoming about what they are doing to stop the attack and how users can mitigate the consequences if affected.