Guten Morgen!

Ich möchte mein aktuell auf Laptop-A genutztes Debian Stable auf
Laptop-B klonen/kopieren, weil Laptop-B Laptop-A ersetzen soll.
Die SSD auf A hat grob (die fdisk-Auflistung steht am Ende):
- ein Grub
- eine Boot-Partition
- eine mit LUKS verschlüsselte Partition, in welcher auf XFS das
Debian läuft
- eine verschlüsselte Swap-Partition
- eine NTFS-Partition für allgemeinzugängliche Daten
- eine NTFS-Partition mit einem Windows-7.
- und nochwas, von dem ich nicht weiß, warum ich es mal eingerichtet
habe, was nicht genutzt wird.

Die neue NVMe wird wahrscheinlich größer als die aktuelle SSD. Lassen
wir mal das Windows-7 in der Betrachtung weg (ich würde nur Platz
lassen wollen, um eventuell ein Win-11 als DualBoot nachinstallieren zu können).
Wie bekomme ich das Linux z.B. via LAN von A auf B? Auf beiden ein
live-Linux wie z.B. GRML booten? Und dann? Oder muss ich die NVMe "vorbereiten", z.B. indem ich auf B schon partitioniere und ein grub installiere?

Begründung zum Verständnis:
In der Vergangenheit war diese Art des "cloning" effizienter, weil
schneller als eine Neuinstallation *mit allen Feinanpassungen*. Am schwierigsten ist es, UID und GID bei einer Neuinstallation auf
gleichen Stand zu bekommen. Außerdem habe ich alle Daten quasi
"nahtlos" von Plattform A auf Plattform B.
Allerdings habe ich das "damals" irgendwie mit netcat und tar
gemacht, weil die Systeme nicht vollverschlüsselt waren.

Würde mich über Ideen und Anregungen freuen!
Bitte kein "mach eine Neuinstallation" - die kann ich immer noch
machen, wenn gar nichts geht und ich an dieser selbstgewählten Aufgabe scheitere.

LG

Dirk
P.S.: das neue Laptop ist ein Fujitsu-Siemens U9311X, falls das
irgendwie wichtig ist (z.B. bzgl. BIOS oder so). Das alte ist ein P771
vom selben Hersteller.

Gerät Boot Anfang Ende Sektoren Größe Kn Typ
/dev/sda1 * 2048 206847 204800 100M 7 HPFS/NTFS/exFAT /dev/sda2 206848 368639999 368433152 175,7G 7 HPFS/NTFS/exFAT /dev/sda3 368640000 370593791 1953792 954M 83 Linux
/dev/sda4 370595838 1000214527 629618690 300,2G 5 Erweiterte
/dev/sda5 370595840 927234047 556638208 265,4G 83 Linux
/dev/sda6 927236096 958484479 31248384 14,9G 83 Linux
/dev/sda7 958486528 1000214527 41728000 19,9G 7 HPFS/NTFS/exFAT

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hallo Dirk.

Dirk S. - 03.07.24, 14:50:32 CEST:

Wie bekomme ich das Linux z.B. via LAN von A auf B? Auf beiden ein
live-Linux wie z.B. GRML booten? Und dann? Oder muss ich die NVMe "vorbereiten", z.B. indem ich auf B schon partitioniere und ein grub installiere?

Ich habe das mehrfach gemacht und es funktioniert. Aber es sind schon
einige Schritte, damit es funktioniert. Soweit mir im Moment aus dem
Stegreif einfällt, *mindestens*:

1. Neues System passend partitionieren.

2. Anlegen des LUKS-Gerätes, z.B. mit:

cryptsetup luksFormat --key-size 512 --hash sha512 --iter-time 5000
PARTITION

Weniger als 5000, falls Du nicht 5 Sekunden auf das Prüfen eines Passworts warten möchtest :). Möglicherweise gibt es mittlerweile sogar noch bessere Einstellungen.

3. Dateisysteme anlegen.

4. Dateisysteme entsprechend einhängen.

5. Kopieren der Daten mit "rsync -aAHXPS --numeric-ids" oder ähnlich. "--numeric-ids" ist sehr wichtig beim Kopieren übers Netzwerk via GRML
oder einem anderen Live Linux. Ich vergaß "--numeric-ids" für das Dateisystem für das Betriebssystem. Bei einem früheren Umzug via Backup- Festplatte war die Option nicht erforderlich oder ich hatte Glück, aber
ich glaube rsync macht standardmäßig das zu Fehlern führende Zuordnen nach Namen nur bei Übertragung übers Netzwerk. Ergebnis: Viele DBUS-Dienste ließen sich nicht starten. "permission denied". Ich hab Stunden gebraucht, die Ursache zu finden: Falsche Gruppe für zwei Verzeichnisse in "/etc/ polkit-1". Ich hab nach 2 Tagen mit abendlichen Herumsuchen
glücklicherweise die Ursache gefunden und hab nochmal mit "--numeric-ids" synchronisiert und meine Änderungen seitdem wiederholt. Alternativ zum Übertragen übers Netzwerk den Umweg über ein Backup-Medium gehen.

