My home backup is encrypted on a local raspberry pi SAMBA server made with Deja Dup. So would have to restore that once installation is finished and Deja Dup installed so that is it automated. But will consider this step if upon trying the guide again doesn’t work or troubleshooting some of the steps…
By the way are you sure that GRUB doesn’t need a separate LUKS1 partition to work? Is it safe to just leave it in the root? Will I need to add anything in the fstab? Don’t know if things have changed with latest versions of GRUB. Thank you very much.
I’d say the best venue is to use systemd-boot. It supports booting windows and it supports a fully encrypted root.
There is one key difference - the $esp must be mounted at boot.
I have experimented with encryption - not that I use it - it’s just the nerd in me which has to test things - at least I’ll be able to understand the issues.
I have all my notes online - I have a specific set of notes in mind here - I don’t recommend btrfs - after a couple of incidents I lost faith in it
systemd-boot is tricky on Manjaro due to the kernel naming schema. A long time ago a community member - I don’t know if the member is still here - @dalto created a script to facilitate maintenance of the systemd boot when you need to setup a new kernel.
It is a fairly simple task - when you know how - so sticking with the LTS kernel will ease the necessary maintenance with relation to systemd-boot as you would only ever have to shift the kernel until the next LTS is stable.
Marco is the window manager and lightdm the displaymanager.
If you mean “boot” as in /boot, then it doesn’t have to be mounted there. I usually mount mine at /efi.
If you mean “boot” as in the time of boot then it actually doesn’t need to be explicitly mounted. However, since the kernels and initrams live inside of it, it will need to be mounted when you update the system so it is probably better to mount it permanently in /etc/fstab or with a mount unit.
systemd-boot-manager is the series of scripts/hooks I created for Manjaro.
Alternatively, you can use kernel-install which is part of systemd.
Either LUKS1, or LUKS2 using PBKDF instead of Argon.
Same as usual, point the LUKS container (e.g, /dev/mapper/luks-XXXXXX or UUID) to the mount point.
If you decide to go the systemd-boot route, then it’s pointless to worry about encrypting /boot, since your kernel and initramfs will exist in non-encrypted space (in the FAT32 ESP or separate partition.) Systemd-boot needs to be able to access the kernel and initramfs before you can proceed to decrypt your system partition.
The same can be achieved with Grub and a separate non-encrypted /boot partition.
If you absolutely want everything encrypted, including the kernel and initramfs, then you need to use Grub, which will provide a rudimentary passphrase prompt to decrypt boot/root, in order to access the menu, and the kernel and initramfs, and thus in order to continue a normal boot process.
However, this goes back to using LUKS1 or LUKS2 without Argon.
Lol, I thought window and display manager were the same thing.
Yes, I did mean boot as in /boot partition to install grub, kernel and initramfs. I noticed that in arch unlike on Ubuntu, even in Calamares there seems to be a default mount point for the boot partition to /boot/efi whereas on Ubuntu it’s just /boot on the installer. Do I need to install all grub, kernel and initramfs in /boot or /boot/efi instead? Thank you very much to everyone, I really appreciate your support :+1 I’ll give it another go and post any issues that may arise.
It’s the method used to encrypt the master key embedded in the LUKS header.
Grub currently does not support Argon for LUKS2, but you can override the initial LUKS creation using PBKDF instead. (Trivia: PBKDF is used in LUKS1).
Some of the terminology overlaps. Mount points and partitions are sometimes used as interchangable terms.
To make it easier to visualize:
Partitions
ESP
– AKA: “EFI System Partition”
– Formatted as FAT32
– Under a running Linux system, usually mounted at /boot/efi or /efi
– Can be shared (often is) between multiple OSes, including Windows and Linux
– Usually sized around 300-500MB, but not a hard requirement, can be smaller (mine is 128M)[1]
Boot partition
– AKA: Where your kernel, initramfs, grub menus, etc, live here
– Not always a separate partition, sometimes it lives in the Root partition as a folder under /boot
– If used as a separate partition, commonly formatted as Ext4
– Under a running Linux system, usually mounted at /boot, if it’s a separate partition
– Can vary in size, usually around a few hundred MB for room to spare for multiple kernels
Root partition
– AKA: The “OS” or “System” partition where your OS, programs, system files, etc, live here
– Can even include everything in the /boot folder if you don’t have a separate Boot partition
– Can even include everything in the /home folder if you don’t have a separate Home partition
– Can be formatted to whatever you prefer, such as Ext4, XFS, Btrfs
– Under a running Linux system, always mounted at /
– Usually sized large enough to hold the OS with plenty of breathing room
Home partition
– AKA: Where your user data and personal files, live here
– Not always a separate partition, sometimes it lives in the root partition as a folder under /home
– If used as a separate partition, formatted to whatever you prefer, such as Ext4, XFS, Btrfs
– Under a running Linux system, always mounted at /home, if it’s a separate partition
– Usually sized large enough to hold your data and personal files, and so forth
Partitions and mount points are two different things. Think of a partition as the actual “block device”, and the mount point as the folder where this block device “begins its journey”.
If there is no separate partition (i.e, no separate block device), then the mount point is meaningless. So if you don’t have a separate boot partition (i.e, no separate block device formatted as Ext4), then /boot/ is in fact just a folder that lives in your Root partition, which upon browsing this folder you will see your kernel, initramfs, and grub menu/theme files.
[1] If you ever plan to use systemd-boot, it’s best to have a decently-sized ESP, so that it can comfortably house multiple kernels and initramfs’es. The reason I can get away with a tiny ESP is because I don’t plan to use systemd-boot. If I ever change my mind, I will need to upsize my ESP to something like 300 or 500 MB.
If you are using grub, it is best to mount your EFI Partition(ESP) at /boot/efi. Your kernel and initrams will go into /boot but that doesn’t need to be a separate partition.
It looks like you are confusing the ESP with the (optional) Boot partition (which is not as much a common practice anymore, as even the default Manjaro installation will not use a separate Boot partition, but rather just use the /bootfolder to dump the kernel, initramfs, and grub menu files.)
Fair enough then, I won’t bother with the /boot. I think I’ll just delete the partition and leave it inside the root…might actually be better if I want to have more kernel versions installed…cheers.
Right when I try this it says: cat: rootfs-pkgs.txt: No such file or directory same for the other command too.
By the way, following the finilising steps on the Ubuntu guide to enable GRUB to work on an encrypted partition and adding the UUID I at least managed to make GRUB support the basic decryption window based on the password and then take you to the actual GRUB list. Now, Windows won’t appear in that list, only Linux, Advanced options for Linux and a third option, when I select Linux it boots into Manjaro, but it doesn’t have a UI, and it can’t mount the VG named ‘ubuntu–vg-root’ (as I had it named from the previous Ubuntu MATE installation) it waits 10 seconds and then drops me to an emergency root shell which doesn’t seem to do much…
Mind you, I haven’t edited the fstab file whilst doing the installation
Ok, that’s what I was doing wrong. I didn’t realise I was in the home folder of the live ISO. I solved it by cd /.
Anyway, this is what I still get:
:: running early hook [udev]
Starting version 249.4-2-manjaro
:: running early hook [udev]
:: Triggering uevents...
Waiting 10 seconds for device /dev/mapper/ubuntu--vg-root ...
ERROR: device '/dev/mapper/ubuntu--vg-root' not found. Skipping fsck.
:: mounting '/dev/mapper/ubuntu--vg-root' on real root
mount: /new_root: no filesystem type specified.
You are now being dropped into an emergency shell.
sh: can't access tty; job control turned off
[rootfs ]#_
Now that’s what I think I’m missing. Something is going on that it won’t recognise the partition type when booting. Therefore I think I will have to edit the fstab with the UUIDs to make it work. I’ll give it another try and let you know when I can.
You’re missing the encrypt and lvm2 hooks in your mkinitcpio.conf. I believe you need them inserted in the order of block → encrypt → lvm2. (Must be after udev and before filesystems hooks.)
Perhaps in the chroot environment, you can edit your fstab to add the proper entries for /boot, /, and /home, and make the corrections in mkinitcpio.conf. Then rebuild the initramfs and Grub menu with mkinitcpio -P and update-grub, respectively.
This feels a bit too precarious for me, considering it’s not a fresh installation, but rather salvaging your existing LUKS + LVM setup from Ubuntu.
Your fstab is… empty?