Eine Antwort schreiben

Schreibe deinen Beitrag und versende ihn
Beitragsoptionen
Deine Antwort

Zurück

Themen-Übersicht (Neuester Beitrag zuerst)

Bachsau
15.03.2019 10:55:35

Ja ok, vielleicht bin ich da nicht ganz up-to-date. Jedenfalls ist es, nachdem was ich gelesen habe, bei der Verschlüsselung nicht sicherer, so dass es nicht unbedingt notwendig ist, zu wechseln, wenn man einen bestehenden Container hat.

frostschutz
14.03.2019 21:42:43
Bachsau schrieb:

Von LUKS 2 würde ich aber Abstand nehmen. Es bietet eigentlich keine Vorteile, ist aber vermutlich noch nich ganz ausgereift.

Inzwischen ist es so (bei ArchLinux), daß du bei cryptsetup explizit angeben musst, wenn du LUKS1 haben willst. Ansonsten wird es automatisch LUKS2.

Da die ganzen Cryptsetup-Anleitungen im Wiki hierzu keine Angaben machen, erzeugen alle Wikibefehle damit auch ein LUKS2. (Edit: Korrektur, es steht doch im Wiki. Aber nur auf der englischen Seite.)

Somit muss man sagen, egal welche Meinung man zu LUKS2 hat: das ist jetzt schon der neue Standard bei ArchLinux.

# rm foobar.img
# truncate -s 1G foobar.img
# cryptsetup luksFormat foobar.img

WARNING!
========
This will overwrite data on foobar.img irrevocably.

Are you sure? (Type uppercase yes): YES
Enter passphrase for foobar.img: 
Verify passphrase: 


# cryptsetup luksDump foobar.img 
LUKS header information
Version:       	2
Epoch:         	3
Metadata area: 	16384 [bytes]
Keyslots area: 	16744448 [bytes]
UUID:          	04a54e7f-5a51-49e9-9558-97342329638a
Label:         	(no label)
Subsystem:     	(no subsystem)
Flags:       	(no flags)

Data segments:
  0: crypt
	offset: 16777216 [bytes]
	length: (whole device)
	cipher: aes-xts-plain64
	sector: 512 [bytes]

Keyslots:
  0: luks2
...
Bachsau
14.03.2019 21:18:02

Man kann aber auch einfach den "Unterbau" neu erstellen und trotzdem das bestehende Dateisystem mit dd da rein setzen. Das hinterher zu vergrößern ist dann keine große Sache mehr. Braucht man nur einmal e2fsresize ohne Parameter drüber laufen lassen. Von LUKS 2 würde ich aber Abstand nehmen. Es bietet eigentlich keine Vorteile, ist aber vermutlich noch nich ganz ausgereift.

frostschutz
14.03.2019 18:03:45

rsync ist keine Neuinstallation (die bleibt unangetastet) aber eben neue Partitionierung, neue/andere Dateisystem(-typ -aufteilung -größe), neuer LUKS-Container (oder auch nicht je nach Gusto), neuer Bootloader. Also Altlasten bezogen hier auf die äußere Struktur, das Innere kannst du ja auch sonst jederzeit regeln (nicht mehr benötigte Pakete deinstallieren, Konfigurationsdateien editieren, sonstige Datenhaushaltung etc.)

Das schafft deutlich mehr Flexibilität als 1:1 dd, das man nachträglich noch vergrößert werden muss. Du kannst dabei eben alle Entscheidungen neu fällen, verschlüsseln oder nicht, RAID oder nicht, LVM oder nicht, ext4 oder xfs oder btrfs oder ...

Letztlich alles Geschmackssache. Neuinstallation ist natürlich auch möglich (da hat man dann auch neue SSH-Host-Keys und solche Sachen, Dinge an die man sonst gar nicht denkt). Bei anderen Distris wie Ubuntu würde ich die Neuinstallation auch bevorzugen, ist dort eben ne 1-Klick-und-Fertig Geschichte.

H.G. Butte
14.03.2019 17:55:11
nik schrieb:

Die Altlasten würdest du bei deinem Vorschlag mit dd ja genauso mitschleppen.

Ich weiß. Frostschutz hatte nur angesprochen, dass durch das Klonen diverse Altlasten mitkommen. Was ich bei der rsync-Methode aber halt auch sehen würde. Wenn auch nicht in dem gleichen Umfang.

nik
14.03.2019 17:16:08

Die Altlasten würdest du bei deinem Vorschlag mit dd ja genauso mitschleppen.

deine Idee der Vorgehensweise findet dann während der Neuinstallation statt und ersetzt praktisch das pacstrap

Wenn du es so nennen möchtest. Eine Neuinstallation findet eigentlich nicht statt. Du partitionierst, erstellst den Luks-Container und LVM-Volumes und anstatt pacstrap zu nutzen, kopierst du den Inhalt deiner alten SSD mittels rsync auf die neue NVMe.

H.G. Butte
14.03.2019 16:42:57

Moin moin,

danke für euer Feedback. frostschutz, deine Idee der Vorgehensweise findet dann während der Neuinstallation statt und ersetzt praktisch das pacstrap, sehe ich das richtig?

