Small luks encrypted partition

In the early fall I received the evergreen L5. But there was a problem with it not mounting the aux sd memory card, so Purism told me to send it back in, and they just now sent me a replacement phone, with byzantium.

I installed just a few programs from the store, when I started getting messages from the device that I had only 250 MB of space left. I am no expert in any of this stuff, but I decided to open up the Disks program. I looked at the partioning of the drive. There is a luks partition of only 4GB, and it is almost full (only 250 MB left). Then, there is an “unallocated” partition of 27 MB that is empty. It looks to me that everything I’m doing, everything I’m installing, is being squeezed into just that 4 GB luks partition. And just wasting 27 GB that is sitting empty. So, I am horribly confused.

What is the logic behind Purism setting these partitions up this way?

How do I break my installed programs out of the 4 GB jail they are currently incarcerated in and let them have access to more GB of capacity?

Now that I’ve installed stuff, how do I make the entire disk be encrypted? Can’t I just have one, gigantic encrypted partition at this point?

See my confusion? Any explanatory help will be appreciated.

1 Like

You can follow the steps from the first post:
https://forums.puri.sm/t/tutorial-full-disk-encryption-on-librem5

Important for you is the part starting from cfdisk.
I executed the commands directly on my Librem5 (so without picocom)

I’m going away from my computer now (will not be able to respond right away) but please post here output of either: sudo fdisk --list or: sudo parted --list

Note: I believe that something went wrong during initial installation (expanding of second, encrypted partition didn’t happen) of PureOS.

purism@pureos:~$ sudo fdisk --list
[sudo] password for purism:
Disk /dev/mmcblk0: 29.12 GiB, 31268536320 bytes, 61071360 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x9e54d2e5

Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 * 10240 962559 952320 465M 83 Linux
/dev/mmcblk0p2 962560 8787967 7825408 3.7G 83 Linux

Disk /dev/sda: 29.72 GiB, 31914983424 bytes, 62333952 sectors
Disk model: Ultra HS-SD/MMC
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device Boot Start End Sectors Size Id Type
/dev/sda1 8192 62333951 62325760 29.7G c W95 FAT32 (LBA)

Disk /dev/mapper/crypt_root: 3.73 GiB, 4004511744 bytes, 7821312 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

purism@pureos:~$ sudo parted --list
Model: Generic Ultra HS-SD/MMC (scsi)
Disk /dev/sda: 31.9GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
1 4194kB 31.9GB 31.9GB primary fat32 lba

Model: Linux device-mapper (crypt) (dm)
Disk /dev/mapper/crypt_root: 4005MB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags:

Number Start End Size File system Flags
1 0.00B 4005MB 4005MB ext4

Model: MMC 032G32 (sd/mmc)
Disk /dev/mmcblk0: 31.3GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
1 5243kB 493MB 488MB primary ext2 boot
2 493MB 4499MB 4007MB primary

Error: /dev/mmcblk0boot0: unrecognised disk label
Model: Generic SD/MMC Storage Card (sd/mmc)
Disk /dev/mmcblk0boot0: 4194kB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:

Error: /dev/mmcblk0boot1: unrecognised disk label
Model: Generic SD/MMC Storage Card (sd/mmc)
Disk /dev/mmcblk0boot1: 4194kB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:

Three questions:

  1. Those instructions include this: “This method doesn’t offer the opportunity to regenerate the encryption keys (luks type1 doesn’t allow for reencryption of online partitions). Remember --> encryption key encryption passphrase. Meaning is - not secure as it should-, its meant for testing.” That leaves me feeling like this isn’t really what I wish to accomplish.

  2. What will following those instructions do to all the programs and data I have already installed?

  3. Does that process enlarge the partition, or both the partition and the underlying filesystem?

I’m back (not really) and think that none really interested what happened and why happened during initial setup of PureOS Byzantium on your Librem 5 therefore let us say it was just some kind of coincidence. Most importantly your internal eMMC is of usual size = 29.12 GiB:

Recognizing that second partition is the problematic one (should read 28.7G instead of 3.7G):

