Installation in virtualbox in luks encrypted partitions failed

Tags: #<Tag:0x00007fc0bdd284a0> #<Tag:0x00007fc0bdd28360> #<Tag:0x00007fc0bdd28220>

Hello,

  • _OpenMandriva Lx version:_4.0

  • Desktop environment (KDE, LXQT…): KDE

  • Description of the issue (screenshots if relevant):
    I tryed to install OpenMandrivaLX 4.0 in a Virtualbox using a luks encrypted swap partition and a luks encrypted root partition.
    Here is the summary displayed before the start of the installation:

  • Summary:

  • Location:
    Set timezone to Europe/Brussels
    The system language will be set to American English (United States).
    The numbers and dates locale will be set to
    American English (United States).

  • Keyboard:
    Set keyboard model to Generic 105-key PC (Intl.) – Default Keyboard Model
    Set keyboard layout to English (US) Default

  • Partitions:
    Manual partitioning on disk /dev/sd a (VBOX HARDDISK)
    New partition 8.6 GiB Luks
    Openmandriva 5 5 . 4 GiB Luks
    Create new MSDOS partition table on /dev/sd a (VBOX HARDDISK)
    Create new 88 00MB partition on /dev/sd a (VBOX HARDDISK) with file system luks
    Flag 8800MB luks partition as swap
    Create new 5 67 29 MB partition on /dev/sd a (VBOX HARDDISK) with file system luks
    Flag 56729 MB luks partition as root
    Install OpenMandriva Lx on new ext4 system partition.
    Install boot loader on /dev/sd a

  • Install

The installation starts but aborts after a very short time with the message:

Installation Failed
The installer failed to create partition on disk 'VBOX HARDDISK'.
Create a new partition (55.40 GiB, luks) on '/dev/sda'
Job: Create new partition on device '/dev/sda'
Command: sfdisk --force --append /dev/sda
Job: Create file system 'luks' on partition '/dev/sda2'
Command: cryptsetup -s 512 --batch-mode --force-password --type luks 1 luksFormat /dev
sda2

Is this a known problem and can it be fixed?
Regards,
Albert

I’m trying to stick to what I know here. So first I have no personal experience with Luks.

This issue is not a known issue. Install with Luks file system would not be well tested in OM Lx 4.0 development if it was tested at all. There is nothing intentional about the lack of testing, this is just a consequence of using the few resources we have the best we can.

Most install testing during development was either EFI or Legacy boot primarily with ext4 but also some f2fs, btrfs, and xfs file system installs.

I’m hoping we can get a developer to tell us if Luks is really supported or not.

I can confirm what you found in screen shots and I have the Calamares installer log if this turns out to be an issue we can get developers to work on.

This is the Konsole out put of ‘pkexec calamares -d’ of the above failed install attempt:
VBox-luks.txt (32.5 KB)

I do not see a separate partition /boot, not encrypted. Without it the installation would fail anyway.

I would now try to set up the partitioning in command line from the live system. Can Calamares handle that?

Best regards,
Bequimão

Hello,
@Ben79: Thanks for verifying my problem.
@Bequimao : In OpenMandrivaLx3.03 calamares can handle this setup (without a separate non encrypted /boot partition).
I also remember that OpenMandrivaLx3.03 couldn’t do it at the beginning of the release, it took some time to get it running.
Regards,
Albert

luks version 1 is only implemented in calamares ,
you have to go in luks2 , but calamares has not switched and check all ( regression )

also needed grub2 with luks2

manjaro still have trouble with luks version , from archlinux luks2 only , but you cant reuse luks1 from calamares

https://forum.manjaro.org/search?q=luks2%20

Hello Stephane,
I’m afraid, I don’t fully understand your answer.
Quick questions:
Is it possible to fix this problem or do we have to wait until other tools are updated?
Is there a manual procedure to go around this problem?
Regards,
Albert

Boot partition is not needed for MSDOS partition table.
For @vhelmont’s install:

For my test:
Check again 1st screen shot. Where is says “flag 300MB fat32 partition as boot”

Thanks @Bequimao you may have pointed to a work around. You can certainly create a partition as you want before running Calamares and then when you get to partitioner select to “keep” it instead of “format”. I have not tried this with luks encrypted partition myself.

:monkey_face:

calamares come with luks1 , or
in manjaro case , Archlinux go to luks2 without warning ,

need calamares , files config , grub2 complete for that working
the search provides all terms to get in any topic about

@stephane thanks for the imformation link. The more I read about luks the more it seems like support is discombobulated. Post-edit: Or it could be considered higgledy-piggledy.

  1. I don’t think it matters if Calamares comes with luks1 if it does not work. If it did work there would be nothing wrong with using luks1. It is not necessary to use the latest version of something. Sometimes users are better off not using latest version of some things.

  2. OM’s Calamares partitioner page has a check box for encryption. That uses luks or is supposed to. So that should either work or it should be removed.

  3. Something that worked in OM implementation of Calamares last time I tested it (maybe 6 or more months ago) now does not work. I’m going on memory in this statement as I have nothing written down about luks installation. But this did work at one time.

(I doubt luks or encrypted partitions are a major focus of OM developers at this time.)

:speak_no_evil: :hear_no_evil: :see_no_evil:

Hello Bequimao,

If I understand you correctly, you would set up an luks encrypted partition for swap and a luks encrypted partition for root via the command line.
Then you would start the mandriva installer and install the 4.0 system in the earlier created encrypted partitions.
Questions:
When you are in the Mandriva installer, how will you unlock the encrypted partitions before the start of the install operation?
Did you already tried this work around and is it possible to share this procedure with me. I would like to learn how this can be done?

Regards,
Albert

Hi ben79,

I tested Calamares some years ago with KAOS Linux. LVM or encryption was not supported then. I knew about full encrypting (including /boot) from the Arch Wiki, but that was above my paygrade then.

This issue needs someone that knows more about this than I do.

Hi Albert,

I tested now on real hardware, not in a VM. The reason is, if something fails, I can chroot into the root filesystem and try repairs.

[root@localhost ~]# vgs
File descriptor 24 (socket:[48013]) leaked on vgs invocation. Parent PID 1893: -bash
File descriptor 32 (socket:[47978]) leaked on vgs invocation. Parent PID 1893: -bash
File descriptor 34 (socket:[49902]) leaked on vgs invocation. Parent PID 1893: -bash
  VG  #PV #LV #SN Attr   VSize    VFree   
  vg1   3  10   0 wz--n- <449.99g <117.99g
[root@localhost ~]# 
[root@localhost ~]# lvcreate -n mlvm15 -L 20G vg1
File descriptor 24 (socket:[48013]) leaked on lvcreate invocation. Parent PID 1893: -bash
File descriptor 32 (socket:[47978]) leaked on lvcreate invocation. Parent PID 1893: -bash
File descriptor 34 (socket:[49902]) leaked on lvcreate invocation. Parent PID 1893: -bash
  Logical volume "mlvm15" created.
[root@localhost ~]# 
[root@localhost ~]# lvcreate -n swap1 -L 8G vg1          
File descriptor 24 (socket:[48013]) leaked on lvcreate invocation. Parent PID 1893: -bash
File descriptor 32 (socket:[47978]) leaked on lvcreate invocation. Parent PID 1893: -bash
File descriptor 34 (socket:[49902]) leaked on lvcreate invocation. Parent PID 1893: -bash
  Logical volume "swap1" created.
[root@localhost ~]# 
[root@localhost ~]# cryptsetup -c aes-xts-plain64:sha256 -y -s 512 luksFormat /dev/mapper/vg1-mlvm15