Eine Variante ist: Zunächst nur alle zum Booten erforderlichen Daten via "rsync" kopieren. Dann in das neue System booten und die Benutzer-Daten in "/home" und ggf. anderswo nachziehen. So habe ich das gemacht, da ich das
neue System, ein feines ThinkPad T14 AMD Gen 5, so schnell wie möglich (teilweise) einsatzfähig haben wollte.

6. Einige Bind-Mounts für /proc, /sys, /dev, /dev/pts usw. und "chroot" in das installierte System.

7. Z.B. mit "blkid" IDs raussuchen und "/etc/crypttab" anpassen

8. ggf. "/etc/fstab" anpassen.

9. "update-initramfs -k all"

10. "grub-install"

Das sind so grob die Schritte, die mir gerade einfallen.

Es braucht eine gewisse Linux-Expertise und/oder Bereitschaft, das alles
zu recherchieren. Ich hab mir eine für meine Situation angepasste
Anleitung erstellt, bin aber derzeit wenig gewillt, die um private Informationen zu erleichtern, um die dann irgendwo online stellen.

Mit anderen Worten: Wenn Du Fragen musst, damit es funktioniert, nicht verstehst, wie das mit den obigen Schritten gemeint ist, oder Dich
irgendwie unsicher damit fühlt, würde ich Dir abraten. *Es sei denn Du*
bist wirklich bereit, Dich da rein zu fuchsen und Fehler-Analyse zu
betreiben, falls das neue System bei den ersten Versuchen nicht richtig bootet. Und mit bereit dazu meine ich auch: Bei einem Fehler erst mal
selbst nachzudenken und zu recherchieren.

Falls Du diesen Weg wählst, empfehle ich Dir, Dir dabei für Dich eine Anleitung zu erstellen. Falls Du das nochmal brauchst. Ich konnte bei
meiner letzten Migration auf meine alte Anleitung zurückgreifen und bis
auf das fehlende "--numeric-ids" hat mir diese alte Anleitung viel Zeit gespart.

Eine Alternative wäre mal eine lokale Linux-Benutzer-Gruppe (Linux User Group, kurz: LUG) zu besuchen, um zu schauen, inwiefern da jemand in der
Lage und bereit dazu ist, Dich durch diesen Prozess hin durch zu führen.
Eine Mailingliste ist dafür nicht wirklich der geeignete Weg. Bei
gezielten Nachfragen, ja… aber für den ganzen Prozess. Das kann schnell sehr zeitintensiv werden. Insbesondere, falls dann die entscheidenden Informationen, Fehlermeldungen usw. fehlen.

Eine weitere Alternative wäre, das System neu zu installieren, aber die Benutzerdaten in "/home" und ggf. anderswo zu synchronisieren. Dann
entfallen viele der obigen Schritte.

Windows habe ich früher mal mit "ntfsclone" kopiert, aber mit deren neuen Bootloader-Anforderungen… keine Ahnung. Ich halte nichts von Dual Boot- Systemen und hab für mich privat Windows komplett entsorgt.

Ciao,
--
Martin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 3 Jul 2024 14:50:32 +0200, "Dirk S."
<debianml@dnetz.homelinux.org> wrote:

Die neue NVMe wird wahrscheinlich größer als die aktuelle SSD. Lassen
wir mal das Windows-7 in der Betrachtung weg (ich würde nur Platz
lassen wollen, um eventuell ein Win-11 als DualBoot nachinstallieren zu >können).

Bitte kein Dualboot. Wenn es irgend geht.

Grüße
Marc
--
---------------------------------------------------------------------------- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Marc Haber - 03.07.24, 16:32:03 CEST:

On Wed, 3 Jul 2024 14:50:32 +0200, "Dirk S."

<debianml@dnetz.homelinux.org> wrote:

Die neue NVMe wird wahrscheinlich größer als die aktuelle SSD. Lassen
wir mal das Windows-7 in der Betrachtung weg (ich würde nur Platz
lassen wollen, um eventuell ein Win-11 als DualBoot nachinstallieren zu >können).

Bitte kein Dualboot. Wenn es irgend geht.

Ist das mittlerweile wirklich so schmerzhaft? :)

--
Martin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Joachim Hussong - 03.07.24, 17:20:48 CEST:

Am 03.07.24 um 17:10 schrieb Martin Steigerwald:

Marc Haber - 03.07.24, 16:32:03 CEST:

On Wed, 3 Jul 2024 14:50:32 +0200, "Dirk S."
Bitte kein Dualboot. Wenn es irgend geht.

Ist das mittlerweile wirklich so schmerzhaft? :)

Wir hatten die Diskussion vor kurzem schon mal.

Nur eine Person sprach sich vehement dagegen aus. Alle anderen haben
Dual Boot im Einsatz gehabt und damit keine Probleme zu berichten.

Hmm, okay… Danke für den Hinweis.

--
Martin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Wed, Jul 03, 2024 at 04:51:23PM +0200 schrieb Martin Steigerwald:

Mit anderen Worten: Wenn Du Fragen musst, damit es funktioniert, nicht verstehst, wie das mit den obigen Schritten gemeint ist, oder Dich
irgendwie unsicher damit fühlt, würde ich Dir abraten. *Es sei denn Du* bist wirklich bereit, Dich da rein zu fuchsen und Fehler-Analyse zu betreiben, falls das neue System bei den ersten Versuchen nicht richtig bootet. Und mit bereit dazu meine ich auch: Bei einem Fehler erst mal
selbst nachzudenken und zu recherchieren.

Danke für deine Antwort! Ich denke, diee "Expertise" ist für diesen Weg ausreichend vorhanden - ich bin ja auch lange genug auf dieser ML und
mit Debian vertraut. Ich habe das ja auch _ohne_ LUKS schon mehrfach erfolgreich gemacht - ist allerdings >10 Jahre her, so lange ist kein
System neu hinzugekommen, und alle vorhandenen haben alle Major-Upgrade
klaglos überstanden. Das wird bei Debian wirklich von Release zu
Release besser! Ich kann gerne, sobald ich wieder zu Hause bin, meine diesbezügliche eigene Dokumentation heraussuchen und zur Verifizierung
auf Fehler zur Verfügung stellen (notfalls auch per Mail, falls es zu uninteressant ist).

Ich hatte die Hoffnung, dass ich "einfach" irgendwie den LUKS-"Container" rüberkopieren und weiter nutzen kann.

Eine weitere Alternative wäre, das System neu zu installieren, aber die Benutzerdaten in "/home" und ggf. anderswo zu synchronisieren. Dann
entfallen viele der obigen Schritte.

Wenn ich eine Möglichkeite wüsste, beim Neuinstall UID und GID für alle anzulegenden Dienste und User festzulegen, würde ich sogar diesen Weg
in Erwägung ziehen, einfach um "Altlasten" loszuwerden.
Aber mir ist keine Möglichkeit bekannt, und identische UID/GID auf
allen von mir administrierten Systemen ist mir sehr wichtig, weil das
sehr viele Dinge erleichtert und Fehlerquellen ausschließt.

Windows habe ich früher mal mit "ntfsclone" kopiert, aber mit deren neuen Bootloader-Anforderungen… keine Ahnung. Ich halte nichts von Dual Boot- Systemen und hab für mich privat Windows komplett entsorgt.

Das würde ich auch gerne, aber es gibt leider Dinge, wofür es ab und zu einfach notwendig ist. Ein Update meines Jabra-Headset in einer VM war
faktisch unmöglich, und ich möchte das Risiko nicht eingehen, dass mein
VCDS über die OBD-Schnittstelle fehlerhaft funktioniert, nur weil das USB-timing der VM nicht gut ist.
Aber wie gesagt, das wäre ein weiterer Schritt, für den ich nur wissen müsste, was ich bei einer "DualBoot-ready"-Partitionierung beachten
müsste.

ciao, Dirk

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dirk S. wrote:

Guten Morgen!

Ich möchte mein aktuell auf Laptop-A genutztes Debian Stable auf
Laptop-B klonen/kopieren, weil Laptop-B Laptop-A ersetzen soll.
Die SSD auf A hat grob (die fdisk-Auflistung steht am Ende):

Wie wäre es mit Clonezilla? https://clonezilla.org/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Wed, Jul 03, 2024 at 04:32:03PM +0200 schrieb Marc Haber:

On Wed, 3 Jul 2024 14:50:32 +0200, "Dirk S."
<debianml@dnetz.homelinux.org> wrote:

Die neue NVMe wird wahrscheinlich größer als die aktuelle SSD. Lassen
wir mal das Windows-7 in der Betrachtung weg (ich würde nur Platz
lassen wollen, um eventuell ein Win-11 als DualBoot nachinstallieren zu >können).

Bitte kein Dualboot. Wenn es irgend geht.

Das Problem ist, dass aus Erfahrung auf mindestens einem Gerät (und das
aus Gründen ein Laptop) in meinem Zoo ein natives Windows leider(!)
immer noch sinnvoll ist. Es gibt *immer noch* Hardware, deren Software
so mies programmiert ist, dass ich mit einer Nutzung aus einer VM heraus regelmäßig scheitere. So lange es "nur" nicht funktioniert, ist das verschmerzbar, aber sobald das Gerät, auf dem das Update gemacht werden
soll, in undefiniertem, unbenutzbarem Zustand zurück bleibt, ist das
halt doof. Die letzten, bei denen es Probleme gab, waren ein Quansheng
und ein Jabra.
Deshalb ja auch die Aussage, dass ich dafür _vorbereitet_ sein will,
eventuell aus dem System ein DualBoot zu bauen. Denn jedesmal die NVMe
wechseln ist mir dann doch zu umständlich. Und bisher reicht mir das
Windows 7 auf dem noch benutzten Laptop noch aus - eventuell wird es
dann darauf "degradiert" (aber das geht halt nicht ewig).


ciao, Dirk

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dirk S. - 03.07.24, 19:33:41 CEST:

Ich hatte die Hoffnung, dass ich "einfach" irgendwie den
LUKS-"Container" rüberkopieren und weiter nutzen kann.

Hmmm, das könnte auch gehen. Habe ich aber nie gemacht.

Würde auch viele leere Daten rüberkopieren. Das LVM darin und die
Dateisysteme darin sind ja nicht komplett voll.

--
Martin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Frank Miller - 03.07.24, 19:52:47 CEST:

Dirk S. wrote:

Guten Morgen!

Ich möchte mein aktuell auf Laptop-A genutztes Debian Stable auf
Laptop-B klonen/kopieren, weil Laptop-B Laptop-A ersetzen soll.

Die SSD auf A hat grob (die fdisk-Auflistung steht am Ende):

Wie wäre es mit Clonezilla? https://clonezilla.org/

Habe ich auch überlegt, aber dann nicht mehr geschrieben.

Das könnte den LUKS-Container vielleicht 1:1 rüberkopieren. Aber inwiefern
es dabei auch die Größe eines LUKS-Containers ändern kann usw. Keine
Ahnung. Weiß nicht, wie weit Clonezilla LUKS explizit unterstützt.

--
Martin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 03 Jul 2024 20:08:40 +0200, Martin Steigerwald
<martin@lichtvoll.de> wrote:

Dirk S. - 03.07.24, 19:33:41 CEST:

Ich hatte die Hoffnung, dass ich "einfach" irgendwie den
LUKS-"Container" rüberkopieren und weiter nutzen kann.

Hmmm, das könnte auch gehen. Habe ich aber nie gemacht.

Das geht. Mache ich ständig.

Grüße
Marc
--
---------------------------------------------------------------------------- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 3 Jul 2024 17:20:48 +0200, Joachim Hussong
<linux@ejr-online.de> wrote:

Nur eine Person sprach sich vehement dagegen aus. Alle anderen haben
Dual Boot im Einsatz gehabt und damit keine Probleme zu berichten.

Die haben halt nicht hinreichend viel Erfahrung.

Grüße
Marc
--
---------------------------------------------------------------------------- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Marc Haber - 04.07.24, 08:25:31 CEST:

2. Anlegen des LUKS-Gerätes, z.B. mit:

cryptsetup luksFormat --key-size 512 --hash sha512 --iter-time 5000 >PARTITION

Mindestens in Debian unstable würde ich mich da eher auf die Defaults
von cryptsetup verlassen. Am Ende werden die noch schärfer als das,
was man im finger memory hat und dann ist man am Ende weniger sicher
als der Default.

Meine letzte Installation hatte --iter-time 5000 nicht. Bezweifle fast,
dass das mittlerweile der Standard ist. Nicht jeder möchte 5 Sekunden
warten. Bezüglich --key-size und --hash… ja, wie geschrieben, kann sein, dass es da mittlerweile bessere Einstellungen gibt.

Interessanterweise wurde ja zuletzt login von SHA512 auf YesCrypt
umgestellt. PAM verwendet ja bereits seit Bullseye YesCrypt. Soweit es für LUKS bezüglich SHA512 um das Speichern von Passwörtern geht, würde
YesCrypt ja laut den Veröffentlichungshinweisen für Debian 11 Wörterbuch- basierte Angriffe erschweren.

Aber jetzt habe ich gerade mal geschaut, damit wir mal aus dem Spekulieren heraus kommen: Laut "cryptsetup --help" für Version 2.7.2 lege ich auf die Standard-Parameter mit obigen Aufruf noch ordentlich was oben drauf!

5. Kopieren der Daten mit "rsync -aAHXPS --numeric-ids" oder ähnlich. >"--numeric-ids" ist sehr wichtig beim Kopieren übers Netzwerk via GRML >oder einem anderen Live Linux.

Und was ist dann mit den Capabilities und anderen extended Attributes?
Wenn auf dem kopierten System ping nicht mehr geht, sind sie nicht mit
rüber gekommen.

--xattrs, -X preserve extended attributes

Schaue Dir die Optionen vom obigen rsync genau an. Da ist meines Wissens
so ziemlich alles mit dabei, was zusätzlich gespeichert sein kann. Ich verwende "-aAHXS" ja nicht einfach nur, weil ich gerne Buchstaben tippe.

Der Befehl "ping" geht demnach auf dem kopierten System einwandfrei. Habe
ich schon mehrfach probiert. Zuletzt als gestern mal wieder mein Provider etwas arg langsam war.

--
Martin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Moin Marc!

Marc Haber schrieb am Donnerstag, den 04. Juli 2024:

Bitte kein Dualboot. Wenn es irgend geht.

Ist das mittlerweile wirklich so schmerzhaft? :)

Es war immer schmerzhaft, und es gibt inzwischen sinnvolle
Alternativen. VMs kosten nix, weitere Festplatten wenig und wenn es
partout sein müsse gibt es alte Notebooks für unter 200 Euro.