But everything on /dev/mmcblk0 as exists there now (partition table) needs (perhaps) to be removed, meaning my advice is to do same homework (prepare yourself) and install PureOS Byzantium by yourself there (really own your device from very initial step).

P.S. As said please don’t be angry at anyone, neither myself or yourself as it is matter of coincidence up to your advantage and indeed good starting point to learn how to (re)install PureOS from scratch to your Librem 5 (something that I think is the best way out from there where you are now, my only advice I have for you). Another advice of mine would be to remove, as present there, microSD (/dev/sda) card during initial setup of PureOS.

Edit: @dln949, before you meet any decision on how to proceed perhaps you’d like to read informatively this document: https://help.ubuntu.com/community/ResizeEncryptedPartitions.

@Quarnero, thank you for the reply.

I’m struggling to understand your recommendation. Are you saying I should reinstall (flash?) the OS? Or are you saying I should attempt to resize the partitions?

If you’re suggesting I reinstall the OS… How do I find the most current instructions for that? (I know I can search online and find all kinds of versions of how to do that, but I am not technical enough to know if I’m looking at the most current, officially recommended version of the instruction, because I know they change, but web pages leave the old versions lying around online. Example of what I mean: At this site, https://developer.puri.sm/Librem5/Development_Environment/Phone/Troubleshooting/Reflashing_the_Phone.html , it says this: “By default, the script will assume it’s flashing Evergreen; however, you can pass in the different version to the --board option. Use librem5r2 for Birch and Chestnut series.” Well, besides not having any clue what they mean by the “–board option”, it appears these instructions will not work to flash Byzantium.)

If you’re suggesting I resize the partitions… I read through the link you sent, I do not have enough confidence in my computer knowledge to plow through something like that.

Not angry at you at all, I am grateful for people like you willing to help. But I am not happy with purism: I thought i paid to receive a device with some basic stuff correctly installed. Especially after I had sent it in for them to fix a problem (at their request). And this is what worries me the most: If they - Purism, the experts - have trouble installing things correctly, I’m very worried that a layman like myself doesn’t stand much of a chance of doing better.

1 Like

Please read/follow this post:

P.S. Not helping you much at this point of time (just tired now), but still repeating in which direction you should go.

EDIT: You’ll find under same post (try this at first place):

You are allowed to flash only librem5r4-flash-image, the Evergreen one:

It appears that your phone has been flashed with an image file of Byzantium w/ LUKS encyption, but, for what ever reason the LUKS partition has not been resized to fill the entire disk after flashing.

There are a couple of ways to resize, if you are familiar with fdisk I would use that as it has the advantage of being able to work on live disks so no reboot would be required. Perhaps the easiest option is to use sfdisk from a root shell, the process is as follows…

  1. From the terminal, get to a root shell by entering…
    sudo -i

  2. Resize the main partition to fill the entire disk space…
    echo ,+ | sfdisk --no-reread --no-tell-kernel /dev/mmcblk0 -N 2

  3. Remove the “filesystem resized marker file”…
    rm /etc/resize_rootfs-resized

  4. Exit from root shell…
    exit

  5. Reboot phone

Notes:

  • sudo -i will prompt for your password.

  • sfdisk will resize/enlarge the partition by changing the “End” sector value, after executing the command you will be shown the old partition table and the new partition table, the only difference between old and new you should see will be in the “End”, “Sectors” and “Size” values of the second partition. If anything doesn’t look right within the partition table then it will most likely need to be addressed before rebooting.

  • If after executing rm it errors with “No such file” or similar then you will have to manually resize the LUKS container with sudo cryptsetup resize /dev/mapper/crypt_root and resize the main filesystem with sudo resize2fs /dev/mapper/crypt_root which, if required, should be done after rebooting.

For your three questions:

  1. Your phone has been flashed with an image, it may have been re-encrypted at the factory, see the issue Change encryption key before flashing for more information. You would need to contact Purism and ask if that was done or not. It is probably best to assume not.

  2. The instructions just resize to enlarge the partition, no programs or data you have installed should be lost but there is always an element of risk, so take backups of anything important.

  3. The process enlarges the partition, the LUKS container and the underlying filesystem.

2 Likes

@Loki, thank you very much for these clear instructions. Just a few followup questions:

  1. When you show the cryptsetup and resize2fs commands to resize the LUKS container in case there is the No such file error, you are saying that BOTH those commands are to be done after rebooting, right?

  2. By following this process, and if all goes well, at the end I will have an enlarged luks encrypted partition, correct?

  3. Will the enlarged luks encrypted partition have the same encryption passphrase that I set up for it? Or will it revert back to the default 123456?

  4. I’m sorry, I’m not understanding what the potential issue is with the encryption keys. Are people saying that Purism may be shipping phones with Byzantium using some common encryption keys for the luks encryption, so they’re the same on all the phones???

  1. Correct, both commands should be executed and in that order, so cryptsetup first then resize2fs

  2. Correct.

  3. The LUKS passphrase you set up will be retained.

  4. As far as I’m aware, the phones rolling of the assembly line and being shipped from the factory are reencrypted prior to being flashed. As your phone has arrived with you and has not had had the LUKS partition resized prior to dispatch it suggests that it may have gone through a slightly different process. I guess there my be some doubt as to whether it has gone through the re-encryption process prior to flashing or not.

@Loki , thanks again.

Regarding #4 about the reencryption:

4a) If I do nothing regarding the reencryption question, what risk am I accepting? And,

