Artix Linux Forum

NOTE:

FOR THE MANUAL, PLEASE VISIT - https://wiki.artixlinux.org/Main/InstallationWithFullDiskEncryption

This thread is for describing my experiences during the creation of this manual, as well as providing the support for those who try it. Feedback and improvement suggestions - are also welcome!

Found a nice guide at Artix Linux: Full Disk Encryption with UEFI (https://www.rohlix.eu/post/artix-linux-full-disk-encryption-with-uefi/) (web.archive.org (http://web.archive.org/web/20200626160946/https://www.rohlix.eu/post/artix-linux-full-disk-encryption-with-uefi/), archive.li (http://archive.li/fuvky)) and tried to follow!

Since I'm using a BIOS machine

• with an opensource coreboot+SeaBIOS (https://coreboot.org/status/board-status.html) for a better security (to avoid the proprietary UEFI holes/backdoors)
• with a *** coreboot-supported AMD-without-PSP *** (see the hardware descriptions & fully updated coreboot'ing instructions here) (http://dangerousprototypes.com/docs/Lenovo_G505S_hacking) - to avoid the Intel ME hardware backdoor (https://libreboot.org/faq.html#intelme) - this AMD is either fam15h Richland or early-fam16h Jaguar architecture (isn't newer than ~2014) - to avoid the PSP hardware  backdoor (https://libreboot.org/faq.html#amd-platform-security-processor-psp) found in late-fam16h Puma and fam17h Picasso(Ryzen)
• connected to a router with LibreCMC firmware (https://librecmc.org/) (OpenWRT fork for blobless routers which could run on 100% opensource) to avoid a router backdoor
• and Artix Linux (https://artixlinux.org/download.php) as a great Arch alternative, to avoid the SystemD backdoors/holes (https://www.theregister.com/2017/07/28/black_hat_pwnie_awards/) hidden in its' 1.3 Million lines of code (https://www.phoronix.com/scan.php?page=news_item&px=systemd-2019-stats)
  

- I had to change :

1) gpt ---> msdos :

parted -s /dev/sdX mklabel msdos

2) esp ---> boot :

parted -s /dev/sdX set 1 boot on

3) ESP ---> BOOT :

mkfs.fat -n BOOT /dev/sdX1

4) /mnt/boot/EFI ---> /mnt/boot :

mkdir /mnt/boot
mount /dev/sdX1 /mnt/boot

5) GRUB : --target=x86_64-efi --efi-directory=/boot/EFI ---> --target=i386-pc --boot-directory=/boot :

grub-install --target=i386-pc --boot-directory=/boot --bootloader-id=artix --recheck /dev/sdX

, and didn't install a efibootmgr package. Also, I had to additionally install these packages after chroot'ing :

pacman -S lvm2 cryptsetup linux mkinitcpio

- otherwise some of the later steps give me the errors; and didn't want to use a crypto_keyfile.bin - so skipped this part.

After completing this guide and rebooting to HDD, I see a GRUB selection window and then "Loading Linux linux / Loading initial ramdisk", but after that I get:

ERROR: resume: hibernation device 'UUID=...long ID here...' 
ERROR: device '/dev/mapper/lvmSystem-volRoot' not found. Skipping fsck
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 ]#

Interesting thing is that I can manually mount a root partition in this shell:

cryptsetup luksOpen /dev/sdX2 lvm-system

, then enter a partition password.

But how to force GRUB to do that - to ask a decryption password and continue booting normally?

Here's my GRUB config:

setparams 'Artix Linux'

	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod fat
	set root='hd0,msdos1'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-ieee1275='ieee1275//disk@0,msdos1' --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  A30C-4CBC
	else
	  search --no-floppy --fs-uuid --set=root A30C-4CBC
	fi
	echo		'Loading Linux linux ...'
	linux		/vmlinuz-linux root=/dev/mapper/lvmSystem-volRoot rw  loglevel=3 quiet resume=UUID=...long ID here... net.ifnames=0
	echo		'Loading initial ramdisk ...'
	initrd		/initramfs-linux.img
	

Here are three helpful answers I got on Arch Linux forum before my thread removal:

It turned out that some sed replacements from this guide above (https://www.rohlix.eu/post/artix-linux-full-disk-encryption-with-uefi/) didn't work for some reason! In particular, this code line:

$ sed -i "s/GRUB_CMDLINE_LINUX=\"\"/GRUB_CMDLINE_LINUX=\"cryptdevice=UUID=`blkid -s UUID -o value /dev/sdX2`:lvm-system\"/g" /etc/default/grub

So I booted from Artix LiveUSB, chroot'ed into this installed system

cryptsetup luksOpen /dev/sdX2 lvm-system
swapon /dev/lvmSystem/volSwap
mount /dev/lvmSystem/volRoot /mnt
mount /dev/sdX1 /mnt/boot
artools-chroot /mnt /bin/bash

Checked the other sed's and /etc/mkinitcpio.conf for "encrypt lvm2 resume" hooks just in case, then found a blkid for /dev/sdX2

blkid -s UUID -o value /dev/sdX2

, opened /etc/default/grub, inserted a manually created code line to the beginning of GRUB_CMDLINE_LINUX and re-generated the GRUB configs with

grub-mkconfig -o /boot/grub/grub.cfg

Then I can successfully reboot, enter a password (once) and boot to the installed system!  :) Although it's pretty bare: I need to install the packages like

pacman -S xorg xorg-xinit xterm mesa xorg-server openbox xfce4 xfce4-goodies nano

and put

exec xfce4-session

slightly earlier than a few ending lines at

nano /etc/X11/xinit/xinitrc

and then launch a graphical environment by startx or startxfce4 commands. However, there's no nice login manager etc.

So, I repeated everything from scratch, but this time - replaced a

basestrap /mnt base base-devel

part of the instruction with pointing a Calamares graphical Artix Linux installer to the previously created partitions!
That's a trick to get a nicely preconfigured Artix Linux while enjoying the custom encryption like

--verbose --type luks1 --cipher serpent-xts-plain64 --key-size 512 --hash whirlpool --iter-time 10000 --use-random --verify-passphrase luksFormat /dev/sdX2

or even stronger (need to think how to improve it and maybe to find even stronger different ciphers) . If your desired cipher couldn't be used by cryptsetup - and

cat /proc/crypto | grep "serp"

gives an empty output, running

cryptsetup benchmark

could help them to become available.

If the encrypted volume isn't mounted already, mount it by doing

cryptsetup luksOpen /dev/sdX2 lvm-system

To run Calamares from a root console:

cat /home/artix/Desktop/calamares.desktop | grep "Exec"

and copy-paste its' command. In Calamares, select storage device as the already-partitioned-and-encrypted LVM drive lvmSystem and choose "Manual partitioning", then assign a mount point / to /dev/lvmSystem/volRoot and let volSwap to stay as swap.

After the installation, complete the rest of this guide (https://www.rohlix.eu/post/artix-linux-full-disk-encryption-with-uefi/) using my hints above. Just make sure to remove the /mnt/etc/fstab entries before re-inserting them, and check if the steps advised by a guide - have been already done by Calamares. If

blkid -s UUID -o value /dev/lvmSystem/volSwap

doesn't give any results, run

sudo file -s /dev/lvmSystem/volSwap
# /dev/lvmSystem/volSwap: symbolic link to ../dm-1
sudo file -s /dev/lvmSystem/../dm-1
# /dev/lvmSystem/../dm-1: ..., UUID=...long ID here...

to learn the UUID of volSwap - for the manual insertion to /etc/default/grub instead of failing

sed -i "s/quiet/quiet resume=UUID=`blkid -s UUID -o value /dev/lvmSystem/volSwap`/g" /etc/default/grub

command, and of course run a

grub-mkconfig -o /boot/grub/grub.cfg

after that. If you still can't find a blkid for LVM's swap - you can skip specifying this argument and fix it later after the first successful boot to your freshly installed OS.

Now, the only remaining issue I'm seeing, is:

error: no such device: ...UUID of root partition here...
error: disk `lvmid/...very long...' not found.
error: disk `lvmid/...same very long...' not found.

Press any key to continue...

^^^ I get this angry message each boot, but after I press any key - I see a GRUB menu list, choose a top entry, it asks me a decryption password and boots successfully!  ???

At the attachments, here are my GRUB configuration files from grub-ok virtual machine (where it's working as intended) and grub-strange virtual machine (with this minor GRUB error above). etc_grub.d is the same, but etc_default_grub and boot_grub_grub.cfg are different. Also: /boot/grub/grubenv for a flawless working case - doesn't have a saved_entry line (or any uncommented lines at all). There seems to be a minor bug at GRUB configuration - which I will figure out and resolve it later.

More files are at https://github.com/informer2016/grub_investigation

Solution for the last problem:

1) back up a /etc/default/grub
2) purge a grub package with its' dependencies:

pacman -Rc grub

checking dependencies...
:: artools-base optionally requires artools-iso: Artix iso tools
 
Packages (3) artix-grub-theme-0.7-4  artools-iso-0.19.4-1  grub-2:2.04-7
 
Total Removed Size:  33.62 MiB

- notice the extra -c flag for removing packages and all packages that depend on them.
3) rm -rf