Hmm, fast jeder Rechner bei mir Dualboot installiert - aber im
Nachhinein stelle ich fest, das ich das nicht bräuchte weil ich
inzischen ein OS auf dem Rechner benutze. Auf meinem aktuellen Rechner
nutze ich tatsächlich via VM das andere OS wenn ich es benötige und
mounte dafür die physische /home-Partition rein ;)

Aber ich finde es aktuell recht entspannt, grub für Multiboot zu
nutzen, unter anderem weil grub die os-prober mitbringt und
sinnvolle(!) defaults kennt. Und wenn man will kann man grub in grub verschachteln; davon rate ich aber ab.

Aber um qubes-os zu testen, nebenbei ein Windows und ein Linux zu
haben mit dem man arbeitet ist durchaus spannend; gerade weil Qubes
Xen mitbringt und man da auf Hardware arbeiten möchte.

Qubes geht auch mit Secureboot; gerade mit Debian. Das ist allerdings
ein höherer Aufwand wenn man mehr selbst machen möchte; ein eigener
Kernel ist dann schon eine Herausforderung. Daher habe ich das eher
aufgegeben, allerdings bringt _mir_ das Secure-Boot auch nicht ein
Mehr an Sicherheit.

Von daher: Meiner Meinung nach ist Dualboot inzwischen durchaus
ausgereift, aber dank VM und anderer Virtualisierung kaum noch
notwendig.

best regards, Hanno Wagner
--
| Hanno Wagner | Member of the HTML Writers Guild | Rince@IRC |
| Eine gewerbliche Nutzung meiner Email-Adressen ist nicht gestattet! |
| 74 a3 53 cc 0b 19 - we did it! | Generation @ |

#"The following recipient(s) could not be reached:
# abuse@msn.com On Wed, 2 Oct 96 15:31:50 UT
# The Microsoft Network member inbox is full." -- found by stesch

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 4 Jul 2024 09:21:32 +0200, Ulf Volmer <u.volmer@u-v.de> wrote:

Am 7/4/24 um 8:25 AM schrieb Marc Haber:

On Wed, 03 Jul 2024 16:51:23 +0200, Martin Steigerwald
<martin@lichtvoll.de> wrote:

5. Kopieren der Daten mit "rsync -aAHXPS --numeric-ids" oder ähnlich.
"--numeric-ids" ist sehr wichtig beim Kopieren übers Netzwerk via GRML
oder einem anderen Live Linux.

Und was ist dann mit den Capabilities und anderen extended Attributes?

Wofür die Option '-H' bei rsync wohl da oben stehen mag?

unvollHständig.

--
---------------------------------------------------------------------------- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 04 Jul 2024 09:25:08 +0200, Martin Steigerwald
<martin@lichtvoll.de> wrote:

Marc Haber - 04.07.24, 08:25:31 CEST:

2. Anlegen des LUKS-Gerätes, z.B. mit:

cryptsetup luksFormat --key-size 512 --hash sha512 --iter-time 5000
PARTITION

Mindestens in Debian unstable würde ich mich da eher auf die Defaults
von cryptsetup verlassen. Am Ende werden die noch schärfer als das,
was man im finger memory hat und dann ist man am Ende weniger sicher
als der Default.

Meine letzte Installation hatte --iter-time 5000 nicht. Bezweifle fast,
dass das mittlerweile der Standard ist.

Im Standard wird die Anzahl der Iterationen abhängig vom vorgefundenen Prozessor ermittelt. Glaube ich. Oder hoffe ich.

Interessanterweise wurde ja zuletzt login von SHA512 auf YesCrypt
umgestellt. PAM verwendet ja bereits seit Bullseye YesCrypt. Soweit es für >LUKS bezüglich SHA512 um das Speichern von Passwörtern geht, würde >YesCrypt ja laut den Veröffentlichungshinweisen für Debian 11 Wörterbuch- >basierte Angriffe erschweren.

Und Ansible kann es bis heute nicht, weswegen ich in meiner Flotte
weiterhin SHA512 verwenden muss.

Aber jetzt habe ich gerade mal geschaut, damit wir mal aus dem Spekulieren >heraus kommen: Laut "cryptsetup --help" für Version 2.7.2 lege ich auf die >Standard-Parameter mit obigen Aufruf noch ordentlich was oben drauf!

Nur beim Hash, LUKS mit XTS hat verdoppelte 256 bit. Ich würde mich
selbst für vermessen halten, wenn ich mir zutrauen würde, hier eine
bessere Auswahl als die Experten treffen zu können.

5. Kopieren der Daten mit "rsync -aAHXPS --numeric-ids" oder ähnlich.
"--numeric-ids" ist sehr wichtig beim Kopieren übers Netzwerk via GRML
oder einem anderen Live Linux.

Und was ist dann mit den Capabilities und anderen extended Attributes?
Wenn auf dem kopierten System ping nicht mehr geht, sind sie nicht mit
rüber gekommen.

--xattrs, -X preserve extended attributes

Schaue Dir die Optionen vom obigen rsync genau an. Da ist meines Wissens
so ziemlich alles mit dabei, was zusätzlich gespeichert sein kann.

