Skip to content

LUKS verschlüsselte Platte mounten

Linux
2 1 1.3k
  • Ich bin mal wieder am Spielen 🙂 Nachdem doch einiges schief gegangen ist, dazu später mehr, musste ich eine verschlüsselte NVMe SSD mal eben mounten um an ein paar Daten ran zu kommen.

    Pakete die benötigt werden

    apt install cryptsetup
    apt install lvm2
    

    Platte suchen

    root@frank-MS-7A34:~# blkid | grep crypto
    /dev/nvme0n1p3: UUID="abf46827-9c34-4ab5-a376-5e6344b4b164" TYPE="crypto_LUKS" PARTUUID="0552c66a-55cd-4153-bf01-787479575f0c"
    

    Platte entsperren

    root@frank-MS-7A34:~# cryptsetup luksOpen /dev/nvme0n1p3 crypthome
    Geben Sie die Passphrase für »/dev/nvme0n1p3« ein: 
    

    Mount Verzeichnis anlegen

    mkdir /mnt/crypthome
    

    /dev/mapper anzeigen

    root@frank-MS-7A34:~# fdisk -l
    [..gekürzt..]
    Festplatte /dev/mapper/crypthome: 476,19 GiB, 511299289088 Bytes, 998631424 Sektoren
    Einheiten: Sektoren von 1 * 512 = 512 Bytes
    Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
    E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
    
    
    Festplatte /dev/mapper/debian--vg-root: 444,24 GiB, 476988833792 Bytes, 931618816 Sektoren
    Einheiten: Sektoren von 1 * 512 = 512 Bytes
    Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
    E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
    
    
    Festplatte /dev/mapper/debian--vg-swap_1: 31,98 GiB, 34309406720 Bytes, 67010560 Sektoren
    Einheiten: Sektoren von 1 * 512 = 512 Bytes
    Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
    E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
    

    Das Root Verzeichnis möchte ich mounten.

    Mounten

    root@frank-MS-7A34:~# mount /dev/mapper/debian--vg-root /mnt/crypthome
    

    Fertig!

    Bildschirmfoto vom 2020-05-01 13-43-06.png

    Quelle: https://evilshit.wordpress.com/2012/10/29/how-to-mount-luks-encrypted-partitions-manually/

  • So, jetzt das ganze noch einen Ticken komplizierter 🙂

    Ich habe ja heute, für eine Neuinstallation von Ubuntu 20.04 Focal eine zweite NVMe SSD eingebaut. Meinen Bericht zu dem Thema findet ihr hier. Aber, darum soll es jetzt hier nicht gehen.

    Wir haben jetzt zwei verschlüsselte Ubuntu NVMe SSD Riegel im System. Jetzt klappt die ganze Sache da oben nicht mehr. Es kommt immer einen Fehlermeldung.

    unbekannter Dateisystemtyp „LVM2_member“.
    

    Ok, kurz googlen und dann findet man heraus, das es nicht klappen kann, weil beide LVM Gruppen, den selben Namen benutzen.

    root@frank-MS-7C37:/mnt/crypthome/root# vgdisplay
      --- Volume group ---
      VG Name               vgubuntu2
      System ID             
      Format                lvm2
      Metadata Areas        1
      Metadata Sequence No  4
      VG Access             read/write
      VG Status             resizable
      MAX LV                0
      Cur LV                2
      Open LV               1
      Max PV                0
      Cur PV                1
      Act PV                1
      VG Size               <464,53 GiB
      PE Size               4,00 MiB
      Total PE              118919
      Alloc PE / Size       118919 / <464,53 GiB
      Free  PE / Size       0 / 0   
      VG UUID               lpZxyv-cNOS-ld2L-XgvG-QILa-caHS-AaIC3A
       
      --- Volume group ---
      VG Name               vgubuntu
      System ID             
      Format                lvm2
      Metadata Areas        1
      Metadata Sequence No  3
      VG Access             read/write
      VG Status             resizable
      MAX LV                0
      Cur LV                2
      Open LV               2
      Max PV                0
      Cur PV                1
      Act PV                1
      VG Size               <475,71 GiB
      PE Size               4,00 MiB
      Total PE              121781
      Alloc PE / Size       121781 / <475,71 GiB
      Free  PE / Size       0 / 0   
      VG UUID               jRYTXL-zjpY-lYr6-KODT-u0LJ-9fYf-YVDna7
    

    Hier oben sieht man das schon mit geändertem Namen. Der VG Name muss unterschiedlich sein. Auch dafür gibt es ein Tool.

    root@frank-MS-7C37:/mnt/crypthome/root# vgrename --help
      vgrename - Rename a volume group
    
      Rename a VG.
      vgrename VG VG_new
    	[ COMMON_OPTIONS ]
    
      Rename a VG by specifying the VG UUID.
      vgrename String VG_new
    	[ COMMON_OPTIONS ]
    
      Common options for command:
    	[ -A|--autobackup y|n ]
    	[ -f|--force ]
    	[    --reportformat basic|json ]
    
      Common options for lvm:
    	[ -d|--debug ]
    	[ -h|--help ]
    	[ -q|--quiet ]
    	[ -v|--verbose ]
    	[ -y|--yes ]
    	[ -t|--test ]
    	[    --commandprofile String ]
    	[    --config String ]
    	[    --driverloaded y|n ]
    	[    --nolocking ]
    	[    --lockopt String ]
    	[    --longhelp ]
    	[    --profile String ]
    	[    --version ]
    
      Use --longhelp to show all options and advanced commands.
    

    Das muss dann so aussehen!

    vgrename lpZxyv-cNOS-ld2L-XgvG-QILa-caHS-AaIC3A vgubuntu2
    

    ACHTUNG

    Es kann zu Datenverlust kommen, also wie immer, Hirn einschalten!

    Ich weiß, das die erste eingebaute Platte mit der Nummer /dev/nvme0n1 geführt wird. Die zweite, heute verbaute, hört dann auf den Namen /dev/nvme1n1. Die darf ich nicht anpacken, weil sonst das System nicht mehr startet.

    /etc/fstab

    # /etc/fstab: static file system information.
    #
    # Use 'blkid' to print the universally unique identifier for a
    # device; this may be used with UUID= as a more robust way to name devices
    # that works even if disks are added and removed. See fstab(5).
    #
    # <file system> <mount point>   <type>  <options>       <dump>  <pass>
    /dev/mapper/vgubuntu-root /               ext4    errors=remount-ro 0       1
    # /boot was on /dev/nvme1n1p2 during installation
    UUID=178c7e51-a1d7-4ead-bbdf-a956eb7b754f /boot           ext4    defaults        0       2
    # /boot/efi was on /dev/nvme0n1p1 during installation
    UUID=7416-4553  /boot/efi       vfat    umask=0077      0       1
    /dev/mapper/vgubuntu-swap_1 none            swap    sw              0       0
    

    Jo, wenn jetzt die Partition /dev/mapper/vgubuntu2-root / anstatt /dev/mapper/vgubuntu-root / heißt läuft nichts mehr. Nur um das zu verdeutlichen, auch das könnte man problemlos reparieren. Aber, ich möchte nur warnen!!

    Nachdem die Änderung durchgeführt wurde, habe ich den Rechner neugestartet. Puuh, Glück gehabt, richtige NVMe SSD erwischt 🙂

    Festplatte /dev/mapper/vgubuntu2-root: 463,58 GiB, 497754832896 Bytes, 972177408 Sektoren
    Einheiten: Sektoren von 1 * 512 = 512 Bytes
    Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
    E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
    

    Nun können wir die Platte ganz normal, wie oben beschrieben, mounten. Nun kann ich noch ein paar Dinge kopieren 😉

  • Forgejo Installation mit Podman Quadlet auf Hetzner VM

    Podman forgejo podman quadlet linux
    2
    0 Stimmen
    2 Beiträge
    162 Aufrufe
    FrankMF
    Schauen wir uns mal an, wie man die Container aktuell hält. In der postgres.container steht das hier (als Beispiel) [Container] Image=docker.io/library/postgres:17 AutoUpdate=registry Das AutoUpdate=registry ist die Voraussetzung, dass der Container aktualisiert werden darf. Mit diesem Befehl kann man sich anschauen, wie der Stand der DInge ist. root@debian-4gb-nbg1-2-forgejo:~# podman auto-update --dry-run UNIT CONTAINER IMAGE POLICY UPDATED forgejo-pod.service 6486189fb10c (postgres) docker.io/library/postgres:17 registry false forgejo-pod.service 7d5627e2d434 (forgejo) codeberg.org/forgejo/forgejo:11.0.1 registry false forgejo-pod.service 7fb26d4f8b58 (nginx) docker.io/library/nginx:latest registry false Podman hat aber standardmäßig einen systemd Dienst, der sich darum kümmert root@forgejo:/etc/containers/systemd# systemctl status podman-auto-update.service ○ podman-auto-update.service - Podman auto-update service Loaded: loaded (/usr/lib/systemd/system/podman-auto-update.service; enabled; preset: enabled) Active: inactive (dead) since Mon 2025-06-09 00:02:57 UTC; 12h ago Invocation: a098f0054b254a0888ee789200ac9507 TriggeredBy: ● podman-auto-update.timer Docs: man:podman-auto-update(1) Process: 68939 ExecStart=/usr/bin/podman auto-update (code=exited, status=0/SUCCESS) Process: 68947 ExecStartPost=/usr/bin/podman image prune -f (code=exited, status=0/SUCCESS) Main PID: 68939 (code=exited, status=0/SUCCESS) Mem peak: 14.4M CPU: 292ms Jun 09 00:02:55 forgejo systemd[1]: Starting podman-auto-update.service - Podman auto-update service... Jun 09 00:02:55 forgejo podman[68939]: 2025-06-09 00:02:55.368941 +0000 UTC m=+0.059687227 system auto-update Jun 09 00:02:57 forgejo podman[68939]: UNIT CONTAINER IMAGE POLICY UPDATED Jun 09 00:02:57 forgejo podman[68939]: forgejo-pod.service 6486189fb10c (postgres) docker.io/library/postgres:17 registry false Jun 09 00:02:57 forgejo podman[68939]: forgejo-pod.service 7d5627e2d434 (forgejo) codeberg.org/forgejo/forgejo:11.0.1 registry false Jun 09 00:02:57 forgejo podman[68939]: forgejo-pod.service f2e9eee72017 (nginx) docker.io/library/nginx:latest registry false Jun 09 00:02:57 forgejo systemd[1]: podman-auto-update.service: Deactivated successfully. Jun 09 00:02:57 forgejo systemd[1]: Finished podman-auto-update.service - Podman auto-update service. postgres Ok, die Container sollten automatisch aktualisiert werden. docker.io/library/postgres:17 Die Postgres DB ist auf die Version 17 festgezurrt. Aktuell ist root@forgejo:/etc/containers/systemd# podman exec postgres postgres --version postgres (PostgreSQL) 17.5 (Debian 17.5-1.pgdg120+1) Eine Version 17.6 wird jetzt automatisch installiert, eine Version 18 aber nicht. nginx docker.io/library/nginx:latest NGINX zieht sich also immer die letzte "latest" Version, die zur Verfügung gestellt wird. root@forgejo:/etc/containers/systemd# podman exec nginx nginx -v nginx version: nginx/1.27.5 Gerade mal gecheckt, 1.27.5 ist die letzte Mainline Version. Also sind wir aktuell. forgejo Der Eintrag codeberg.org/forgejo/forgejo:11.0.1 aktuelle Version, die installiert ist. root@forgejo:/etc/containers/systemd# podman exec forgejo forgejo -v Forgejo version 11.0.1+gitea-1.22.0 (release name 11.0.1) built with GNU Make 4.4.1, go1.24.2 : bindata, timetzdata, sqlite, sqlite_unlock_notify Ok, wir sind auf Version 11.0.1 Wenn jetzt die Version 11.0.2 herauskommt, wird diese nicht installiert, da wir im forgejo.container folgendes stehen haben. [Container] Image=codeberg.org/forgejo/forgejo:11.0.1 Das ist aber erst mal nicht so schlimm, ich lese da mit und bekomme das mit. Das mache ich auch lieber von Hand, dann kann ich besser sehen wo es klemmt
  • OpenCloud - Docker Compose Hetzner VM

    Angeheftet Verschoben OpenCloud opencloud linux docker
    2
    2
    0 Stimmen
    2 Beiträge
    257 Aufrufe
    FrankMF
    Ich habe mich nochmal mit verschiedenen Aspekten der produktiven Installation beschäftigt. Auch ein wenig die KI befragt und dann ein paar Änderungen vorgenommen. Was hatte mich gestört? Traefik lief als root. Um das zu ändern, habe ich das docker-compose.yml angepasst. Ich habe auch gleich mal auf die aktuelle Version angepasst. services: traefik: image: traefik:v3.4.1 #3.3.1 container_name: traefik user: "1000:1001" # 1000 = dockeruser, 1001=docker group cap_add: - NET_BIND_SERVICE # erlaubt Ports <1024 restart: always networks: - opencloud-net ports: - "80:80" - "443:443" volumes: - ./certs:/certs # bind-mount acme.json - /var/run/docker.sock:/var/run/docker.sock:ro command: - "--log.level=${TRAEFIK_LOG_LEVEL:-ERROR}" # Let's Encrypt HTTP-01 Challenge - "--certificatesResolvers.http.acme.email=${TRAEFIK_ACME_MAIL:-example@example.org}" - "--certificatesResolvers.http.acme.storage=/certs/acme.json" - "--certificatesResolvers.http.acme.httpChallenge.entryPoint=http" - "--certificatesResolvers.http.acme.caserver=${TRAEFIK_ACME_CASERVER:-https://acme-v02.api.letsencrypt.org/directory}" # Dashboard - "--api.dashboard=true" # Entrypoints - "--entryPoints.http.address=:80" - "--entryPoints.http.http.redirections.entryPoint.to=https" - "--entryPoints.http.http.redirections.entryPoint.scheme=https" - "--entryPoints.https.address=:443" - "--entryPoints.https.transport.respondingTimeouts.readTimeout=12h" - "--entryPoints.https.transport.respondingTimeouts.writeTimeout=12h" - "--entryPoints.https.transport.respondingTimeouts.idleTimeout=3m" # Docker Provider - "--providers.docker.endpoint=unix:///var/run/docker.sock" - "--providers.docker.exposedByDefault=false" # Access Log - "--accessLog=true" - "--accessLog.format=json" - "--accessLog.fields.headers.names.X-Request-Id=keep" labels: - "traefik.enable=${TRAEFIK_DASHBOARD:-false}" - "traefik.http.middlewares.traefik-auth.basicauth.users=${TRAEFIK_BASIC_AUTH_USERS:-admin:$$apr1$$4vqie50r$$YQAmQdtmz5n9rEALhxJ4l.}" - "traefik.http.routers.traefik.entrypoints=https" - "traefik.http.routers.traefik.rule=Host(`${TRAEFIK_DOMAIN:-traefik.opencloud.test}`)" - "traefik.http.routers.traefik.middlewares=traefik-auth" - "traefik.http.routers.traefik.tls.certresolver=http" - "traefik.http.routers.traefik.service=api@internal" networks: opencloud-net: volumes: {} Und hierzu - ./certs:/certs # bind-mount acme.json brauch es noch ein paar Anpassungen auf dem Host, also im Verzeichnis von wo wir deployen mit dem dockeruser! mkdir -p ./certs touch ./certs/acme.json chmod 600 ./certs/acme.json chown 1000:1000 ./certs/acme.json # UID muss mit docker-compose user übereinstimmen Das klappt jetzt hier einwandfrei. dockeruser@opencloud:~/opencloud/deployments/examples/opencloud_full$ docker exec -it traefik id uid=1000 gid=1001 groups=1001 Sieht soweit gut aus Die KI meint noch das hier Wenn du maximale Sicherheit willst, kannst du langfristig docker-socket-proxy einsetzen. Er erlaubt Traefik nur lesenden Zugriff auf die Container-API: → Projektseite: Tecnativa/docker-socket-proxy Das muss ich aber erst noch sacken lassen und mich etwas zu einlesen.
  • Debian Bookworm 12.11 released

    Linux linux debian
    1
    0 Stimmen
    1 Beiträge
    206 Aufrufe
    Niemand hat geantwortet
  • Debian Bookworm 12.6 released

    Linux debian linux
    1
    0 Stimmen
    1 Beiträge
    183 Aufrufe
    Niemand hat geantwortet
  • Zima Board

    Linux zima linux
    6
    1
    0 Stimmen
    6 Beiträge
    979 Aufrufe
    FrankMF
    Wer noch einen braucht, sind wieder ein paar im Shop erhältlich. ZimaBoard 832 is IN STOCK & AVAILABLE NOW ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ZimaBoard Official Store Back In Stock The item you've been waiting for is back in stock ZimaBoard 832 - Single Board Server for Creators $199.90 Model: ZimaBoard 832 Stock: 190
  • NodeBB - Upgrade auf v1.19.3

    NodeBB nodeb linux
    1
    0 Stimmen
    1 Beiträge
    138 Aufrufe
    Niemand hat geantwortet
  • 10G

    Linux 10g linux
    2
    0 Stimmen
    2 Beiträge
    222 Aufrufe
    FrankMF
    Bedingt durch ein paar Probleme mit der Forensoftware, habe ich einen kleinen Datenverlust erlitten. Dazu gehören auch hier einige Beiträge. Dann versuche ich das mal zu rekonstruieren. Oben hatten wir das SFP+ Modul ja getestet. Als nächsten Schritt habe ich die ASUS XG-C100F 10G SFP+ Netzwerkkarte in meinen Hauptrechner verbaut. [image: 1635752117002-20211028_162455_ergebnis.jpg] Die Verbindung zum Zyxel Switch erfolgt mit einem DAC-Kabel. Im Video zum Zyxel Switch wurde schön erklärt, das die DAC Verbindung stromsparender als RJ45 Adapter sind. Somit fiel die Wahl auf die DAC Verbindungen. Hier nochmal das Video. https://www.youtube.com/watch?v=59I-RlliRms So sieht so ein DAC Verbindungskabel aus. Die SFP+ Adapter sind direkt daran montiert. [image: 1635752308951-20211028_170118_ergebnis.jpg] ethtool root@frank-MS-7C37:/home/frank# ethtool enp35s0 Settings for enp35s0: Supported ports: [ FIBRE ] Supported link modes: 100baseT/Full 1000baseT/Full 10000baseT/Full 2500baseT/Full 5000baseT/Full Supported pause frame use: Symmetric Receive-only Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 100baseT/Full 1000baseT/Full 10000baseT/Full 2500baseT/Full 5000baseT/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Speed: 10000Mb/s Duplex: Full Port: FIBRE PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: pg Wake-on: g Current message level: 0x00000005 (5) drv link Link detected: yes iperf3 ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Accepted connection from 192.168.3.207, port 44570 [ 5] local 192.168.3.213 port 5201 connected to 192.168.3.207 port 44572 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 1.10 GBytes 9.43 Gbits/sec 46 1.59 MBytes [ 5] 1.00-2.00 sec 1.10 GBytes 9.42 Gbits/sec 0 1.60 MBytes [ 5] 2.00-3.00 sec 1.10 GBytes 9.42 Gbits/sec 3 1.60 MBytes [ 5] 3.00-4.00 sec 1.10 GBytes 9.42 Gbits/sec 0 1.60 MBytes [ 5] 4.00-5.00 sec 1.10 GBytes 9.42 Gbits/sec 0 1.61 MBytes [ 5] 5.00-6.00 sec 1.10 GBytes 9.42 Gbits/sec 0 1.63 MBytes [ 5] 6.00-7.00 sec 1.10 GBytes 9.42 Gbits/sec 0 1.63 MBytes [ 5] 7.00-8.00 sec 1.09 GBytes 9.41 Gbits/sec 0 1.68 MBytes [ 5] 8.00-9.00 sec 1.10 GBytes 9.42 Gbits/sec 0 1.68 MBytes [ 5] 9.00-10.00 sec 1.10 GBytes 9.42 Gbits/sec 0 1.68 MBytes [ 5] 10.00-10.02 sec 22.5 MBytes 9.45 Gbits/sec 0 1.68 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.02 sec 11.0 GBytes 9.42 Gbits/sec 49 sender
  • NodeBB - nach Plugin platt

    NodeBB nodebb linux
    1
    0 Stimmen
    1 Beiträge
    635 Aufrufe
    Niemand hat geantwortet