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.
fstab file is empty as I followed the exact steps as the full installation guide linked up here in the comments and didn’t touch it. That’s as it came.
Ok will try that. Btw forgot to mention that I formatted boot and root partitions and now the GRUB menu won’t show anymore like before. It will just boot straight to the faulty install of Manjaro with emergency root shell. Anyway, will see if those steps work. If it means me having to recreate the LVMs from scratch then I could give that a try, but don’t see how that would make it any different since I formatted the root installation and just kept the home files on a separate Volume group
Ok, I’ve tried to do that, updated fstab with /dev/mapper/ubuntu--vg-root / ext4 defaults 0 1
And same for /home and /boot and /boot/efi. I then edited the hooks like you said and got the same error as before with it not finding /dev/mapper/ubuntu–vg-root and dropping me to the emergency root shell. I even tried to used systemd hooks as I saw that some people seemed to have solved it that way, and still same error.
I would be happy to scrap the LVM system if there is another slightly easier way to use an encrypted installation just for Manjaro. Does anyone know anything more about it? Cheers.
Oh God. I’m going to lose all the programs and stuff I have on Windows that I use for music. Not that this laptop is my main workstation, I use it as a secondary machine but it’s going to be a nightmare even just to reinstall Windows. Don’t think I’ll go down that route…
If I delete the existing LVM only, does Manjaro Installer support creating a new encrypted LVM and installing Manjaro on it instead?
Would it be alright if I deleted the LVM on LUKS and created just another big one that will include root, home and boot sections (alongside all the rest) and try to set up the installation with the graphical installer rather than having to do it all manually? I feel like I’m missing something the manual way…