Aber gerade beim rsync ziehe ich doch ggf. wieder diverse Altlasten mit mir mit. Zumindest im Bereich /etc. Da weiß ich nicht, ob ich dann ganz in den sauren Apfel beiße und komplett sauber aufsetze. Wobei ich eigentlich den Aufwand so gering wie möglich halten wollte.

nik
14.03.2019 08:21:19

Würde dir auch zu der Vorgehensweise von frostschutz raten. Gerade bei Luks lohnt es sich meiner Meinung nach, den Wechsel zu Luks2 mitzumachen. Das wäre eine gute Gelegenheit dafür.

frostschutz
13.03.2019 22:41:58

SSDs überschreibt man eigentlich nicht mit Zufallsdaten. Zum einen sinnlos weil nach TRIM/discard ist das eh wieder weg, und daß freier Speicher sichtbar ist, das ist normalerweise kein Problem. Und zum anderen da die SSD neu ist und noch nie unverschlüsselte Daten drauf gespeichert waren, muss man da auch nichts sicher löschen. Und wenn du mit dd kopierst, sind die Zufallsdaten ja auch wieder weg (zumindest für die ersten 120G).

Gegen das Klonen spricht sonst eigentlich nur, daß du so halt auch sämtliche Altlasten mitnimmst. Ob es prinzipiell funktioniert... kannst du nur herausfinden indem du es machst und ausprobierst. Solange die Quell-SSD dabei nicht überschrieben wird, kostet der Versuch ja nichts. (bloß Abstöpseln ist wichtig sonst große Katastrophe wegen identischer UUIDs).

Ich greife bei sowas gerne zur traditionellen Variante, ungefähr so (von einem Livesystem aus):

# status quo mounten (ggf. readonly)
mkdir /mnt/alt
mount -o ro /dev/os/root /mnt/alt
mount -o ro /dev/sda1 /mnt/alt/boot

# neue struktur erstellen und mounten
# ...also nach parted, cryptsetup, lvcreate, mkfs, ...
mkdir /mnt/neu
mount /dev/newvg/root /mnt/neu
mkdir /mnt/neu/home
mount /dev/newvg/home /mnt/neu/home

# und schwupps
rsync -va -AHSX /mnt/alt/. /mnt/neu/.

# chroot nach /mnt/neu, bootloader installieren, fstab/crypttab/grubcfg/etc. anpassen, mkinitcpio neu erstellen, etc.

reboot

Das schöne daran ist, man kann damit alles umziehen und die Struktur dabei fast beliebig ändern (andere Dateisysteme, neues LUK2-Header-Format, separates LV für /home, etc.).

Man muss das System dabei halt verstehen, und wieder bootfähig machen.

H.G. Butte
13.03.2019 21:47:07

Moin moin,

ich möchte bei einem meiner Arch-Rechner meine alte SATA-SSD gegen eine neue NVMe-SSD austauschen, da die SSD langsam unschöne SMART-Werte liefert und inzwischen eh zu klein ist.

Folgende Eckdaten zum Setup:
- LVM on LUKS
- Mounts per UUID

sda                          8:0    0 111.8G  0 disk  
├─sda1                       8:1    0   256M  0 part  /boot
└─sda2                       8:2    0 111.6G  0 part  
  └─lvm                    254:0    0 111.6G  0 crypt 
    ├─os-swap              254:1    0     4G  0 lvm   [SWAP]
    └─os-root              254:2    0 107.5G  0 lvm   /

Die Umstellung soll von 120GB auf 500GB erfolgen. Dabei möchte ich gerne um eine Neuinstallation herum kommen und habe mich schlau gemacht, wie ich hier am besten vorgehen könnte.

Bei SSD zu SSD wird oft dd empfohlen:

- Neue SSD ran
- Per dd klonen
- Partionen anpassen
- Alte SSD ab

Da die UUIDs etc. alles mitgeclont werden, muss man im Endeffekt nichts tun.

Da ich jedoch nun von SATA auf NVMe wechseln möchte, weiß ich nicht, ob ich hier besonderes beachten muss. Ich konnte hierzu nichts finden.

Sorgen bzw. Unsicherheit herrscht nun bei LVM und LUKS. Mein Plan wäre wie folgt gewesen:

- Neue SSD dran und per dm-crypt erst einmal komplett mit Random Müll vollschreiben
- Danach regulär mit dd alles kopieren
- Partition sda2 auf maximum vergrößern
- Volume Group lvm vergrößern
- Locale Volumen os-root vergrößern

Bei Recherchen im Netz bin ich jedoch immer nur darauf gestolpert, dass Leute eine neue Partionen angelegt haben und diese dann der VG hinzugefügt haben. Daher bin ich mir nun nicht über das eigentliche Vorgehen sicher.

Ich bin auch über die Möglichkeit gestolpert, dass ich die neue SSD einfach dem LVM hinzufüge und alle Partionen umziehe, siehe hier: https://askubuntu.com/questions/161279/ … -hard-disk Wäre natürlich das eleganteste. Was mich daran aber stört: Geht dabei etwas schief, ist das System erst einmal defekt, was bei einem Klon-Prozess nicht der Fall wäre. Hier könnte ich im Problemfall einfach die alte SSD dran klemmen.

Hat mit diesem Prozess jmd. hier Erfahrung und ggf. einen klugen Tipp zum Vorgehen?

Fußzeile des Forums

Powered by FluxBB