4b) The process you described above does not deal with the reencryption question you’re raising - right? So, do if I should want to ensure that the phone is properly encrypted, how, if at all, would the partioning process you described above be modified?

If the image was not reencrypted prior to flashing to your phone then there is a risk that the master key to decrypt your LUKS container is shared with one on more devices, meaning that there may be one or more individuals around the world with access to that master key and consequently, may have the ability to decrypt your device.

Regardless of whether or not the image was reencrypted prior to flashing, there is still the possibility that the image file containing your master key is knocking around the factory somewhere.

You are correct, the process I have described does not address any reencryption concerns, the process as described merely resizes the filesystem to make use of the entire disk space addressing your initial inquiry. Should you wish to reencrypt the phone, you would need to go through a full install process as the reencryption needs to be done prior to flashing as it is LUKS1 format which, if I recall correctly, only supports offline reencryption. The partition resizing process is currently required as part of doing a clean install/flash of Byzantium w/ LUKS encryption and as such, the process as described above would be directly applicable without modification.

@Loki , thank you very much, your instructions appear to have worked perfectly for me. One followup question:

Do you think the problem I faced was just a fluke? Or, will this problem keep coming up everytime there’s an OS upgrade for the Librem 5?

The master key doesn’t need to be in use on any other devices for someone else to know it. The OS image is available for download by anyone. The image contains its own master key, therefore that particular master key is available for download by anyone.

Assuming that @dln949’s phone was flashed with a publicly available image, without changing the master key, then practically anyone can now decrypt its storage if they have enough wit, motivation and physical access.

1 Like

Maybe use Jumpdrive to do offline reencryption? (from host or locally on phone - but not both)

You will not have to go through the resizing process again for standard upgrades through the Pure OS Store app or via any of the other package manager apps/utilities.

Only if you flash the phone with a new encrypted OS image will you have to resize after flashing. This is a known issue logged as Encrypted images don’t resize root partition so it’s probable that this issue will be addressed at some point and resizing after flashing the image will be done automatically on first boot.

1 Like

Yes, I believe that is an option. Although I have used Jumpdrive, I have not tried any sort of offline reencryption or other LUKS manipulation with it so couldn’t comment on how suitable it is.

Given that there are people who have been using Linux for a number of years, are familiar and comfortable with Linux but are still hesitant to flash their phone through the standard procedure, I don’t think Jumpdrive is a good recommendation for a newcomer or relative novice.

1 Like

Just for the record, as the recent images had a bug that prevented their rootfs from being resized automatically at first boot - the only thing needed to resize the filesystem is:

sudo growpart /dev/mmcblk0 2
sudo resize_rootfs

No reboot or playing with partition tables necessary.

Once all the needed fixes land in the repos, this will happen automatically (along with LUKS reencryption) at first boot after reflash.

5 Likes