pixel
Select Page

NETWAYS Blog

Kickstart your Laptop with Linux

Alle paar Jahre bekomme ich einen neuen Laptop bei Netways. Vor zwei Wochen war es wieder so weit und somit eine gute Gelegenheit mal wieder die Betriebssystem-Frage zu stellen. Die alte Frage also: “Welches Linux ist das Beste?”. Also für mich ganz persönlich. Nicht für die weite Welt. Zur Auswahl stehen die rpm Fraktion wie centos, fedora oder rhel; debianoide wie ubuntu, mint, debian und arch Derivate wie Manjaro oder Endeavour.

Entscheidungsmatrix

  • Suse ist raus, fedora ist mir zu unstable, centos/rhel zu altbacken.
  • ubuntu ist mir zu kommerziell, debian zu rock-stable, mint vereinigt irgendwas dazwischen
  • Manjaro finde ich ganz gut, Endeavour ist ein reines Arch mit beigelegtem installer.

Ergebnis

Ich nehme nichts von alledem, sondern Arch-Linux ohne Verpackung, aus folgenden Gründen.

Ein sehr neuer Laptop hat manchmal aktuelle Chipsätze oder ähnliches, die einen aktuellen Kernel oder andere Tools erfordern. Bei Arch Linux bekommt man immer aktuelle Software und muss nicht auf einen neuen Major-Release der Distro warten, da es sich um einen Rolling-Release handelt.
Für die Installation des OS brauche Endeavour oder Manjaro mehr. Das reine Arch Linux bringt mittlerweile einen terminal basierten Installer mit. Bis vor ein paar Jahren musste man die im Arch-Wiki beschriebene Schritt für Schritt Installation durchführen. Jetzt hat sich das mit archinstall aber sehr vereinfacht. Hier hat man nach circa 5 Minuten ein lauffähiges System. In meinem Fall: Eine LUKS verschlüsselte Basis Partition, darauf ein Gnome mit Wayland. Eine Besonderheit ist mir dabei aufgefallen. Per Default wird nicht mehr grub sondern systemd-boot genutzt. Ein letzter Fallstrick: Man sollte bei “Netzwerk” angeben, dass der NetworkManager die Verbindungen verwaltet, sonst hat man nach dem Neustart der Installation kein Netzwerk mehr. Damit dann nicht zu langweilig wird ist dann natürlich kein NetworkManager installiert und ohne Internet ist das auhch nicht möglich. Da ifconfig(depricated) auch nicht installiert ist landet man dann schnell an dem Punkt, wo man mit dem *ip* command weiterhelfen muss.
Generell ist das Arch-Wiki eine gute Anlaufstation für Hilfe. Obwohl Arch eine viel kleinere Nutzerbasis hat als Ubnutu oder fedora, ist das Wiki mittlerweile so ausführlich, dass ich darin auch Lösungen für Probleme finde die ich mit anderen Distros habe.
Updates: funktionieren einfach. Ich benutze seit circa sieben Jahren Arch Linux und konnte in der Zeit immer problemlos updaten. Ab und zu muss man mal den keyring aktualisieren wenn die Updates lange ignoriert wurden aber die Updates – an und für sich – funktionieren einfach.
Bei Ubuntu oder Fedora kann man das Glück haben das ein Softwarehersteller direkt Pakete baut und anbietet. Bei Arch nicht. Bei Arch gibt es allerdings das Arch User Repository (AUR). Hier werden an zentraler Stelle Pakete von einer großen Community gepflegt. Ein AUR Paket besteht dabei im Prinzip aus einem Pacman-Install-Skript(PKGBUILD), dass entweder vorkompilierte binaries von *irgendwo* laden oder auch mit Quelltext Binaries on-demand kompilieren kann. Allerdings muss man sich bewusst sein, dass die PKGBUILD zwar im AUR von der Community geprüft werden *können*, aber nicht in jedem Fall sicher sind. Ich finde aber das PKGBUILD-Format ist sehr einfach lesbar und man kann genau nachlesen was genau von wo heruntergeladen und wie installiert wird. Wenn man z.B. spotify aus dem AUR installiert kann man nachlesen, dass das debian Paket hierfür genutzt wird und von repository.spotify.com geladen wird. Außerdem kann man hier sehen, wie gpg genutzt wird um den Inhalt zu verifizieren.