Und nach meiner Erfahrung reicht das leider nicht. Das mag sich in den
letzten Monaten geändert haben.

Der Befehl "ping" geht demnach auf dem kopierten System einwandfrei. Habe
ich schon mehrfach probiert. Zuletzt als gestern mal wieder mein Provider >etwas arg langsam war.

Na dann.

Grüße
Marc
--
---------------------------------------------------------------------------- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 4 Jul 2024 10:14:54 +0200, Joachim Hussong
<linux@ejr-online.de> wrote:

Am 04.07.24 um 09:54 schrieb Hanno 'Rince' Wagner:

Von daher: Meiner Meinung nach ist Dualboot inzwischen durchaus
ausgereift, aber dank VM und anderer Virtualisierung kaum noch
notwendig.

Dual Boot ist schon lange ausgereift.

So weit wie das Flickwerk ausgereift sein kann. Man findet das immer
nur gut bis es mal schiefgegangen ist.

Wenn man einen Rechner kauft, ist meist Windows dabei, d.h. man hat eine >Lizenz dafür. Warum sollte man die wegschmeißen?

Das klingt mir sehr nach "ich habe eine Flatrate, also lass ich über
nacht die Zeitansage laufen".

Grüße
Marc
--
---------------------------------------------------------------------------- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Marc Haber - 04.07.24, 13:05:04 CEST:

Und was ist dann mit den Capabilities und anderen extended
Attributes?

Wofür die Option '-H' bei rsync wohl da oben stehen mag?

unvollHständig.

Auch das ist nicht sonderlich konkret.

Nun die Manpage schreibt, dass rsync auch mit Root-Rechten standardmäßig Attribute, die auf "system.*" passen, nicht kopiert. Insoweit das ACLs
meint, dafür verwende ich "-A".

So oder so, für die Ping-Capability reicht es definitiv:

% getcap /usr/bin/ping
/usr/bin/ping cap_net_raw=ep

Und auch sonst fehlte mir bislang nichts.

Falls Du ein *konkretes*, *praktisches* Beispiel hast, wo mit
"rsync -aAHXS" etwas fehlt, dann gerne her damit. Wo gab es damit bei Dir genau Probleme? (Minus Datenschutz-technisch sensitive Angaben.)

Ansonsten betrachte ich das Thema für mich als abgeschlossen.

--
Martin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Marc Haber - 04.07.24, 13:04:44 CEST:

Meine letzte Installation hatte --iter-time 5000 nicht. Bezweifle fast, >dass das mittlerweile der Standard ist.

Im Standard wird die Anzahl der Iterationen abhängig vom vorgefundenen Prozessor ermittelt. Glaube ich. Oder hoffe ich.

Hast Du den Optionsnamen "--iter-time" gelesen und was ich geschrieben
habe? Und dann mal nach "cryptsetup --help" wirklich angeschaut? Da steht Iterationszeit 2000. Ich verwende 5000. Deswegen dauert es dann ja auch 5 Sekunden, bis ein Passwort geprüft ist. Wie ich ebenfalls schrieb.
Vielleicht ist 5000 auf einem Laptop mit AMD Ryzen 7 PRO 8840U paranoid.
Die Manpage deutet das an :) Aber ich erinnere mich noch gut an die
Zeiten, wo für SSH längere RSA-Schlüssel-Längen als der Standard empfohlen waren.

Ich frage mich ja gerade schon, warum ich mir die Mühe mache, das alles
zu schreiben. Aber ich weigere mich, herum zu spekulieren, wenn
"cryptsetup --help" und der Optionsname und die Manpage doch super
eindeutig sind, wie das mit der "--iter-time" gemeint ist und was der Standard-Wert ist.

Aber jetzt habe ich gerade mal geschaut, damit wir mal aus dem
Spekulieren heraus kommen: Laut "cryptsetup --help" für Version 2.7.2
lege ich auf die Standard-Parameter mit obigen Aufruf noch ordentlich
was oben drauf!

Nur beim Hash, LUKS mit XTS hat verdoppelte 256 bit. Ich würde mich
selbst für vermessen halten, wenn ich mir zutrauen würde, hier eine
bessere Auswahl als die Experten treffen zu können.

Für Optionen, die ich nicht angebe, wird LUKS die Standard-Werte
verwenden, auch wenn ich einige Optionen angebe. Zumindest ging ich
bislang davon aus. Macht es ja auch, wenn man keine Optionen angibt. Falls
Du das sicher anders weißt, dann informiere mich bitte. Und dass SHA512 sicherer als SHA256 ist… davon gehe ich auch aus. Debian hat ja für die Passwörter auch SHA512 verwendet und nicht SHA256.

Nach allem, was ich sehe und verstehe, habe ich auf die Standard-Werte
noch etwas oben drauf gelegt.

Ja, ich bin kein Kryptologe, aber ich hab mir bei den Einstellungen schon
auch was gedacht. Ich denke, ich hab die Idee dazu aus dem Arch Wiki. Und
da sind meiner Einschätzung nach auch Leute, die sich was dabei gedacht haben.

