Present Situation: I updated my system today (December 18). I didn’t check for errors during the update process and simply rebooted when KDE notified me that a restart was recommended. After rebooting, my EndeavourOS system now boots directly into Emergency Mode.
Debugging the problem: Systemd fails to mount EFI partition (/efi) during boot (Exit Code 32). Because this mount fails, the local-fs.target dependency also fails.
The Kernel is loading (proving the bootloader works), and the Root filesystem (nvme0n1p4) is healthy and accessible. The issue is strictly a mounting configuration error for the EFI partition.
I am currently in LIVE ISO that I downloaded on Dec 8
Fixed Mounts: Manually mounted Root (/mnt) and EFI (/mnt/efi) correctly in the Live ISO.
Restored Files: Created the missing kernel directory (.../6.18.1-arch1-2/) on the EFI partition and manually copied vmlinuz-linux and initramfs-linux.img there.
Updated Boot Config: Created a new loader entry (endeavouros-6.18.conf) pointing to these new files.
Checked fstab: Verified the fstab file has the correct UUID (1448-DD78) for /efi.
Even though the files are correct, the system still “panics” when trying to mount /efi at boot. This is likely due to a “dirty bit” on the FAT32 filesystem (common after crashes) or a strict mount option that halts the boot process on failure.
Not sure what to do now. I really need to get into my system safe and sound.
Background: I dual-boot Windows and EndeavourOS. On December 4, my laptop stopped charging; I had it repaired, and the issue was traced to the motherboard and the charger. Following the repair, EndeavourOS failed to boot. It was a database lock issue and what not that I don’t remember exactly, I think I managed to fix it using arch-chroot among many other things, after which everything worked correctly. I think I also performed a system update on December 8, which caused no issues.
Hi Dalto, thanks for replying. The EFI part contains the old kernel folder (6.17.9) but is missing the new kernel folder (6.18.1). The systemd-boot loader configuration for the new kernel is also missing.
So I created the folder, copy the files, and add the boot entry.
I copied them manually from /boot/vmlinuz-linux and /boot/initramfs-linux.img (inside the chroot) to the EFI partition. I did this because the automation wasn’t working and I was trying to manually match the systemd-boot entry I saw in the logs.
I also had to compress the boot file because it was too large and I was constantly getting not enough space error message.
Is this from within the chroot? If so, this is the problem. It looks like you installed mkinitcpio and removed kernel-install-for-dracut. That will absolutely break your boot process.
I would delete all the directory and files you copied. Delete the entry conf you created. Delete any old files in /efi tied to old kernels,
Then run pacman -R mkinitcpio-busybox mkinitcpio, pacman -S kernel-install-for-dracut and finally reinstall-kernels
# vim:set ft=sh
# MODULES
# The following modules are loaded before any boot hooks are
# run. Advanced users may wish to specify all system modules
# in this array. For instance:
# MODULES=(piix ide_disk reiserfs)
MODULES=(vmd)
# BINARIES
# This setting includes any additional binaries a given user may
# wish into the CPIO image. This is run last, so it may be used to
# override the actual binaries included by a given hook
# BINARIES are dependency parsed, so you may safely ignore libraries
BINARIES=()
# FILES
# This setting is similar to BINARIES above, however, files are added
# as-is and are not parsed in any way. This is useful for config files.
FILES=()
# HOOKS
# This is the most important setting in this file. The HOOKS control the
# modules and scripts added to the image, and what happens at boot time.
# Order is important, and it is recommended that you do not change the
# order in which HOOKS are added. Run 'mkinitcpio -H <hook name>' for
# help on a given hook.
# 'base' is _required_ unless you know precisely what you are doing.
# 'udev' is _required_ in order to automatically load modules
# 'filesystems' is _required_ unless you specify your fs modules in MODULES
# Examples:
## This setup specifies all modules in the MODULES setting above.
## No raid, lvm2, or encrypted root is needed.
# HOOKS=(base)
#
## This setup will autodetect all modules for your system and should
## work as a sane default
# HOOKS=(base udev autodetect block filesystems)
#
## This setup will generate a 'full' image which supports most systems.
## No autodetection is done.
# HOOKS=(base udev block filesystems)
#
## This setup assembles a pata mdadm array with an encrypted root FS.
## Note: See 'mkinitcpio -H mdadm' for more information on raid devices.
# HOOKS=(base udev block mdadm encrypt filesystems)
#
## This setup loads an lvm2 volume group on a usb device.
# HOOKS=(base udev block lvm2 filesystems)
#
## NOTE: If you have /usr on a separate partition, you MUST include the
# usr, fsck and shutdown hooks.
HOOKS=(base udev modconf kms memdisk archiso archiso_loop_mnt archiso_pxe_common archiso_pxe_nbd archiso_pxe_http archiso_pxe_nfs block filesystems keyboard)
# COMPRESSION
# Use this to compress the initramfs image. By default, gzip compression
# is used. Use 'cat' to create an uncompressed image.
#COMPRESSION="gzip"
#COMPRESSION="bzip2"
#COMPRESSION="lzma"
#COMPRESSION="xz"
#COMPRESSION="lzop"
#COMPRESSION="lz4"
COMPRESSION="zstd"
# COMPRESSION_OPTIONS
# Additional options for the compressor
#COMPRESSION_OPTIONS=()
I think I also did something in /efi/loader/entries/endeavouros-6.18.conf that I don’t know how to see now. Also don’t remember about compression. Can’t look back into history as ISO is started from scratch.
I had touched a lot of things. Sorry, I didn’t know any better. I should have asked help earlier itself.
I just ran my regular update script and got the following:
:: Running pre-transaction hooks...
(1/1) Performing snapper pre snapshots for the following configurations...
IO Error (open failed path://.snapshots errno:2 (No such file or directory)).
==> NOTE: Custom flags should be put directly in: ~/.config/code-flags.conf
:: Running post-transaction hooks...
(1/6) Arming ConditionNeedsUpdate...
(2/6) Updating the MIME type database...
(3/6) Updating icon theme caches...
(4/6) Checking which packages need to be rebuilt
(5/6) Updating the desktop file MIME type cache...
(6/6) Performing snapper post snapshots for the following configurations...
Invalid snapshot '--type'.
==> root:
Clearing pacman cache
du: cannot read directory '/var/cache/pacman/pkg/download-PjSfzt': Permission denied
du: cannot read directory '/var/cache/pacman/pkg/download-IHZkl7': Permission denied
du: cannot read directory '/var/cache/pacman/pkg/download-1eoECw': Permission denied
du: cannot read directory '/var/cache/pacman/pkg/download-a7pCsE': Permission denied
du: cannot read directory '/var/cache/pacman/pkg/download-4CIiC3': Permission denied
du: cannot read directory '/var/cache/pacman/pkg/download-TF4iaR': Permission denied
du: cannot read directory '/var/cache/pacman/pkg/download-ZgDts9': Permission denied
du: cannot read directory '/var/cache/pacman/pkg/download-A9gWfG': Permission denied
du: cannot read directory '/var/cache/pacman/pkg/download-2SgUdl': Permission denied
du: cannot read directory '/var/cache/pacman/pkg/download-LG1e9A': Permission denied
du: cannot read directory '/var/cache/pacman/pkg/download-IlZaK1': Permission denied
du: cannot read directory '/var/cache/pacman/pkg/download-6bvV7a': Permission denied
du: cannot read directory '/var/cache/pacman/pkg/download-3Lbklv': Permission denied
==> no candidate packages found for pruning
Pacman cache deleted: 13G /var/cache/pacman/pkg/
Aur cache deleted: 295M /home/neo/.cache/paru/clone
This looks like there is something wrong with your snapper config or you rolled back a snapshot not quite correctly. Have you ever rolled back the root snapshot? If so, how did you do it?
rm -rf download-1eoECw/
trash: cannot trash directory 'download-1eoECw/' (from volume '/var/cache')
trash: `- failed to trash download-1eoECw/ in /home/neo/.local/share/Trash, because trash dir and file to be trashed are not in the same volume, trash-dir volume: /home, file volume: /var/cache
trash: `- failed to trash download-1eoECw/ in /var/cache/.Trash/1000, because trash dir cannot be created because its parent does not exists, trash-dir: /var/cache/.Trash/1000, parent: /var/cache/.Trash
trash: `- failed to trash download-1eoECw/ in /var/cache/.Trash-1000, because error during directory creation: [Errno 13] Permission denied: '/var/cache/.Trash-1000'
Also, if you aren’t familiar with snapper and snapshot management you might take a look at Btrfs Assistant. It is a GUI tool to make managing btrfs and snapper easier.