[...]
source=('spotify.protocol'
'LICENSE'
"${pkgname}-${pkgver}-x86_64.deb::http://repository.spotify.com/pool/non-free/s/spotify-client/spotify-client_${pkgver}.${_commit}_amd64.deb"
[...]

Um mit AUR Paketen einfach installieren zu können favorisiere ich YAY, dass als pacman replacement fungiert. Eine Installation von eben genanntem Spotify würde man z.B. mit *yay spotify* anstoßen. Und bevor ich es vergesse: die schicken Icons aus dem Screenshot kommen aus dem buuf icon-set und können auch mit yay installiert werden.

To the moon

Für mich ist Arch aktuell das optimale Betriebssystem und wenn alle Anderen ihren Fehler endlich eingesehen haben könnte 2023 das Jahr des Linux-Desktops werden.

Christoph Niemann
Christoph Niemann
Senior Consultant

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

Ansible – Testing roles with Molecule

Ansible is a widely used and a powerful open-source configuration and deployment management tool. It can be used for simple repetitive daily tasks or complex application deployments, therefore Ansible is able to cover mostly any situation.

If used in complex or heterogene environments it is necessary to test the code to reduce time to fix code in production. To test Ansible code it is suggested to use Molecule.

Molecule is a useful tool to run automated tests on Ansible roles or collections. It helps with unit tests to ensure properly working code on different systems. Whether using the role internally or provide it to the public, it is useful to test many cases your role can be used. In addition Molecule is easily integrated into known CI/CD tools, like Github Actions or Gitlab CI/CD.

In this short introduction I’ll try get your first Molecule tests configured and running!

Please make sure you installed Molecule beforehand. On most distributions it’s easily installed via PIP.
The fastest and most common way to test roles would be in container. Due to a version problem with systemd currently it’s not possible to start services over systemd in containers. For this reason you can easily start with a vagrant instance and later migrate to docker or podman easily.


pip install molecule molecule-vagrant

If you have a role you can change into the role directory and create a default scenario.


cd ~/Documents/netways/git/thilo.my_config/
molecule init scenario -r thilo.my_config default
INFO     Initializing new scenario default...
INFO     Initialized scenario in /Users/thilo/Documents/netways/git/thilo.my_config/molecule/default successfully.

Below the molecule folder all scenarios are listed. Edit the default/molecule.yml to add the vagrant options.

Add a dependency file with your collections as with newer Ansible versions only the core is available. If needed you can add sudo privileges to your tests.

molecule/default/molecule.yml


---
dependency:
  name: galaxy
  options:
    requirements-file: collections.yml
driver:
  name: vagrant
platforms:
  - name: instance
    box: bento/centos-7
provisioner:
  name: ansible
verifier:
  name: testinfra
  options:
    sudo: true

The converge.yml is basically the playbook to run on your instance. In the playbook you define which variables should be used or if some pre-tasks should be run.

molecule/default/converge.yml


---
- name: Converge
  hosts: all
  become: true
  tasks:
    - name: "Include thilo.my_config"
      include_role:
        name: "thilo.my_config"

Now you can run your playbook with molecule. If you want to deploy and not delete your instance use converge. Otherwise you can use test, then the instance will be created, tested and destroyed afterwards.


python3 -m molecule converge -s default
or 
python3 -m molecule test -s default

Finally we can define some tests, the right tool is testinfra. Testinfra provides different modules to gather informations and check them if they have specific attributes.

Your scenario creates a tests folder with the following file: molecule/default/tests/test_default.py

In this example I’ll test the resources my role should create.


"""Role testing files using testinfra."""


def test_user(host):
    """Validate created user"""
    u = host.user("thilo")

    assert u.exists

def test_authorized_keys(host):
    """Validate pub key deployment"""
    f = host.file("/home/thilo/.ssh/authorized_keys")

    assert f.exists
    assert f.content_string == "ssh-rsa AAAA[...] \n"

And if we already converged our instance, we can verify these definitions against our deployment.


python3 -m molecule verify
INFO     default scenario test matrix: verify
INFO     Performing prerun with role_name_check=0...
[...]
INFO     Running default > verify
INFO     Executing Testinfra tests found in /Users/thilo/Documents/netways/git/thilo.my_config/molecule/default/tests/...
============================= test session starts ==============================
platform darwin -- Python 3.9.12, pytest-6.2.5, py-1.11.0, pluggy-0.13.1
rootdir: /
plugins: testinfra-6.4.0
collected 2 items

molecule/default/tests/test_default.py ..                                [100%]

============================== 2 passed in 1.79s ===============================
INFO     Verifier completed successfully.

With those easy steps you can easily test your roles for any scenario and your deployments can run without any hassle or at least you will be more relaxed during it 😉

Check out our Blog for more awesome posts and if you need help with Ansible send us a message or sign up for one of our trainings!

Thilo Wening
Thilo Wening
Manager Consulting

Thilo hat bei NETWAYS mit der Ausbildung zum Fachinformatiker, Schwerpunkt Systemadministration begonnen und unterstützt nun nach erfolgreich bestandener Prüfung tatkräftig die Kollegen im Consulting. In seiner Freizeit ist er athletisch in der Senkrechten unterwegs und stählt seine Muskeln beim Bouldern. Als richtiger Profi macht er das natürlich am liebsten in der Natur und geht nur noch in Ausnahmefällen in die Kletterhalle.

NETWAYS Support Collector Roadmap

Den Support Collector konnte ich bereits in meinem letzten Blogpost vorstellen. Für alle die den Beitrag verpasst haben, hier kurz umrissen was es ist:
Bei dem Tool handelt es sich um einen von uns geschriebenen Datensammler, welche alle möglichen Support relevanten Daten von einem System sammelt und als ZIP verpackt. Das ZIP kann in Support Fällen an uns geschickt werden, damit wir uns einen Überblick über das System machen können.

Letzte Woche konnte mit Verzögerungen die Version 0.7.0 veröffentlich werden, welche nun auch Daten über die IcingaDB und Redis sammelt. Von Versionen bis hin zur Konfiguration und Service Status wird alles mit gesammelt.

Im Rahmen dieses Blogposts möchte ich euch einen kleinen Ausblick geben, welche möglichen Erweiterungen wir mit dem Support Collector noch abbilden möchten.

Systemweiter Datensammler

Zum aktuellen Stand sammelt der Support Collector Daten ein, speichert sie in eine Datei und verpackt dass alles zu einem großem ZIP. Das ganze passiert aber nur auf dem System auf welchen das Tool ausgeführt wird. Jetzt stehen wir natürlich vor dem “Problem” dass Icinga 2 Umgebungen über mehrere Systeme verteilt sein können. So kann es sein dass einfach nur die Datenbank auf einem anderen Host läuft oder dass sich irgendwo noch ein zweiter Master bzw. Satelliten befindet. Aus Sicht des Supports wäre es natürlich schön auch diese Daten mit abzufragen.
Die Umsetzung des eben beschriebenen Vorhabens ist noch nicht ganz klar, da es hier neben vielen Kleinigkeiten vor allem die Security zu beachten gilt. Da wir uns auch vorstellen können, dass nicht ein jeder es gut findet, wenn wir komplette Systeme scannen, wird diese Funktion auch nur optional. Unser Augenmerk liegt darauf, dass der Benutzer frei entscheiden kann, was er gesammelt haben möchte.

Statistiken

Mit den gesammelten Daten lassen Sich natürlich auch aussagekräftige Statistiken erstellen. Anhand von diesen Daten könnten wir von den einfachsten Statistiken wie “Welche Versionen werden wie oft genutzt”, bis hin zu komplexen Themen wie “Durchschnittliche Größe eines Systems” oder “Welche Hardware Specs für welche Icinga 2 Größe” erstellen. Allerdings ist auch hier noch nicht zu eindeutig wie die Umsetzung aussehen soll, da hier ebenfalls die Security und Anonymität eine große und wichtige Rolle spielen.

Mit den zwei Punkten welche ich hier angesprochen habe, konnte ich euch nur einen kleinen Einblick gegeben, was an Feature Ideen noch in Planung sind. Sollte euch etwas einfallen, was aus eurer Sicht sinnvoll wäre umzusetzen, könnt ihr gerne ein Feature Request im Git Repository eröffnen.

Tobias Bauriedel
Tobias Bauriedel
Assistant Manager Operations

Tobias ist ein offener und gelassener Mensch, dem vor allem der Spaß an der Arbeit wichtig ist. Bei uns hat er seine Ausbildung zum Fachinformatiker für Systemintegration abgeschlossen und arbeitet nun im NETWAYS Professional Services - Team Operations und entwickelt nebenbei Projekte für die NPS. In seiner Freizeit engagiert er sich ehrenamtlich aktiv bei der Freiwilligen Feuerwehr als Atemschutzgerätetrager und Maschinist, bereist die Welt und unternimmt gerne etwas mit Freunden.

Der NETWAYS Support Collector

Dem ein oder anderen unserer Support Kunden ist unser neuer Support Collector vielleicht schon über den Weg gelaufen. Aber was ist das überhaupt? Und was bringt er?

Der NETWAYS Support Collector ist eines unserer neuesten Kreationen. Inspiriert von, dem mehr verbreiteten, icinga2-diagnostics ist die Aufgabe des Support Collectors, Daten über laufende Systeme und deren Komponenten zu sammeln.
So ist es möglich mittels eines einzelnen Aufrufes alle essentiellen Daten über das System zu sammeln.

Anhand dieser Daten können beispielsweise Support Abläufe effizienter gemacht werden oder sogar aussagekräftige Statistiken erstellt werden.

Der Support Collector kann neben den vorstellbar gängigen Daten wie Icinga 2 und Icinga Web 2 weit aus mehr.
Der aktuelle Rahmen, welcher durch das Tool abgedeckt wird, ist folgender:

  • Allgemeine System Informationen
  • Icinga 2
  • Icinga Web 2
  • Icinga Director
  • Mysql / MariaDB
  • PostgreSQL
  • Ansible
  • Puppet
  • InfluxDB
  • Grafana
  • Graphite

Für den User ist es selber wählbar, welche “Module” durch den Support Collector alle gesammelt werden sollen. Standartmäßig werden alle “Module” gesammelt, welche auf dem System gefunden werden.

Um den Sicherheitsaspekt zu beachten, werden alle Passwörter / IP Adressen / Token innerhalb der gesammelten Daten entfernt, bevor diese zu einen ZIP verpackt werden.
Die generierte ZIP Datei kann dann durch Support Kunden an unseren Support weitergeleitet werden, sobald ein Support Fall eintrifft.

Wer selber einen Blick auf den Support Collector werfen möchte, kann dies in dem GitHub Repository machen oder sich das Tool mit den durch uns bereit gestellten Paketen auf packages.netways.de/extra installieren.
Die –help Übersicht liefert einige Konfigurations Möglichkeiten, welche optional mitgegeben werden können.

Tobias Bauriedel
Tobias Bauriedel
Assistant Manager Operations

Tobias ist ein offener und gelassener Mensch, dem vor allem der Spaß an der Arbeit wichtig ist. Bei uns hat er seine Ausbildung zum Fachinformatiker für Systemintegration abgeschlossen und arbeitet nun im NETWAYS Professional Services - Team Operations und entwickelt nebenbei Projekte für die NPS. In seiner Freizeit engagiert er sich ehrenamtlich aktiv bei der Freiwilligen Feuerwehr als Atemschutzgerätetrager und Maschinist, bereist die Welt und unternimmt gerne etwas mit Freunden.

LUKS LVM Resizing

Ever tried to create a Dual Boot Ubuntu AFTER you encrypted your whole hard drive already?
Well don’t worry we got you covered!

My Problem:

I want to shrink my encrypted Ubuntu installation to make room for another OS, which I need for my video editing.
For that I have a SSD 512GB, which is encrypted with LUKS, uses LVM and ist partitioned in ext 4 fs.
But I also have an encrypted LUKS Swap called “vgubuntu-swap_1”, who also uses LVM and is formated in swap fs.

My partition had a size around 475 GiB before shrinking. The swap volume helps to demonstrate that shrinking may lead to gaps between logical LVM volumes.
The plan is to shrink the file system, its volume, the volume group and also the encrypted partition.
I used a Live Ubuntu System from a USB stick, since I could not just take the hard drive out. If you have just one computer available, use either a Live System from a USB stick or a DVD.

Disclaimer: PLEASE MAKE A BACKUP of the whole disk first.
Please read carefully through the steps first before you do anything.
If you are unsure about the commands and what they mean or what consequences they have, do some research on the Internet ahead. Likewise in case of trouble or error messages. It definitely helps to be familiar with partitioning, LVM, dm-crypt and LUKS.

My Solution:

Resizing was a sequence of 14 steps – following the disk layout in reverse order, I started resizing from the filesystem to the LVM structure down to the partition.
You open an encrypted partition with LVM on LUKS just as any dm-crypt/LUKS-partition by:

cryptsetup open /dev/Disk-MAPPING-Name cryptdisk

For the mapping name I used “cryptdisk“. Note that closing the encrypted device requires to deactivate the volume groups in the kernel first; in our case:

vgchange -a n vg1;

cryptsetup close cryptdisk

Otherwise you may not be able to close your device.

 

Step 1: Take a look at your Block Devices

With lsblk you take a look at you partitions

lsblk

For instance for me the disk appeared as “/dev/nvme0n1” – the encrypted partition was located on “/dev/nvme0n1p3”.

 

Step 2: Opening the encrypted partition

ubuntu@ubuntu:~$ cryptsetup open /dev/nvme0n1p3 cryptdisk

Review it so you know the mapping is done correctly by “ls -la /dev/mapper”
Take a look at the “cryptdisk”-device, but keep a close eye on the LVM-volumes inside the encrypted partition. They should appear automatically as distinct devices.

 

Step 3: Let’s take a look at the LVM Structure

Next up we have:

pvdisplay
vgdisplay
lvdisplay

Pvdisplay and vgdisplay show you the PV device:  “/dev/mapper/cryptdisk” and the volume group, like in my case “vgubuntu”.
With lvdisplay you can take a look at the logical volumes, so the path to the devices and LV Size. In this case it was: “/dev/vgubuntu/root” and “/dev/vgubuntu/swap_1”

 

Step 4: Filesystem Integrity check

With fsck we can make sure the filesystem is clean:

ubuntu@ubuntu:~$ sudo fsck /dev/vgubuntu/root
fsck from util-linux 2.36.1
e2fsck 1.46.3 (27-Jul-2021)
/dev/mapper/vgubuntu-root: clean, 530426/13107200 files, 14946582/52428800 blocks

That seems fine, let’s move on!

 

Step 5: Review  filesystem physical block size and used space

Since we need to take a look at the phyisical block size, we can use “fdisk -l”.
There were also a lot of loop devices in my case, but the last entry showed my encrypted drive.

ubuntu@ubuntu:~$ sudo fdisk -l

Disk /dev/mapper/cryptdisk: 475.71 GiB, 510787584000 bytes, 997632000 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
Inode count:              13107200
Block count:              52428800
Reserved block count:     2621439
Free blocks:              37482218
Free inodes:              12576774

 

Step 6: Reducing the Volume and filesystem size

For the reduced filesystem I went with 210G, since it should be about 200GiB size at the end.
With lvreduce we work with GiB, so the filesystem size should be 5-10% smaller than the logical volume size. Then we would get 200 * 1024 * 1024 * 1024 Bytes = 214.748.364.800 Bytes.

 

Step 7: Actually shrinking the filesystem

Please check first if the filesystem is mounted somewhere and then proceed with:

ubuntu@ubuntu:~$ sudo resize2fs /dev/mapper/vgubuntu-root 210G
resize2fs 1.46.3 (22-Dez-2021)
Resizing the filesystem on /dev/mapper/vgubuntu-root to <pre style="padding:8px;"> (4k) blocks.
The filesystem on /dev/mapper/vgubuntu-root is now 52428800 (4k) blocks long.

 

Step 8: Shrink the logical volume

With “lvreduce” we can resize the LVM volume, the option parameter “L” together with a “size” determines how big the volume will become.

ubuntu@ubuntu:~$  lvreduce -L 200G /dev/vgubuntu/root
WARNING: Reducing active logical volume to 200 GiB.
THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce vgubuntu/root? [y/n]: y
Size of logical volume vgubuntu/root changed from 210 GiB (20480 extents) to 200.00 GiB (15360 extents).
Logical volume vgubuntu/root successfully resized.

Since we got the confirmation that it worked, we can now proceed.

 

Step 9: Check for gaps between the volumes of your LVM volume group

That was the trickiest part for me at least since I had a swap with my Ubuntu. The first thing I did was to scan for the Swap, on which Blocks it was located.

I then used “pvmove” to get the swap from the last blocks to the ones after my root volume.

As you can see, my swap moved over and my free space had no further volumes in between.

 

Step 10: Resize/reduce the physical LVM

Next I had to resize and reduce the physical LVM to 200G

ubuntu@ubuntu:~$ sudo pvresize --setphysicalvolumesize 200.96G /dev/mapper/cryptdisk
/dev/mapper/cryptdisk: Requested size <200.96 GiB is less than real size <475.71 GiB. Proceed?  [y/n]: y
WARNING: /dev/mapper/cryptdisk: Pretending size is 421443665 not 997632000 sectors.
Physical volume "/dev/mapper/cryptdisk" changed
1 physical volume(s) resized or updated / 0 physical volume(s) not resized

Since the resize worked, I wanted to make sure everything was fine.

ubuntu@ubuntu:~$ sudo pvdisplay
--- Physical volume ---
PV Name               /dev/mapper/cryptdisk
VG Name               vgubuntu
PV Size               <200.96 GiB / not usable <2.04 MiB
Allocatable           yes (but full)
PE Size               4.00 MiB
Total PE              51445
Free PE               0
Allocated PE          51445
PV UUID               KpzZm…

 

Step 11: Setting up the encrypted regions size

First make sure which Block Size the current drive has:

ubuntu@ubuntu:~$ sudo cryptsetup status cryptdisk
/dev/mapper/cryptdisk is active and is in use.
type:    LUKS2
cipher:  aes-xts-plain64
keysize: 512 bits
key location: keyring
device:  /dev/nvme0n1p3
sector size:  512
offset:  32768 sectors
size:    997632000 sectors
mode:    read/write

Then I had to calculate the new blocksize for the encrypted disk, I used the formula on the Arch Wiki: NEW_LUKS_SECTOR_COUNT = PV_EXTENT_COUNT * PV_EXTENT_SIZE / LUKS_SECTOR_SIZE

From Step 10 (pvdisplay) and the cryptdisk status you can gather all the information needed to get:
(53880 extent + 1 unusable extent) * 4 MiB/extent /512 B/sector = 441393152 sectors

ubuntu@ubuntu:~$  sudo cryptsetup -b 441393152 resize cryptdisk
Enter passphrase for /dev/nvme0n1p3:
ubuntu@ubuntu:~$ sudo cryptsetup status cryptdisk
/dev/mapper/cryptdisk is active and is in use.
type:    LUKS2
cipher:  aes-xts-plain64
keysize: 512 bits
key location: keyring
device:  /dev/nvme0n1p3
sector size:  512
offset:  32768 sectors
size:    441393152 sectors
mode:    read/write

And now we have a smaller LUKS Partition. You came this far, now don’t stop!

 

Step 12: Reduce the size of the physical partition

Here I used parted to get an overview of my drives and resize it to the desired size:

ubuntu@ubuntu:~$ sudo parted /dev/nvme0n1
GNU Parted 3.4
Using /dev/nvme0n1
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Model: PM9A1 NVMe Samsung 512GB (nvme)
Disk /dev/nvme0n1: 512GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number  Start   End     Size   File system  Name                  Flags
1      1049kB  538MB   537MB  fat32        EFI System Partition  boot, esp
2      538MB   1305MB  768MB  ext4
3      1305MB  512GB   511GB

(parted) resizepart

Partition number? 3
End?  [512GB]? 211GB
Warning: Shrinking a partition can cause data loss, are you sure you want to continue?
Yes/No? y
(parted) print
Model: PM9A1 NVMe Samsung 512GB (nvme)
Disk /dev/nvme0n1: 512GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number  Start   End     Size   File system  Name                  Flags
1      1049kB  538MB   537MB  fat32        EFI System Partition  boot, esp
2      538MB   1305MB  768MB  ext4
3      1305MB  211GB   210GB

(parted) q

Information: You may need to update /etc/fstab.

I checked with print in between, to see if the parted resize worked.

 

Step 13: Set new size of the encrypted region

Now we just need to make sure we also have use the full partition size:

ubuntu@ubuntu:~$ sudo cryptsetup resize cryptdisk
ubuntu@ubuntu:~$ sudo cryptsetup status cryptdisk
/dev/mapper/cryptdisk is active.
type:    LUKS2
cipher:  aes-xts-plain64
keysize: 512 bits
key location: keyring

device:  /dev/nvme0n1p3
sector size:  512
offset:  32768 sectors
size:    409526848 sectors
mode:    read/write

 

Step 14: Reset the PV size to the full partition size

Next up we have to use pvresize so the cryptdisk gets also adjusted and then we can take a look at the volumes.

ubuntu@ubuntu:~$ pvresize  /dev/mapper/cryptdisk
Physical volume "/dev/mapper/cryptdisk" changed
1 physical volume(s) resized / 0 physical volume(s) not resized
ubuntu@ubuntu:~$ sudo pvdisplay
--- Physical volume ---
PV Name               /dev/mapper/cryptdisk
VG Name               vgubuntu
PV Size               210.47 GiB / not usable 2.00 MiB
Allocatable           yes
PE Size               4.00 MiB
Total PE              53880
Free PE               2435
Allocated PE          51445
PV UUID               Kpz...

ubuntu@ubuntu:~$ sudo vgdisplay
--- Volume group ---
VG Name               vgubuntu
System ID
Format                lvm2
...
VG Size               <210.47 GiB
PE Size               4.00 MiB
Total PE              53880
Alloc PE / Size       51445 / <200.96 GiB
Free  PE / Size       2435 / 9.51 GiB
VG UUID               dz0...

That’s it!

You can also do a checkup with gparted/disks, but apart from that I was just happy that I had more space for a second OS while also maintaining the encryption for Ubuntu!
(Now I will create another backup, just in case I break something with the new OS Installation.)