Du kannst es ja so machen, wie Du es für sinnvoll hältst. Ich mache es so, wie ich es für sinnvoll halte. Insbesondere steht uns auch frei, unterschiedliche Quellen heran zu ziehen und dann selbst einzuschätzen,
wie wir es machen. Cryptsetup-Upstream, Debian, Arch Wiki… Weil am Ende bleibt mir nichts Anderes übrig, als mich in Bezug auf Krypto-
Einstellungen auf Empfehlungen zu verlassen. Oder hast Du verstanden, wie SHA512, Yescrypt und Co *genau* funktionieren? Ich nicht, auch wenn ich
einen deutlich älteren und einfacheren Algorithmus tatsächlich mal zu verstehen glaubte, als ich eine sehr gute Beschreibung davon las. Ich
wollte dann Schulungsfolien dazu erstellen. Und dann war ich mir nicht
mehr sicher, ob ich es wirklich verstanden hab. Zumindest wäre mir schwer gefallen, es in einfachen Worten zu erklären.

Dass z.B. die Standard-Werte für SSH weit hinter dem zurückbleiben, was viele IMHO gute Quellen empfehlen, ist auch klar. Oder auch für Nginx oder Apache, Postfix, Dovecot. Ich habe dort überall nach Empfehlungen, die mir sinnig erschienen nach geschärft. Mozilla TLS-Leute, ssh-audit, lynis,
wohl veraltet Applied Crypto Hardening. Und zwar genau da, wo ich es nachvollziehen konnte und mir sinnvoll erschien. Also nicht immer alles – was bei Lynis ja schon auch echt viel wäre. Du vertraust dem Cryptsetup- Upstream, den Debian-Paketbetreuern. Ich habe zusätzliche Quellen zu Rate gezogen. Wo ist also jetzt genau der Unterschied? Wir beide verlassen uns
auf Empfehlungen von anderen Leuten! Natürlich ist es wichtig, nicht blind alles zu übernehmen, was irgendwo im Internet geschrieben steht. Und
erneut zu prüfen, was aktuell sinnig ist, macht auch immer wieder Sinn.
Danke für die Erinnerung. Ich habe geprüft anhand der aktuellen Standardwerte und bleibe bei meiner Einschätzung.

Ich habe ja von Anfang an geschrieben, dass es vielleicht bessere
Parameter gibt. Also ich verstehe die ganze Diskussion hier gerade nicht
mehr. Mache es doch so wie Du es für sinnvoll hältst! Mich hast Du jedenfalls bislang nicht überzeugt, anders vorzugehen, als ich es bisher gemacht habe.

--xattrs, -X preserve extended attributes

Schaue Dir die Optionen vom obigen rsync genau an. Da ist meines
Wissens so ziemlich alles mit dabei, was zusätzlich gespeichert sein
kann.

Und nach meiner Erfahrung reicht das leider nicht. Das mag sich in den letzten Monaten geändert haben.

Konkret? Wie bei Dual Boot schreibst Du einfach es geht nicht. Aber was
genau nicht geht, das dürfen die geneigten Leser raten? Ich finde da
konkrete Fakten durchaus mal ganz nett.

Ich hatte damit noch nie ein Problem, insofern das Ziel-Dateisystem mit
den Optionen klar kommt, was z.B. bei FAT32 und ExFAT nicht der Fall ist.

Ich habe schon so oft mit "rsync -aAHXS" kopiert, dass ich es nicht mehr zählen kann. Ich hab da bislang noch nie eine Spur irgendeines Problems
damit bemerkt.

Ciao,
--
Martin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Wed, Jul 03, 2024 at 08:08:40PM +0200 schrieb Martin Steigerwald:

Würde auch viele leere Daten rüberkopieren. Das LVM darin und die Dateisysteme darin sind ja nicht komplett voll.

Gibt kein LVM hier.

ciao, Dirk

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Thu, Jul 04, 2024 at 08:19:43AM +0200 schrieb Marc Haber:

On Wed, 03 Jul 2024 20:08:40 +0200, Martin Steigerwald
<martin@lichtvoll.de> wrote:

Dirk S. - 03.07.24, 19:33:41 CEST:

Ich hatte die Hoffnung, dass ich "einfach" irgendwie den
LUKS-"Container" rüberkopieren und weiter nutzen kann.

Hmmm, das könnte auch gehen. Habe ich aber nie gemacht.

Das geht. Mache ich ständig.

Prima! Und wie passe ich das an, wenn die Größe der neuen Partition
größer als die der alten ist?

ciao, Dirk

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Jan, hi.

Jan-Henrik Koch - 03.07.24, 21:50:53 CEST:

Ich mache meine Backups regelmäßig mit Clonezilla. Meine Hauptfestplatte
ist LUKS-verschlüsselt. Clonezilla läuft bei mir über Netboot an, fragt
dann nach dem Passwort zum Einhängen und läuft durch.
Clonezilla kann wohl auch Images im DD-Abbildmodus schreiben, dann muss
aber der ganze LUKS-Container vollständig kopiert werden.

