I tried to get /usr on a separate partition and failed because I thought I knew what i was doing

Referring to this post

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.

The error I get after grub with kernel panic:

I dont see that.
I see

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.

Oh … well a backup works.

1 Like

Please edit your topic title to be clear and concise about the issue you’re having. Your language is not appropriate.

Please see:

1 Like

/lib is a symlink to /usr/lib, so yes, it’s because /usr isn’t mounted at boot. :arrow_down:

[aragorn] >   ls -l /
total 112
lrwxrwxrwx   1 root root    7 Mar 21 15:24 bin -> usr/bin
drwxr-xr-x   5 root root 4096 Jun 10 19:47 boot
drwxr-xr-x  20 root root 4180 Jul  3 15:19 dev
drwxr-xr-x   1 root root 4682 Jul  3 04:05 etc
drwxr-xr-x   1 root root   14 May 10  2019 home
lrwxrwxrwx   1 root root    7 Mar 21 15:24 lib -> usr/lib
lrwxrwxrwx   1 root root    7 Mar 21 15:24 lib64 -> usr/lib
drwxr-xr-x   1 root root    0 Sep 12  2020 mnt
drwxr-xr-x   1 root root   22 Mar 31 09:12 opt
dr-xr-xr-x 425 root root    0 Jul  3 04:04 proc
drwx------   1 root root  494 Jun 17 13:49 root
drwxr-xr-x  31 root root  740 Jul  4 03:40 run
lrwxrwxrwx   1 root root    7 Mar 21 15:24 sbin -> usr/bin
drwxr-xr-x   1 root root   26 Aug 11  2022 srv
dr-xr-xr-x  13 root root    0 Jul  3 04:04 sys
drwxrwxrwt  15 root root  600 Jul  4 22:41 tmp
drwxr-xr-x   1 root root  150 Jun 28 05:34 usr
drwxr-xr-x   1 root root  126 Jul  3 04:00 var

Oh right, duh. :person_facepalming:

I also don’t know how to manjaro-chroot into the system because / /usr and /var are all on different partitions.

Does somebody have an answer for this? I could not sudo mkinitcpio -P for instance

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… :arrow_down:

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
1 Like

Thanks! I will try it later, timeshift is still recovering files lol filling /usr again in root partition

I have never done a manual chroot before, so am not really qualified to comment, but might these three lines

be better written as

mount -t proc /proc /mnt/proc
mount -t sysfs /sys /mnt/sys
mount -t efivarfs /sys/firmware/efi/efivars /mnt/sys/firmware/efi/efivars

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.


Thank you for educating me once again.

1 Like
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)

LOL! It frkickng worked!! I am back into my system LOL! Everything works again!

I could run mkinitcpio -P with manjaro-chroot instead of chroot lol!

linux is so much fun lol didnt think I could get back in hahahah

Sorry I’m back at square 1, I emptied /usr (not the partition) and on reboot it stopped working again. same story.

So I think it cant find /usr on boot

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:arrow_down:

… suggests that you booted in legacy BIOS mode, rather than in UEFI mode.

I booted from a manjaro live usb

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.

Never understood why but this is the way for me.

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.

Hi all,

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.

Thanks all