WARNING!
========
This will overwrite data on /dev/mapper/vg1-mlvm15 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter passphrase for /dev/mapper/vg1-mlvm15: 
Verify passphrase: 
[root@localhost ~]# cryptsetup open /dev/mapper/vg1-mlvm15 crypt_mlvm15
Enter passphrase for /dev/mapper/vg1-mlvm15: 
[root@localhost ~]# cryptsetup status /dev/mapper/crypt_mlvm15
/dev/mapper/crypt_mlvm15 is active.
  type:    LUKS1
  cipher:  aes-xts-plain64:sha256
  keysize: 512 bits
  key location: dm-crypt
  device:  /dev/mapper/vg1-mlvm15
  sector size:  512
  offset:  4096 sectors
  size:    41938944 sectors
  mode:    read/write
[root@localhost ~]# 
[root@localhost ~]# cryptsetup -c aes-xts-plain64:sha256 -y -s 512 luksFormat /dev/mapper/vg1-swap1

WARNING!
========
This will overwrite data on /dev/mapper/vg1-swap1 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter passphrase for /dev/mapper/vg1-swap1: 
Verify passphrase: 
[root@localhost ~]# 

[root@linux ~]# blkid | grep LUKS
/dev/sda7: UUID="31c59654-5d8f-42e1-b58f-8295fe102654" TYPE="crypto_LUKS" PARTLABEL="primary" PARTUUID="25bfae0a-2adf-4196-ad8f-2e86b3116391"
/dev/mapper/vg1-mlvm15: UUID="bb4042d1-0036-4e2a-8a8b-b93ce4c313f9" TYPE="crypto_LUKS"
/dev/mapper/vg1-swap1: UUID="53e36aa8-c76f-4988-87a5-101506c875a8" TYPE="crypto_LUKS"
[root@linux ~]# 
[root@linux ~]# cryptsetup open /dev/mapper/vg1-swap1 crypt_swap1
Enter passphrase for /dev/mapper/vg1-swap1: 
[root@linux ~]# 
[root@linux ~]# mkfs.xfs /dev/mapper/crypt_mlvm15
meta-data=/dev/mapper/crypt_mlvm15 isize=512    agcount=4, agsize=1310592 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=0
data     =                       bsize=4096   blocks=5242368, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
[root@linux ~]# 
[root@linux ~]# mkswap /dev/mapper/crypt_swap1
Setting up swapspace version 1, size = 8 GiB (8587833344 bytes)
no label, UUID=0a3eaa23-fc10-4f22-9db3-9f0631b7fac9
[root@linux ~]# 

You see that the default format is still LUKS1, and that should be accepted by Calamares.

Reference: Verschlüsseltes System mit LUKS/dm-crypt und LVM aufsetzen – Siduction Wiki DE

I chose a setup with explicit /boot. The cryptsetup devices where recognized and kept. The installation started and failed after some time with a different error message unlike Ben’s test.

Something like: rsync error, failed to copy /run/…/???.img

Unfortunatedly I failed to copy the screenshot to my hard drive.

The root partition is not filled

[root@mga7-upgr ~]# df -h /mnt
Filesystem                Size  Used Avail Use% Mounted on
/dev/mapper/crypt_mlvm15   20G   53M   20G   1% /mnt
[root@mga7-upgr ~]#

Best regards,
Bequimão

This is a known and reported upstream bug. [partition] auto partitioning with encryption and swap is broken · Issue #1163 · calamares/calamares · GitHub

@vhelmont so as it says in that bug report this will work if you install without swap. And swap is not normally needed nowadays though it may be needed for hibernate, but I don’t use hibernate myself.

Hello,
I tried to be clever by cloning an OpenMandrivaLx3.03 Virtualbox luks encrypted installation and install an OpenMandrivaLx4.0 system on top of it.
The OpenMandrivaLx4.0 installer recognized the luks partitions but there was no option to insert my luks key and open the partitions, so the installation failed.
Regards,
Albert

Hello ben79,

I can repeat your work around in BIOS mode and it boots.
I will continue testing it.

Regards,
Albert

1 Like