Das heißt Clonezilla kann auch die Dateien in einem Dateisystem direkt kopieren? Mit "rsync" oder auf anderem Weg. Oder arbeitet es mit
speziellen Werkzeugen für bestimmte Dateisysteme, die leere Blöcke
weglassen, wie "xfs_copy"?

Da ich alles immer direkt auf Befehlszeile gemacht habe, habe ich mich
bislang nicht wirklich eingehend mit Clonezilla beschäftigt.

Danke,
--
Martin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Wed, Jul 03, 2024 at 09:50:53PM +0200 schrieb Jan-Henrik Koch:

Wenn Du möchtest, kann ich gerne mal ein Fujitsu Lifebook T901 (müsste doch epochenähnlich zu deinem Altgerät sein?) imagen und das Ganze testen.

Ich würde da bestimmt nicht ablehnen, wenn mir jemand so ein Angebot
macht ;-)

ciao, Dirk

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 4 Jul 2024 13:36:34 +0200, Ulf Volmer <u.volmer@u-v.de> wrote:

Magst Du mal ausführen, was bei -S bitte unvollständigt sein soll?

Kann ich leider im Moment nicht, ich habe nur angeregt nach
erfolgreicher Kopie beim offensichtlichsten Kandidaten, ping,
nachzuschauen ob die Capabilities mitgekommen sind.

Grüße
Marc
--
---------------------------------------------------------------------------- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 04 Jul 2024 13:35:21 +0200, Martin Steigerwald
<martin@lichtvoll.de> wrote:

Ich frage mich ja gerade schon, warum ich mir die Mühe mache, das alles
zu schreiben. Aber ich weigere mich, herum zu spekulieren, wenn
"cryptsetup --help" und der Optionsname und die Manpage doch super
eindeutig sind, wie das mit der "--iter-time" gemeint ist und was der >Standard-Wert ist.

Ach weißt Du, ich kann meine Erfahrung auch für mich behalten, meine
Klappe halten und am besten unsubscriben.

Du musst mir ja nicht zustimmen, ich ergänze nur.

Du kannst es ja so machen, wie Du es für sinnvoll hältst. Ich mache es so, >wie ich es für sinnvoll halte.

Das will ich Dir auch nicht absprechen. Vieles ist eine Stilfrage.

Insbesondere steht uns auch frei,
unterschiedliche Quellen heran zu ziehen und dann selbst einzuschätzen,
wie wir es machen. Cryptsetup-Upstream, Debian, Arch Wiki… Weil am Ende >bleibt mir nichts Anderes übrig, als mich in Bezug auf Krypto-
Einstellungen auf Empfehlungen zu verlassen.

Und die Empfehlungen der Softwareautoren sind auch Empfehlungen, sonst
hätten sie das ja nicht als Default gesetzt. Ich plädiere nur, diesen Empfehlungen, die von denen kommen die die Software um die es geht MIT
ABSTAND am besten kennen, auch etwas Gehör zu geben.

Am Ende muss jeder für sich eine informierte Entscheidung treffen und
deswegen ist es wichtig auch unterschiedliche Standpunkte zu beachten.
Am Ende liest jemand in zehn Jahren das Archiv und nimmt dann die
Werte von heute.

Ich habe ja von Anfang an geschrieben, dass es vielleicht bessere
Parameter gibt. Also ich verstehe die ganze Diskussion hier gerade nicht >mehr. Mache es doch so wie Du es für sinnvoll hältst!

Natürlich. Möchtest Du auch dass ich meine Klappe halte? Das kannst Du
gerne haben.

Mich hast Du
jedenfalls bislang nicht überzeugt, anders vorzugehen, als ich es bisher >gemacht habe.

Mit diesem Vorhaben bin ich nie angetreten.

Konkret? Wie bei Dual Boot schreibst Du einfach es geht nicht. Aber was
genau nicht geht, das dürfen die geneigten Leser raten? Ich finde da >konkrete Fakten durchaus mal ganz nett.

Leider ist meine Dokumentation nicht gut genug dass ich das jetzt aus
dem Ärmel ziehen könnte. Und um das jetzt im Detail auszuforschen
fehlt mir die Motivation. Sonst hätte ich das damals gebloggt.

Grüße
Marc
--
---------------------------------------------------------------------------- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ulf Volmer - 04.07.24, 17:30:51 CEST:

Am 7/4/24 um 4:49 PM schrieb Marc Haber:

On Thu, 4 Jul 2024 13:36:34 +0200, Ulf Volmer <u.volmer@u-v.de> wrote:

Magst Du mal ausführen, was bei -S bitte unvollständigt sein soll?

Kann ich leider im Moment nicht, ich habe nur angeregt nach
erfolgreicher Kopie beim offensichtlichsten Kandidaten, ping,
nachzuschauen ob die Capabilities mitgekommen sind.

Danke, dass Du das richtiggestellt hast.

Hätte man missverstehen können.

Es wäre immer noch "-X" für die erweiterten Attribute. "-S" ist für Sparse-Dateien. Oder habe ich missverstanden über was ihr diskutiert?

--
Martin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)