I created a new encrypted partition for /usr and rsynced /usr into it and then deleted the contents of /usr on / partition
I have this setup and tweaked it since 2017
I did a bunch of other stuff like changing partition sizes etc. and checking partitions for errors
I set up crypttab and fstab correctly
everything went great, I thought
decrypting / and booting into grub went as normal, but then it did not find /usr partition and gave me a black screen saying I’m on my own.
Does somebody know how I can fix it?
I am running timeshift from my backup drive as we speak to repair / and /usr to get it booting again.
ERROR: Root device mounted successfully, but /sbin/init does not exist.
Which seems pretty self-explanatory, but does not have to do with /usr.
On my system /sbin/init is a symlink to ../lib/systemd/systemd which translates to simple /lib/systemd/systemd.
I’m not sure why its missing, or if its the only thing missing.
Assuming that your EFI partition is /dev/sda1, that your root filesystem resides on /dev/sda2, that your /usr is on /dev/sda3 and that your /var is on /dev/sda4 — adapt this to your real situation! — try the following…
sudo su -
mount -t auto /dev/sda2 /mnt
mount -t auto /dev/sda1 /mnt/boot/efi
mount -t auto /dev/sda3 /mnt/usr
mount -t auto /dev/sda4 /mnt/var
mount --bind /dev /mnt/dev
mount -t proc proc /mnt/proc
mount -t sysfs sysfs /mnt/sys
mount -t efivarfs efivarfs /mnt/sys/firmware/efi/efivars
chroot /mnt /usr/bin/bash
mkinitcpio -P
Well, no, because then you might just as well use bind-mounts, and then you don’t need the -t option.
There are reasons as to why you shouldn’t use bind-mounts for /proc and /sys. For /dev it’s okay, because that’s a tmpfs, but /proc and /sys are virtual filesystems exported by the kernel. You should not bind-mount those inside a chroot, but instead, you should mount them explicitly.
mount -t efivarfs efivarfs /mnt/sys/firmware/efi/efivars
I think everything works, I was able to chroot into the system, except the above line did not work because the mount point was not found, and mkinitcpio -P needs firmware to run properly
below my errors:
[manjaro /]# mount -t auto /dev/mapper/root1 /mnt/boot/efi
mount: /mnt/boot/efi: mount point does not exist.
dmesg(1) may have more information after failed mount system call.
[manjaro /]# modprobe efivarfs
modprobe: FATAL: Module efivarfs not found in directory /lib/modules/6.1.30-1-MANJARO
[manjaro /]# mount -t efivarfs efivarfs /sys/firmware/efi/efivars
mount: /sys/firmware/efi/efivars: mount point does not exist.
dmesg(1) may have more information after failed mount system call.
[manjaro /]# mount
/dev/mapper/root1 on / type ext4 (rw,relatime,errors=remount-ro)
/dev/mapper/usr2 on /usr type ext4 (rw,relatime)
/dev/mapper/var4 on /var type ext4 (rw,relatime)
dev on /dev type devtmpfs (rw,nosuid,relatime,size=8099812k,nr_inodes=2024953,mode=755,inode64)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
This is my new error, I don’t know where it goes wrong. I double checked fstab, crypttab mkinitcpio and grub though its possible i screwed something up there but i dont think so.
What amazes me is that /usr is not empty, indicating that /usr did get mounted? But i havent decrypted it yet at this stage.
Either you hadn’t fully emptied the /usr directory on the root filesystem, or your new /usr partition is incomplete. It is possible that the encryption has something to do with that — I have no experience with encrypted filesystems, but there is either way never a reason to encrypt your /usr, because there’s nothing confidential in there.
Also, this…
… suggests that you booted in legacy BIOS mode, rather than in UEFI mode.
That’s what was said to me when I could not chroot on my computer when using a live usb but turned out to most likely not be the case.
I can only say this, doing what you say “I should never do” was the ONLY solution to the problem I had (could not use update-grub in chroot)
This is what I HAD TO do (I tried not binding, but it will not work without it)
Efivars and all that was also suggested, but I have never seen that on my computer, but I do run btrfs not ext4.
But maybe worth a try? (adjust to what fits you and ext4)
sudo mount -t btrfs -o subvol=@ /dev/sda7 /mnt
sudo mount -t vfat /dev/sda5 /mnt/boot/efi
sudo mkdir /mnt/hostrun
sudo mount --bind /run /mnt/hostrun
sudo manjaro-chroot /mnt /bin/bash
mount --bind /hostrun /run ## yes, inside of chroot
If I did not mount /run update-grub would not work correctly.
Mounting /run directly to /mnt/run only created a directory called “mount” inside of chroot /run but if I mount it to the created dir /mnt/hostrun It shows all content. BOTH OF THEM has to be done with --bind for it to work on my computer.
The live USB can boot in either legacy BIOS mode or in UEFI mode, depending on what the UEFI firmware is set up to do. Commonly, if legacy BIOS emulation (CSM) is supported, an UEFI will always attempt to boot in legacy BIOS emulation mode instead of native UEFI mode.
In your case it was because you had been tinkering and not giving us all the information, so I had to go by the information you provided.
When you reported that the efivarfs was already mounted, it became clear that it was not a matter of UEFI versus BIOS. In the case of @whatthe, the efivarfs support module isn’t even loaded into the kernel and the mountpoint does not exist. Ergo, they have booted in legacy BIOS emulation mode.
I could not get it to work to get /usr on a different bootable encrypted partition.
The problem was that I could not get crypttab to unlock the encrypted /usr partition during boot.
I still don’t know what exactly why it went wrong (doublechecked uuid’s and crypttab and fstab multiple times and mkinitcpio -P with usr hook and sudo update-grub), but it’s alright I repartitioned the harddrive and I rsynced everything from the backup.