/boot/grub/
/etc/grub.d/
/etc/default/grub
/usr/share/grub/

if they haven't been erased. After that, make sure to

mkdir /boot/grub

4) install a grub package with its' dependencies (just don't install artix-grub-theme)

pacman -S grub

and restore /etc/default/grub from your saved copy
5) do

grub-install --target=i386-pc --boot-directory=/boot --bootloader-id=artix --recheck /dev/sdX

and

grub-mkconfig -o /boot/grub/grub.cfg

Not sure what was the origin of this problem, but now it's gone!  ;)  and here's my final /etc/default/grub config, if you'd like to use it as a template - just make sure to change the UUID's

EDIT : this final__etc_default_grub.txt file is still fresh - truly matches a newer artix-xfce-openrc-20230814-x86_64.iso - and can be used after you change xxx/yyy there

Excellent, thanks, pinned.

Thank you so much @nous , I'll continue improving the instructions above  ;) After more investigation in a new VM,
I'm pretty sure the last GRUB problem is caused by artix-grub-theme package. Simply removing it and doing

grub-mkconfig -o /boot/grub/grub.cfg

while artix-grub-theme is not installed ---> it was enough to fix the last GRUB problem mentioned above.
And if you'd look at grub-strange__boot_grub_grub.cfg.txt (https://forum.artixlinux.org/index.php?action=dlattach;topic=1541.0;attach=762) - some parts seem to be double mentioned! ??? I.e., see

insmod lvm
insmod ext2

repeats two times through the file, while grub-ok__boot_grub_grub.cfg.txt (https://forum.artixlinux.org/index.php?action=dlattach;topic=1541.0;attach=760) doesn't have this problem,
so there's certainly some mistake in /boot/grub/grub.cfg generation added by a presence of artix-grub-theme package

New Problem + Solution ;) Something got updated - and now, by following all the instructions above, there's a high chance of getting this error in the end of Calamares installation:

Installation Failed

Boost.Python error in job "bootloader".

Command 'grub-install --target=i386-pc --recheck --force /dev/sda' returned non-zero exit status 1.
Installing for i386-pc platform.
File descriptor 7 (/root/.cache/calamares/session.log) leaked on vgs invocation.
Parent PID 7025: grub-install File descriptor 17 (/dev/mapper/control) leaked on vgs invocation.
Parent PID 7025: grub-install WARNING: Failed to connect to lvmetad. Falling back to device scanning.
File descriptor 7 (/root/.cache/calamares/session.log) leaked on vgs invocation.
Parent PID 7025: grub-install File descriptor 17 (/dev/mapper/control) leaked on vgs invocation.
Parent PID 7025: grub-install WARNING: Failed to connect to lvmetad. Falling back to device scanning.
grub-install: error: attempt to install to encrypted disk without cryptodisk enabled. Set `GRUB_ENABLE_CRYPTODISK=y' in file `/etc/default/grub'.

Traceback:

