Sadly, my Dell Latitude 5531 with encrypted ext4 root cannot boot anymore after the update:
[ TIME ] Timed out waiting for device./dev/.4ef432-dee9-4792-82c7-e8ddcf3e6e61.
[DEPEND] Dependency failed for /sysroot.
[DEPEND] Dependency failed for Initrd Root File System.
[DEPEND] Dependency failed for Mountpoints Configured in the Real Root.
[DEPEND] Dependency failed for Initrd Root Device.
[DEPEND] Dependency failed for File System Check on /dev/mapper/luks-d34ef432-dee9-4792-82c7-e8ddcf3e6e61.
You are in emergency mode. After logging in, type "journalctl .- xb" to view
system logs, "systemctl reboot" to reboot, or "exit"
to continue bootup.
Camnot open access to console, the root account is locked.
See sulogin(8) man page for more details.
Press Enter to continue.
Things I already tried (sadly no BTRFS and Timeshift):
Boot from USB stick with live system: manually encrypt mount root and boot/efi, chroot and reinstall kernels, and regenerate the initramfs files.
Tried to boot from different kernel versions (618…)
Checked fstab and mkinitcpio.conf, but everything looks unchanged. Maybe that’s the mistake? But get no pacnew files or something else during the update.
Reinstall of GRUB
What I observe: Encryption of the disk is successful, and GRUB is also working: I can switch to the GRUB menu with loaded theme if I hit ESC after entering the encryption password. But then it gets stuck.
Well, I’ve run out of ideas. Does anyone else have any?
[ TIME ] Timed out waiting for device./dev/.4ef432-dee9-4792-82c7-e8ddcf3e6e61.
[DEPEND] Dependency failed for /sysroot.
[DEPEND] Dependency failed for Initrd Root File System.
[DEPEND] Dependency failed for Mountpoints Configured in the Real Root.
[DEPEND] Dependency failed for Initrd Root Device.
[DEPEND] Dependency failed for File System Check on /dev/mapper/luks-d34ef432-dee9-4792-82c7-e8ddcf3e6e61.
You are in emergency mode. After logging in, type "journalctl .- xb" to view
system logs, "systemctl reboot" to reboot, or "exit"
to continue bootup.
Camnot open access to console, the root account is locked.
See sulogin(8) man page for more details.
Press Enter to continue.
As I wrote in the main thread:
I still have no solution. As my private notebook now runs into the same issue, I would think it’s not a very unlikely problem while updating to the latest stable. pacman.log shows no errors during update
Maybe the combination of an encrypted root filesystem with encrypted boot inside causes problems? On my desktop machine I have a separate, non-encrypted boot partition, and everything went fine.
Well, the error message is the same (just the UUID differs, of course). My working laptop is a Dell Latitude 5531 and my private one is a Schenker VIA 14 Pro (L23). So very different hardware: Intel vs. AMD, Kioxia vs Samsung SSDs, but the same result. I would guess it is not a hardware issue.
It has encryption. But not for boot. Because it has dual boot with Windows, I want to access GRUB without encryption. It has a separate boot partition that is not encrypted. The root partition is also encrypted. But no problems here.
I asked @TheInvisible since he didn’t report any logs but a solution (for his case). Regarding your issue do you have access to /var/log/pacman.log so you could post the logs of the last update?
Your post(s) have been moved to a dedicated topic.
Please provide your system information as described below.
Regards.
[Mini-HowTo] Provide System Information
Basic details provided by *-fetch type apps might give enough information for someone wishing to buy a computer, however, for Support purposes it’s best to ask your system directly.
Output of the inxi command will generate more useful and detailed information for those who may wish to help:
So you are still asked for your luks passphrase. I’m thrown into emergency mode without being asked for my passphrase. I’m currently doing a backup of the system, so I can tinker around without the risk of doing further damage to it. I will report back when the backup is done.
I have a similar configuration to yours with grub not being encrypted for the same reason.
I apologize for the delay, but I’ve got a bit of work to catch up on.
I end up in setting up a fresh installation on my private laptop. Afterwards, I compare the mkinitcpio.conf from the fresh installation and from my broken business laptop.
And an interesting difference appears at the HOOKS line:
Fresh installation
If I had to guess, I’d say the pacnew-checker crashed in the background, which is why the line didn’t make it into mkinitcpio.conf as it should have.
It’s also possible I simply closed it mistakenly. It was only during the second run on the second private laptop that I was absolutely certain no pacnew-check process was shown to me… In both cases, I updated with the pamac-gui not in shell.
I don’t know if that makes sense, but everything’s working again now.
What you term “the broken one” is actually the new syntax, whereby systemd-based hooks are used, versus the old one, which uses udev and busybox hooks.
The systemd hooks do work, but in the event of encryption, one must also change the syntax for the encrypted container in the boot loader configuration, which I’m quite sure you hadn’t done, and which thus resulted in a non-booting system.
That sounds about right.
In this context, ‘broken’ refers to the laptop itself – specifically its ability to boot – rather than the configuration.
However, my personal laptop, which has a fresh installation, had the ‘old syntax’ straight after installation. Is that correct?
I’ve now got back to my timeshift rsync snapshots and could see that the systemd hook had been entered in mkinitcpio.conf for quite some time. So that worked right up until the update.
But then the source of the error is probably less likely to be found in mkinitcpio.conf than in the GRUB configuration (and fstab, crypttab, etc.).
When I have some time, I’ll look into this in more detail. My personal laptop is now a good candidate for experimentation, as it’s still relatively bare at the moment.
The old syntax works, and is still supported. It’s just that upstream — i.e. Arch itself — has recently switched to the systemd-based hooks as the default. But this does also require a different syntax for referring to encrypted volumes at boot time.
And some reading for the freetime or other passers by:
(3.3.4)
and
1.2.4.1 was the problem, if you do not use udev but systemd and sd-encrypt in HOOKS you need the kernel parameter telling which is the encrypted device in the kernel line of /etc/default/grub (update-grub of course).
With udev you probably have cryptdevice=UUID=device-UUID:root instead.
If I can tag on to this – please split this off if my question strays too far from the topic --one of my systems has only the /home partition encrypted. This issue is only for full disk encryption, right?
I had already made the change to the HOOKS variable (switching from the udev style to systemd) in /etc/mkinitcpio.conf a few months ago, so that it reads:
(note that there is no sd-encrypt/encrypt and I am prompted for the unlocking of my home directory after the GRUB splash screen but before the login-manager)
