I have no idea - so a guess - the device has not yet initialised?
Did the interface name change?
I vaguely recall reading about such setup years ago - I get the idea - if the system is remote one would like to keep data under lock and key, hence the LUKS container.
I have never worked with such setup so I am guessing and speculating what a Windows dual-boot does in that scenario
Has the init and the kernel been properly rebuild to match kernel changes?
I am thinking a unified kernel would be the way forward.
mount /EFI
to the correct places - I usually mount to /mnt
No need to open and mount /home to repair stuff - not needed for now
Then chroot.
blkid
or lsblk -f
to identify the components
It looks a bit unusual that you have an /EFI and a /boot partition.
sudo cryptsetup open /dev/nvme0n1p7 encrypted
sudo mount /dev/mapper/encrypted /mnt
sudo mount /dev/nvme0n1p6 /mnt/boot
… I do not know where the separate EFI partition belongs - perhaps /mnt or /mnt/boot
You can look at /mnt/etc/fstab once you have mounted the root partition … to see where it belongs.
chroot: manjaro-chroot /mnt /bin/bash
Then you can access logs and do what would need to be done.
If file system is BTRFS, the procedure is a bit more complex but there are posts and wiki articles here on how to do that.
I have zero experience and can’t advise.
Just for the test, did you try to remove that hook to verify if the problem is there?
There was a major version bump for systemd with some changes, maybe something in this hook changed and something Has to be reconfigured. If the problem is confirmed to be the hook see the systemd changelog for hints.
P.s. the efi should be mounted to /mnt/boot/efi i guess.
Thanks a lot for all the input. It was the netconf hook and chroot worked so far. I did not find the time jet to look into the netconf hook problem. If someone already knows what to do i happy for a solution.
Disclaimer: I’ve never used encryption or remote access, so I am far from being an expert on this. Hopefully the above will point you in the right direction though.
Thanks, I did read into it a bit, but did not find a solution. Probably because I only partly understand the problem.
Did the busybox hooks stop working and I have to use systemd hooks instead? If yes are there more beginner-friendly instructions somewhere?
Not really if the systemd hook is used, because then systemd will handle the init. All the base hook then still does is add the busybox emergency shell, but systemd disables that for security reasons, making base useless.
Of course, if you do want to keep the rescue shell, then you still need to include the base hook, and add “SYSTEMD_SULOGIN_FORCE=1” to the kernel boot parameters.