File "/usr/lib/calamares/modules/bootloader/main.py", line 465, in run
    prepare_bootloader(fw_type)

  File "/usr/lib/calamares/modules/bootloader/main.py", line 437, in prepare_bootloader
    install_grub(efi_directory, fw_type)

  File "/usr/lib/calamares/modules/bootloader/main.py", line 344, in install_grub
    check_target_env_call([libcalamares.job.configuration["grubInstall"],

  File "<string>", line 11, in <module>

To prevent it from happening, after creating/mounting the partitions and before opening a Calamares installer, you'd need to

sudo nano /usr/lib/calamares/modules/bootloader/main.py

and comment out this line near the end of file at "def run()" function:

prepare_bootloader(fw_type)

--->

# prepare_bootloader(fw_type)

Since there doesn't seem to be an option to disable the GRUB installation at Calamares, this manual edit is a custom way of disabling - and it's fine, since we're going to install GRUB manually a bit later.

Hi everyone! New Artix user here coming from Fedora.

I'm having trouble setting up LVM on LUKS (https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_Entire_System#LVM_on_LUKS) despite the fact that I (I think) followed the steps from there^{[1] (https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_Entire_System#LVM_on_LUKS)[2] (https://www.rohlix.eu/post/artix-linux-full-disk-encryption-with-uefi/)[3] (https://invidio.us/watch?v=nCc_4fSYzRA)[4] (https://invidio.us/watch?v=kD3WC-93jEk)} correctly. When I turn on my laptop it doesn't ask for the decryption password, it just shows the GRUB shell and I can't decrypt the partition there using this tutorial (https://blog.stigok.com/2017/12/30/decrypt-and-mount-luks-disk-from-grub-rescue-mode.html). I can decrypt the partition in the live ISO and mount everything there but it seems that I made a mistake when configuring GRUB or mkinitcpio.conf.

Should I create another thread or can I post the related files here?

Edit: I have a setup similar to this (https://gist.github.com/luispabon/db2c9e5f6cc73bb37812a19a40e137bc). Good night :)

Hi, I managed to boot Artix using grub > configfile (hd2,gpt1)/EFI/Artix/grub.cfg (https://bbs.archlinux.org/viewtopic.php?pid=1919953#p1919953). In the end (almost) everything was configured correctly, any ideas why it doesn't boot and ask for the password automatically? Sorry if it this is not related to this thread :P

There are many potential points of failure, some are described in my second post here. It is hard to guess what exactly is wrong, and much easier to do it from scratch using a good instruction - than trying to fix what is already broken. You could either follow my detailed posts above after reading them all, or wait until I complete a new straightforward wiki manual. I already have a complete set of commands that's guaranteed to work: tested again today using a VirtualBox, installed from scratch on a blank Virtual HDD and almost everything is working perfectly. Hope to complete it in a next couple of weeks, then will post a link there.

Good day friend, I think this instruction is ready for your test 8)

https://wiki.artixlinux.org/Main/InstallationWithFullDiskEncryption

;-)

Thank you!
I'm new to Artix and Linux in general but I find it the most appealing distro to switch since I started to get interested in libre computing (using coreboot+SeaBIOS on T440p) and I wanted to get rid of as many blobs and backdoors as possible.

I managed to follow your guide up until one point, where the Calamares installer will install the bootloader, then it crashes with bootloader installation error.
It seems commenting out the line:

prepare_bootloader(fw_type)

in the python script does not work in the 2022-02-13 release of Artix OpenRC-LXQt.
I asked at the Calamares Github and they gave me a suggestion:

https://github.com/calamares/calamares/issues/1886#issuecomment-1041343454 (https://github.com/calamares/calamares/issues/1886#issuecomment-1041343454)

Should I still comment out the line or only add this to bootloader.py ?

1. In the future, please don't necro 2 year old threads. Create a separate thread.

2. I just installed Artix LXQt OpenRC from artix-lxqt-openrc-20220213-x86_64.iso in QEMU guest using the guide, and it booted without errors.

Make sure you understand the overall procedure and you are carefully applying every step of the guide (https://wiki.artixlinux.org/Main/InstallationWithFullDiskEncryption). That guide is made for installation on BIOS/MBR, not UEFI/GPT. For UEFI/GPT, there is a separate archived article (https://web.archive.org/web/20200626160946/https://www.rohlix.eu/post/artix-linux-full-disk-encryption-with-uefi/), also linked in the OP.

Edit: To be more specific:
Make sure you are typing the exact command you see there. Alternatively, you can use any other editor, but the pathname must be exactly the one listed. Also, make sure that the line in the file after edits is exactly like the one listed: beginning with #, with no whitespace before it.

Update: You don't even have to follow the guide anymore if you don't want precise control over parameters such as encryption algorithm, key sizes etc. Encryption is supported directly in Calamares, but nevertheless you need to know what you are doing.

You need to carefully read this:

https://wiki.archlinux.org/title/Partitioning#BIOS/MBR_layout_example

And in the case of the highly recommended BIOS/GPT, this:
https://wiki.archlinux.org/title/Partitioning#BIOS/GPT_layout_example
and this:
https://wiki.archlinux.org/title/GRUB#GUID_Partition_Table_(GPT)_specific_instructions

See the attached images for key points during install.

Dear strajder , thank you a lot for such a detailed reply with pictures!


This is a sticky thread for support/feedback for this Wiki manual (https://wiki.artixlinux.org/Main/InstallationWithFullDiskEncryption) and I still support it - although I'm a bit late this time, so thank you a lot for your kind help ;)


Seems I found the problem! At the Calamares newer version (Github: calamares/src/modules/bootloader/main.py (https://github.com/calamares/calamares/blob/calamares/src/modules/bootloader/main.py)) , they surrounded the previously-standalone "prepare_bootloader(fw_type)" line in this way:

    try:
        prepare_bootloader(fw_type)
    except subprocess.CalledProcessError as e:
        libcalamares.utils.warning(str(e))
        libcalamares.utils.debug("stdout:" + str(e.stdout))
        libcalamares.utils.debug("stderr:" + str(e.stderr))
        return (_("Bootloader installation error"),
                _("The bootloader could not be installed. The installation command <pre>{!s}</pre> returned error code {!s}.")
                .format(e.cmd, e.returncode))

    return None

There should be at least one not-commented-out line between try and except, otherwise the code will break - so a previous solution doesn't work anymore. Now, need to either comment-out the whole try/except block, or simply replace the same

    prepare_bootloader(fw_type)

with

    return None

After doing this, the installation completed successfully with artix-xfce-openrc-20220123-x86_64.iso  ;D . I already updated the Wiki (https://wiki.artixlinux.org/Main/InstallationWithFullDiskEncryption?action=diff) with this fix, and will re-check the rest of a guide as soon as possible

As I stated in my previous post in this thread, simply commenting out the appropriate line (as was indicated in the then-current version of the wiki article) in the then-fresh artix-lxqt-openrc-20220213-x86_64.iso works.

Strange, on artix-xfce-openrc-20220123-x86_64.iso I tried simply commenting out this line, but got the following error:

Installation Failed

Boost.Python error in job "bootloader".

Details:

<div><strong>&lt;class 'IndentationError'&gt;</strong></div><div>(&quot;expected an indented block
after 'try' statement on line 616&quot;, ('/usr/lib/calamares/modules/bootloader/main.py', 618, 5, '
    except subprocess.CalledProcessError as e:\n', 618, 11))</div>

But, if I replace it by return None or something else - i.e. libcalamares.utils.debug("Do nothing") - then the installation completes successfully

That is strange. I just tried that again with the indicated ISO and indeed, now it fails. The only explanation that comes to mind is that I must have used an older ISO anyway somehow. The other possibility is that I commented the entire try block, but then I would mention that. I did test the installation in QEMU by following that guide at the time.

In any case, Calamares now supports encryption from the UI directly, without the need for hacks like this one, as demonstrated in the screenshots.

Indeed; I'm only using this manual approach because I would like a stronger (although slower) encryption than Calamares default. Hopefully they'd implement the custom encryption option (i.e. Github: calamares/issues/1452 (https://github.com/calamares/calamares/issues/1452)) one day...

After going through 1 (https://forum.artixlinux.org/index.php/topic,3880.0.html) , 2 (https://forum.artixlinux.org/index.php/topic,3888.0.html) , 3 (https://forum.artixlinux.org/index.php/topic,3893.0.html) , 4 (https://forum.artixlinux.org/index.php/topic,3896.0.html) , 5 (https://forum.artixlinux.org/index.php/topic,3908.0.html) threads, I just did a huge update to the InstallationWithFullDiskEncryption (https://wiki.artixlinux.org/Main/InstallationWithFullDiskEncryption) manual !  8) Everyone is welcome to try it and share your feedback ;)

@qmastery thanks a lot !
i created/mounted my partitions, the luks container, the lvm volumes inside, then launched the installer.
but i couldn't get artix installed, not being aware of the little bugs in calamares :D
i followed your manual, went around the bugs, and finally it works :)

Consider changing the

cryptsetup luksFormat

command to use a hashing algorithm other than whirlpool as whirlpool was moved to openssl's legacy provider.

The info on cryptsetup is dangerously outdated. I'd suggest just using default values (for hashes and the like) and maybe consider using LUKS2.

As of yesterday encrypting ones system with the suggested values will result in a borked boot because of the missing support of the whirlpool hashing algorithm.

I haven't found any info on usage of openssl-1.0 and openssl-1.1 for encrypted boot. Does anyone know why it isn't using 3.x?

Huge thanks to @Dudemanguy ! He has replaced whirlpool with sha512 and by that he has fixed this manual for almost 2 months until I had the time to fix it further... Now, after some extra tweaks, it is working for whirlpool too, but I decided to continue using sha512 there until the further investigation on what gives the stronger encryption. The strongest encryption is my ultimate goal, and I believe that the settings used in this manual should be as secure as possible (and lets leave it up to a user to decide how much security to sacrifice for how much extra performance) - so I have also restored the key-size back to 512 The default cryptsetup values may give more performance, but that comes with a significant security sacrifice. Also, a great part of this manual - is a workaround for using the custom encryption values because the Calamares doesn't allow their customization, and that is a major issue for many. But if you are fine with these default values - maybe you may simply use the Calamares default encryption and install Artix much faster this way LUKS2 is still relatively new and security holes like this (https://www.openwall.com/lists/oss-security/2022/01/13/2) are happening to it from time to time, so using LUKS1 may be better for security and also compatibility reasons Actually it was bad for sha512 hashing algorithm too, it's just maybe it broke less and still allowed to boot. During the today's tests (in a VM by the fresh installs), I got

==> ERROR: binary dependency `libcrypto.so.3' not found for `cryptsetup'
==> ERROR: file not found: `/usr/lib/ossl-modules/legacy.so'

while installing the cryptsetup - regardless of whether whirlpool or sha512 have been used for that root partition! - and some extra tweaks were required to fix it for everyone At the time of writing this manual and until very recently, Artix used openssl-1.1 - you could verify it by looking at any "...-20220713-x86_64.iso" - so the manual also used 1.1. After the today's fixes, it uses both 1.1 and 3.x to allow the maximum customization of the encryption and i.e. make it possible to use whirlpool, although the instruction uses sha512 now

Definitely the case. Not specifying luks1 during luksFormat means that grub always rejected my password during decryption of the master key. Grub and luks2 are just not playing nice currently.

I also wanted to bring up a potential change / edit, where by parted always gave me issues later in the installation. When partitioning with parted, I would always encounter errors during grub-install. Either "unknown filesystem" or "cannot find EFI directory".

I followed the guide precisely 3 times. I then repeated the guide but using fdisk instead, and everything worked fine.

This is an edge case I would say, but maybe worth adding as a note in the partitioning step, that for some users parted can lead to issues with grub-install, and to use fdisk or alternative instead?

@tjex  Thank you for your kind words and feedback. Please tell, are you using this guide on BIOS or UEFI system - and, if UEFI, is it in CSM mode or not?

Dear @tjex , thank you so much for reporting this error and suggesting a workaround. It turned out there is some regression in newer parted versions (3.4-2 is fine, while 3.5-1 and 3.6-1 are not), causing it to create the partitions that are disliked by GRUB (even "--skip-fs-probe" does not help! this doesn't seem a GRUB fault, because downgrading GRUB does not help). As a temporary fix, I have updated the instructions with

ERRATA: to avoid the grub-install: error: unknown filesystem - please downgrade the parted utility from 3.6-1 to 3.4-2 before making the partitions

pacman -U "https://archive.artixlinux.org/packages/p/parted/parted-3.4-2-x86_64.pkg.tar.zst"

Luckily, everything else is working fine  :) A bit later I will investigate this issue further: either there is some new command line option that has to be added to new parted to force a desired behavior, or maybe there is a parted but that has to be reported upstream. As for now, everyone has to either use the parted 3.4-2 or the alternative disk partitioning utilities like fdisk  ???

@qmastery , I've tried going through the installation with disk encryption [case A], using gdisk and fdisk several times (I'm using GPT) and it never seems to work at the GRUB install stage. It keeps giving me the "grub-install: error: unknown filesystem". I'm not sure how to modify parted if I'm using GPT either. I even tried following the Void Linux documentation for FDE (with some modification) with no luck. FDE works fine when I'm installing Void Linux, just not on Artix for some reason. I really want it to work on my Artix install.

Just really confused. I feel like it should work fine regardless of what distro you're using. I feel like there's some sort of weird bug in the GRUB package that's causing it to not recognize my filesystems.

>error: no such cryptodisk found, perhaps a needed disk or cryptodisk module is not loaded
>error: 'lvmid/<UUID>/<UUID>/<UUID>' not found.
>Entering rescue mode...

the error message I get after entering my password on boot. It then prompts to a grub rescue shell.
Anyone got any idea what this module could refer to and/or why grub can't seem to read/load the disk?

EDIT: I forgot to specify --type luks1 so I will give that a shot tomorrow
(https://files.catbox.moe/gx4bmu.jpg)

EDIT: --type luks1 didn't solve it. However, I wonder if the calamares installer is absolutely necessary. And I am confused about the rc-update command. Does this mean that this installation guide only works for systems employing OpenRC? This whole time I was installing for dinit... maybe at the start of the guide it should warn the user that it would only work if you use OpenRC?

@budman5 , maybe your adaptation of commands for GPT partition table was slightly wrong - I suggest you to try installing again using MBR (you may have to switch your UEFI into a Legacy/CSM mode) and see if it works for you. IMHO, old trusty MBR is much easier to work with than a GPT (i.e. to repair it when the things go wrong), so I recommend going for MBR even for the UEFI systems (personally I'm using a coreboot+SeaBIOS so there's no such dilemma)

By the way, my FDE manual contains ERRATA command (see "Disk partitioning" section) that helps to downgrade a "parted" package - to ensure that the partitions created with it are recognized by GRUB. Although during the recent test with a weekly Artix ISO it turned out that this downgrade is not needed anymore (maybe some GRUB bug got fixed, since there haven't been any updates to parted) - but I'm still keeping this command for compatibility purposes

@houtje , it looks like you made some error during the GRUB configuration; please try to repeat the instruction and if the problem repeats - share the exact sequence of commands as well as your final GRUB config (without any personal info, of course - i.e. may have to replace the UUID with something custom). This way it will be much easier for me to spot an error and help you Indeed: a Calamares is problematic sometimes, i.e. recently I had to insert a new ERRATA to fix its refusal to install into the LVM partitions, but still it does some work which otherwise would've had to be manual. Of course if it eventually breaks, I will seek the alternative installation methods, but it still works for now Although I wrote this guide with OpenRC in mind, it should work for dinit/runit/s6 if you look up the another-init command equivalents for the very few OpenRC commands that are being used. Maybe later I will add these equivalents to the relevant places of this manual if it could be done without bringing confusion (since there are already [CaseA]/[CaseB] I'm a bit hesitant to be honest).

I added this clarification note to a guide's header and encourage you to try again regardless of your init system choice: if it fails again, share your command sequence / GRUB config so that we could debug this together  ;)

Hello,


First, thank you for your adaptation of this guide and maintaining it.
I installed Artix on a new computer these last few days (I first spent hours deciding of my setup, then tried several configurations, and ran into a few problems, it probably was my most complicated installation since a long time).
I read your guide and mixed it with another one, a wiki and random threads more up-to-date on certain aspects (mainly EFI, also different encryption models) as well as reading what each step was doing and why do it this way.
I have a second disk with two partitions mounting on /home/backup and /home/data. Also my SSD are identified as nvmeXn1 and partitions as nvmeXn1pY. I will do as if I only have one drive and simulate /dev/sdaX to shorten the syntax.
I have a Meteor Lake CPU, 2 SSD, wanted Xfce as a desktop environment and LightDM as a login manager. The other software is not relevant to this comment.

I tried to write some complementary remarks, approximately in the same order than the guide. Good luck with it, I am often quite confused when writing and even more in English.


You could use GPT as a partition table instead of MBR, it might especially be useful on computers with UEFI, but is also supported with BIOS. I will try to remember of the different changes it needs and also write them in the guide order.
The first change is that with GPT, the first option of mklabel is not primary/logical anymore, but the disk label; this means that the example linked on rohlix.eu set “primary” as the labels to his partitions. Also, fat32 could (should?) then be used for the ESP partition with mklabel, and must be reused with mkfs.fat (as showed Artix main installation guide).
I am not sure about the lvm flag when using LVM on LUKS. I set it when I installed the other way around (LUKS on LVM) before reinstalling because it was harder to get what I wanted (except the graphics which instantly worked…), now it works without the lvm flag but would probably also work with.

parted /dev/sdX mklabel gpt
parted -a optimal /dev/sdX mkpart "boot" "ext4" "1MiB" "1025MiB"
parted -a optimal /dev/sdX mkpart "bootefi" "fat32" "1025MiB" "2049MiB"
parted -a optimal /dev/sdX mkpart "main" "ext4" "2049MiB" "100%"
parted /dev/sdX set 2 esp on
mkfs.fat -F 32 /dev/sdX2

Note that FAT32 can be used with /boot partition, it may even be better for multi-environment booting.

LUKS2 (default) has been OK for the last few years, so it better to use (more secure, I believe that the key is copied at several places in case some get corrupted).
Even when you want to encrypt /boot, you can keep luks2 with GRUB (not with other boot loaders), but need to use --pbkdf pbkdf2. The --hash sha512 is still a good option. I did not try the Serpent cipher; it is slower, so is probably marginally more secure because the attacker would not have the instruction set, but neither do you so it probably is slower at execution.
My command was just:

cryptsetup --verbose --hash sha512 --verify-passphrase luksFormat /dev/sdX3

After setting the last logical volume on a volume group containing at least one ext4 partition, you can reduce one of the logical volume of at least 256MiB with

lvreduce -L -256M lvmSystem/volhome

(for example). It lets e2scrub run to check the filesystem metadata.
Not sure if contiguous is needed or even better with SSD.

I ran fstabgen, but only to look for the mount options it suggested and compared them with what Calamares set and what I have on my current computer.
I often read that periodic TRIM is better for SSD longevity than discard option. Also you should add noatime (it can break some software like mutt) or at least relatime to decrease the writes. I have not tried lazytime which was introduced a few years ago (but is seems useless with noatime which I set).
root password should have been set by Calamares installer and setting it up was not needed in my case.
The keyboard hook might need to be placed before autodetect when using an external keyboard on a laptop (the only minor drawback is that placing hooks before autodetect slightly enlarge the initramfs produced).
When using a non-QWERTY layout, it is also better to place keymap and consolefont before encrypt and set the correct layout in /etc/vconsole.conf.

HOOKS=(base udev keyboard autodetect microcode modconf kms keymap consolefont block lvm2 encrypt filesystems fsck)

I am not sure about what the net.ifnames=0 kernel parameter does. I have this parameter on my current computer, it keeps the interfaces names the old way (ethX, wlanY…). I tried without it this time until I understand what the implications are.
GRUB_ENABLE_CRYPTODISK=y is only needed when /boot is encrypted.
You can add the parameter root=/dev/lvmSystem/volRoot to the kernel parameters line. It is not needed when generating grub.cfg with grub-mkconfig, but as adding the device seems to be advised in most of the documentation I found, I believe it is better as fallback functioning. With my configuration, with /boot and /boot/efi separated, the line looked like:

grub-install --target=x86_64-efi --esp-directory=/boot/efi --boot-directory=/boot --bootloader-id=artix --recheck

With UEFI, the first parameter should be changed to --target=x86_64-efi, another parameter --esp-directory=/boot/efi added (or /boot or /efi, as the person wants it¹), and no device path at the end.
Important: also with UEFI, install efibootmgr at the same time than grub or at least before launching grub-install, otherwise it shows errors and probably does not work.

Still with an UEFI computer, with root and other partitions encrypted, but an unencrypted /boot, the cleanest way I partitionned my disk was with: a partition for root /, another one for /home (this is quite a must), one for swap, and I also set a specific partition for /var but that is less useful (and a last one for /opt which will be useless, we will no longer care about it), all of them on the LVM volume group.
I also set up /boot and /boot/efi separated, so I can encrypt /boot if I want one day. I did not encrypt /boot, as it is slower to boot, and you either need to enter two passwords (the one for /boot and the one for root), or let a root keyfile in the encrypted boot partition. However, the /boot partition can not have Argon2 KDF, so letting the keyfile of a more secure partition in /boot would downgrade its security to the weakest link of the chain.
My partition scheme is (without the quite-useless stuff):
/dev/sda        with GPT partition table
  /dev/sda1                                        /boot               ext4 or fat32
  /dev/sda2     esp flag                     /boot/efi        fat32
  /dev/sda3     encrypted with LUKS and partitioned into a LVM container
    /dev/mapper/lvmsys (second SSD is lvmdata, but whatever)
      /dev/MyVolGroup/volroot         /                       ext4
      /dev/MyVolGroup/volvar          /var                  ext4
      /dev/MyVolGroup/volswap      [SWAP]
      /dev/MyVolGroup/volhome     /home              ext4

/dev/mapper/lvmsys as the LVM physical volume.
MyVolGroup as the volume group.
The logical volumes of this VG are: volroot (32 GB), volvar (16 GB), volswap (normally RAM size, but I gave it half, I will see if it can suspend) and volhome (the rest minus 1 GB for
e2scrub).

I used ext4 for all of the volumes (except the one where the ESP is). It never failed me, should do great with periodic TRIM (and noatime or at least relatime mount option in fstab). I thought about using Btrfs, especially for its compression feature; but I believe that Btrfs loses a bit of its usefulness with LVM already on top which can do (block) snapshots and resize quite easily.

I had a blank screen problem after installing xfce4 and LightDM; only the tty were working. It turned out that I needed to remove xf86-intel-driver and install intel-media-driver.

As I mentioned, I first tried to install LUKS on LVM and maybe can complement another guide if you would like to.
It was much more complex, I had less experience, and I had to mix two or three different guides to get what I wanted (basically the one from ArchWiki and the Artix one). It made sense, as I have two SSD and thought a volume group with two physical volumes (/boot excluded) so I had a huge 1.8 TB /home would be the cleanest scheme.
However, Calamares always failed (the pacman commands) so I installed the system manually with pacstrap. I may had not correctly installed GRUB (or maybe I did it correctly) and had to enter my LUKS password before GRUB in QWERTY and after GRUB in QWERTY, with a minor non-blocking error appearing after GRUB. Only the root volume automounted after that, all the other volumes had to be manually mounted even with crypttab configured and keyfiles working when doing it manually. What was strange is that I had less problems to get the display and login working, I installed xfce4 and LightDM and that was it, no need to remove and add other drivers.
All in all, it is probably best this way, because if one SSD failed, the whole volume group would have failed and all data be inaccessible.
Still it was interesting, and as bad as I am in Linux administration, if you want some information in order to write a guide, I can try to remember.


¹ Setting the EFI directory directly in /boot is the easiest way as you can follow the same commands as with MBR. Setting it in /efi seems to be popular with Arch as some systemd programs
default to it. Finally, /boot/efi probably is a clean way to do it, as you can make the special ESP partition for it separated from an encrpyted /boot, so you could still dual-boot without
problem if you need. Setting it in a separated /efi would also work for dual-booting, but it does not look as logical to me.

I do have the same problem and not being able to pinpoint the actual issue: https://forum.artixlinux.org/index.php/topic,7209.msg43691.html

I don't think it's a coincidence, there must be a step not mentioned in the guide that might not be necessary under some conditions and installations, but prevents from booting in others.