Hello,
I just found out that OpenMandriva LX (Rome and also Rock, desktop and arch. irrelevant).
Can not be installed with luks2 since Calamares will install it only with LUKS1 (if you select to encrypt ext4 partition) which is no longer very secure. If you choose LUKS 2 in Calamares it will not ask you for volume password or filesystem type under it and install will fail with error.
Is there any way to install OpenMandriva on LUKS2 partition (preferably also with SHA512 hash) (of course i understand I need to have one unencrypted /boot partition…) ?
So far I tried pre-creating partitions and then running Calamares and setting just mount points, but I had no luck.
If you can help me I would be very glad since this is my only stumbling block with OpenMandriva.
I also noted that other distros using Calamares do not have this problem so perhaps problem just lies in Calamares configuration in OpenMandriva ???
EDIT: They (other distros) also encrypt with LUKS2 by default.
Thanks
3 Likes
Welcome!
I don’t use LUKS, so I have no experience with this one, but we are glad to see you.
rugyada
(rugyada)
February 1, 2025, 10:50pm
3
1 Like
No, I already tried this. As I mentioned Calamares simply cannot install on existing LUKS partition (wont even ask for password, and if it is unlocked only pretends to install on it but nothing is written and fails).
1 Like
It appears something similar was reported but the person that reported it opted not to follow up with calamares about any upstream issues:
opened 05:32PM - 09 Jan 25 UTC
closed 03:31PM - 25 Jan 25 UTC
ROME/rolling
new
needinfo
Hey, Lunduke viewer here! 🤗
Wanted to install under VMware Fusion on Apple S… ilicon. While there seem to be aarch64 packages around, I couldn't find a (UEFI) installer. So I went for a Proxmox VM on x86_64.
**OpenMandriva version**:
`OpenMandrivaLx.rolling-snapshot.20241225.3522-plasma6x11.x86_64.iso`
**Describe the bug**:
<img width="263" alt="Screenshot 2025-01-09 at 18 10 31" src="https://github.com/user-attachments/assets/6e2492b6-6cc3-4874-9660-c93e09d6359d" />
**Steps to reproduce**:
Decided to try out disk encryption with btrfs. Install went fine until the very end, see screenshot.
**Observed behavior**:
I thought, ok, maybe that's a bit too wild, let's try with ext4. Started the installer again, but it only offered to manually partition the (now already initialised) disk. I didn't find an option to apply the default layout. Quickly zeroed the headers in the shell, good to go. Same result.
Again, `dd`, maybe disk encryption is broken right now? Leave it off, try btrfs again. Same grub error.
**Expected behavior**:
Last attempt, no encryption, plain old ext4: Works as expected!
Just felt like sharing, feel free to close anytime. 👍🏻
I know we are addressing issues with LUKS 1 and it may be evaluated at that time to investigate LUKS 2.
1 Like
So, here is what I could find from the upstream that will hopefully shed some light on things:
opened 07:23AM - 21 Apr 23 UTC
I followed this guide to setup LUKS2 for Calamares on Debian Bookworm: https://g… ithub.com/calamares/calamares/wiki/Deploy-LUKS
Calamares built from source (21-04-2023).
Configuration files:
[modules_conf.zip](https://github.com/calamares/calamares/files/11293243/modules_conf.zip)
Version info:
```
$ apt policy grub-efi-amd64 cryptsetup
grub-efi-amd64:
Installed: 2.06-8
Candidate: 2.06-8
Version table:
*** 2.06-8 500
500 http://deb.debian.org/debian testing/main amd64 Packages
500 file:/run/live/medium testing/main amd64 Packages
100 /var/lib/dpkg/status
cryptsetup:
Installed: 2:2.6.1-3~deb12u1
Candidate: 2:2.6.1-3~deb12u1
Version table:
*** 2:2.6.1-3~deb12u1 500
500 http://deb.debian.org/debian testing/main amd64 Packages
500 file:/run/live/medium testing/main amd64 Packages
100 /var/lib/dpkg/status
```
**Automatic partitioning (erase):**
300M: /boot/efi: FAT32
10G: /: LUKS2
100%: /home: LUKS2
```
Starting job "bootloader" ( 39 / 41 )
2023-04-21 - 06:20:10 [6]: virtual Calamares::JobResult Calamares::PythonJob::exec()
Job file "/usr/lib/x86_64-linux-gnu/calamares/modules/bootloader/main.py"
2023-04-21 - 06:20:10 [6]: [PYTHON JOB]: Found gettext "en_US" in "/usr/share/locale/en_US"
2023-04-21 - 06:20:10 [6]: .. Job description from pretty_name "bootloader" = "Install bootloader."
2023-04-21 - 06:20:10 [6]: [PYTHON JOB]: "Bootloader: grub (efi)"
2023-04-21 - 06:20:10 [6]: .. Running ("grub-install", "--target=x86_64-efi", "--efi-directory=/boot/efi", "--bootloader-id=debian", "--force")
2023-04-21 - 06:20:11 [6]: .. Target cmd: ("grub-install", "--target=x86_64-efi", "--efi-directory=/boot/efi", "--bootloader-id=debian", "--force") Exit code: 1 output:
Installing for x86_64-efi platform.
grub-install: error: cannot find a device for /boot/grub (is /dev mounted?).
```
Creating a /boot partition for automatic partitioning results in a encrypted /boot partition and the same error as above.
**Manual partitioning:**
300M: /boot/efi: FAT32
300M: /boot: EXT4
10G: /: LUKS2
100%: /home: LUKS2
Boot partition not encrypted warning is shown. In this case (there currently no alternative) the warning should not be shown.
```
Starting job "bootloader" ( 40 / 42 )
2023-04-21 - 06:49:13 [6]: virtual Calamares::JobResult Calamares::PythonJob::exec()
Job file "/usr/lib/x86_64-linux-gnu/calamares/modules/bootloader/main.py"
2023-04-21 - 06:49:13 [6]: [PYTHON JOB]: Found gettext "en_US" in "/usr/share/locale/en_US"
2023-04-21 - 06:49:13 [6]: .. Job description from pretty_name "bootloader" = "Install bootloader."
2023-04-21 - 06:49:13 [6]: [PYTHON JOB]: "Bootloader: grub (efi)"
2023-04-21 - 06:49:13 [6]: .. Running ("grub-install", "--target=x86_64-efi", "--efi-directory=/boot/efi", "--bootloader-id=debian", "--force")
2023-04-21 - 06:49:14 [6]: .. Finished. Exit code: 0 output:
Installing for x86_64-efi platform.
Installation finished. No error reported.
2023-04-21 - 06:49:14 [6]: [PYTHON JOB]: "UEFI Fallback: True"
2023-04-21 - 06:49:14 [6]: [PYTHON JOB]: " .. installing 'bootx64.efi' fallback firmware"
2023-04-21 - 06:49:14 [6]: .. Running ("grub-mkconfig", "-o", "/boot/grub/grub.cfg")
2023-04-21 - 06:49:14 [6]: .. Target cmd: ("grub-mkconfig", "-o", "/boot/grub/grub.cfg") Exit code: 1 output:
/usr/sbin/grub-probe: error: cannot find a device for / (is /dev mounted?).
2023-04-21 - 06:49:14 [2]: WARNING: [PYTHON JOB]: "Command 'grub-mkconfig -o /boot/grub/grub.cfg' returned non-zero exit status 1."
2023-04-21 - 06:49:14 [6]: [PYTHON JOB]: "stdout:/usr/sbin/grub-probe: error: cannot find a device for / (is /dev mounted?)."
2023-04-21 - 06:49:14 [6]: [PYTHON JOB]: "stderr:None"
```
As I understand, Grub2 does not support LUKS2. You will need an unencrypted /boot partition. However, automatic partitioning does not create an unencrypted /boot partition when using LUKS2 for encryption. Manual partitioning should work, but crashes on grub-probe.
It appears despite the announcement in 2020 that GNU had these patches they may not have been merged, or the calamares project just isn’t good about closing issues. It only appears that the Nix project chimed in with support by default for LUKS 2. Given that uncertainty I could see how a managerial decision to use LUKS 2 might have been avoided. There were other points made in the Issue that may be of value.
There are several other LUKS issues that could also be perused:
If there is a possibility that this form of encryption is not supported at this time, then it may not be considered. I realize there are probably many other distros using this type of encryption, but we would need people to step up and test this. If you would be willing to do that, then it might be more of a possibility.
Okay, this was why we avoided it:
opened 10:26AM - 24 Feb 19 UTC
closed 04:49PM - 20 Nov 22 UTC
bug: downstream
**Describe the bug**
Currently you will hit issues when **cryptsetup 2.1** is n… ot set to use **luks1** still as default. **grub** and other bootloaders still relay on **luks1** for now.
**To Reproduce**
Steps to reproduce the behavior:
1. Use an install media like **Manjaro 18.0.3** and try to install with encryption
2. You will land in a rescue shell as **grub** don't support **luks2** for `/boot`
**Expected behavior**
When **cryptsetup 2.1** is detected, we have to use `--type luks1` to explicitly use **luks1** for `/boot` encryption until **grub** might adopt **luks2** support.
**Screenshots and Logs**

**Additional context**
See also [release notes](https://gitlab.com/cryptsetup/cryptsetup/blob/master/docs/v2.1.0-ReleaseNotes) from **cryptsetup**.
1 Like
But it is important to note that:
Grub is not a problem if you use un-encrypted /boot and /boot/efi partition and then you can LUKS2 encrypt rest of / without problems with grub.
It works this way on Ubuntu without problems.
1 Like
Okay. If there is a way to enable it without tying it to the boot loader we will investigate configuring that. Would you be willing to test it?
We don’t do things the way Ubuntu does them so it’s not really a valid comparison.
You are a official developer of OpenMandriva ??? Where is your badge ?
So, no. You are not willing to test it.
1 Like
He is, but doesn’t wear a badge.
I am willing to test it , but you should stop pretending to be a OF. developer
I am willing to test it , but you should stop pretending to be a OF. developer
Sure thing potatus
2 Likes
You can keep track of the progress here:
opened 12:10AM - 02 Feb 25 UTC
enhancement
new
From the forum:
https://forum.openmandriva.org/t/installing-openmandriva-on-luk… s2/6252/15
The following default configuration is provide for encrypted partitioning:
https://github.com/calamares/calamares/blob/babaddffc39fa1a423c4f9714e8cf972f18d2af6/src/modules/partition/partition.conf#L90-L102
Investigate if this can be enabled without creating a breaking scenario with the bootloader (`grub2`).
2 Likes
DMoRiaM
February 3, 2025, 12:15am
17
I will pay attention and test it to as I need LUKS on my main notebook!
Thanks in advance for the good work!
1 Like