staging.inyokaproject.org

Hallo zusammen,
nachdem mein PC mit seiner "Mate18.04" Installation plötzlich SEHR langsam wurde, habe ich mich entschlossen, die schon länger geplante Neuinstallation von Ubuntu 18.4.04 jetzt durchzuführen und die "alte" Installation als 2.System (vorläufig) weiter zur Verfügung zu behalten.

Gestern habe ich meine SSD[126GB / sda] leer geräumt und Ubuntu18.04 frisch mit dem LifeSystem mit LVM/Luks installiert. Das "swap" wurde dort automatisch angelegt. sdb ist die SSD[sdb. 500GB] auf der das bisherige, alte System liegt. sdc ist eine HDD, auf der ich Swap, mein "home" und eine Partition für Virtualbox abgelgt habe.

Leider habe ich nicht gefunden, wie ich die neue "root" gleich auf 30GB dimensionieren hätte können - es wurde alles (außerdem autom. erzeugten swap) "verwendet. Also habe ich nach dieser ANLEITUNG mein "/dev/mapper/ubuntu--vg-root" auf 30GB verkleinert und dann nach Logical Volume Manager (Abschnitt „Administration eines LVM“) zwei weitere "LVs" in dem frei gewordenen Bereich angelegt: (/dev/mapper/ubuntu--vg-Mate18.04) und (/dev/mapper/ubuntu--vg-SteHome) und mittels rsync die alte Systempartition(sdb1) in das neue LV (ubuntu--vg-Mate18.04) kopiert.

Mein Systems sieht seitdem SO aus:

~$ sudo blkid
[sudo] Passwort für stefan: 
/dev/mapper/sda5_crypt: UUID="QMnOk9-pq7N-JWYX-eef9-7Rx1-E3V7-w0uUO0" TYPE="LVM2_member"
/dev/mapper/ubuntu--vg-root: UUID="89dce358-166b-442f-977e-01b7b314d8db" TYPE="ext4"
/dev/loop0: TYPE="squashfs"
/dev/loop1: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop3: TYPE="squashfs"
/dev/loop4: TYPE="squashfs"
/dev/loop5: TYPE="squashfs"
/dev/loop6: TYPE="squashfs"
/dev/loop7: TYPE="squashfs"
/dev/sda1: UUID="58c83153-3c59-445b-9aae-e2724fb8dd88" TYPE="ext4" PARTUUID="176bef1c-01"
/dev/sda5: UUID="de247f5d-9b4e-4c6d-a090-18843bf808c2" TYPE="crypto_LUKS" PARTUUID="176bef1c-05"
/dev/sdb1: LABEL="Mate18.04" UUID="0bf920bb-eaad-40eb-90d8-3eb16d7884c9" TYPE="ext4" PARTUUID="bf77df4f-01"
/dev/sdc1: UUID="fad598f4-34ec-4edb-9849-b6d044c35e8f" TYPE="swap" PARTUUID="865fea76-d27c-4c4c-8596-9686e78fefba"
/dev/sdc2: LABEL="0_HDD(VBox)" UUID="61421da9-883e-43b2-b4b2-67f9390fcc56" TYPE="ext4" PARTUUID="930fae0a-04b2-47e1-a3f3-00a91a66f4ad"
/dev/sdc3: LABEL="0_StePc08-Home" UUID="ec943b66-96b3-4b2c-981c-8172b8dfd016" TYPE="ext4" PARTUUID="f4cd7358-ac71-42ff-a6db-a2e3c426419d"
/dev/mapper/ubuntu--vg-swap_1: UUID="8ed57e9d-53f4-4d34-a58d-47c9824cd4d6" TYPE="swap"
/dev/mapper/ubuntu--vg-Mate18.04: UUID="860f17cf-7703-4156-8cfe-43bbc94e621b" TYPE="ext4"
/dev/mapper/ubuntu--vg-SteHome: UUID="fee5b921-042e-4bec-8a81-a2eb24db35dc" TYPE="ext4"
/dev/loop8: TYPE="squashfs"
/dev/loop9: TYPE="squashfs"
/dev/loop10: TYPE="squashfs"
/dev/loop11: TYPE="squashfs"
/dev/loop12: TYPE="squashfs"
/dev/loop13: TYPE="squashfs"
/dev/loop14: TYPE="squashfs"
/dev/loop15: TYPE="squashfs"
/dev/loop16: TYPE="squashfs"
/dev/loop17: TYPE="squashfs"
/dev/loop18: TYPE="squashfs"
/dev/sdd: LABEL="Tuxedo" UUID="7FE1BC8E229DBB65" TYPE="ntfs" PTTYPE="dos"
/dev/sdb2: PARTUUID="bf77df4f-02"
/dev/loop19: TYPE="squashfs"
/dev/loop20: TYPE="squashfs"
/dev/loop21: TYPE="squashfs"
/dev/loop22: TYPE="squashfs"
/dev/loop23: TYPE="squashfs"
/dev/loop24: TYPE="squashfs"
/dev/loop25: TYPE="squashfs"

Das neue System funktioniert soweit problemlos.

Um zukünftig sowohl mit "Ubuntu18.4.04" als auch "Mate18.04" starten/arbeiten zu können habe ich //wiki.ubuntuusers.de/GRUB_2/Reparatur/#Reparatur im laufenden System:
a) die aktuelle GrubVersion mit "dpkg --list | grep grub" überprüft, dann
b) das "bootinfoscript" installiert und ausgeführt und
c) "versucht" die Grub2-Pakete mit "sudo update-grub" zu aktualisieren.

Das hat auch soweit (für das "neue" System) funktioniert, das neue System lässt sich problemlos starten und GRUB hat auch das "neue" Mate18.04 gefunden
ABER: wenn ich das "neue"(alte) System "Mate18.04" auswähle, bekomme ich die Fehlermeldung Sie müssen zuerst den Kernel laden ...
Ich vermute, dass GRUB nicht gelernt hat, dass auch für "Mate18.04" erst LVM entsperrt werden muss.

Frage:
A) wie kann ich Grub beibringen, dass sowohl die "root" (:= Ubuntu18.4.04) als auch die "Mate18.04" in LVM stehen - sprich die Platte erst entsperrt werden muss?

B) Wie kann ich meine alte (ziemlich große) "Home"-Partition auch in LVM übertragen?

Wie immer - VIELEN DANK für eure Hilfestellungen ...
Herzlichen Grüß, Stefan

Das "swap" wurde dort automatisch angelegt

Wo? Im LVM? Da gehört er auch hin. Du solltest sicherstellen, dass der swap unter sdc1 nicht genutzt wird, da er unverschlüsselt ist (theoretische Sicherheitslücke).

Mein Systems sieht seitdem SO aus:

Ein herrliches Durcheinander, selbst wenn man die loops wegdenkt.

Wenn ich das richtig verstehe, hast du dein altes System innerhalb deines neuen Systems. Egal wo du das eingebunden hast bzw. einbinden wirst, erwartest du, dass unter /dev/mapper/ubuntu--vg-Mate18.04/boot nach dem startbaren Kernel gesucht wird und obwohl das alte System weder für Verschlüsselung, noch LVM konfiguriert war, es trotzdem startet. (?) Dir war wohl langweilig und konntest keine leichtere Herausforderung finden. 😉 😈

b) das "bootinfoscript" installiert und ausgeführt und

Und was steht da drin? Wurde die gut versteckte /boot gefunden?

fleet_street schrieb:

Das "swap" wurde dort automatisch angelegt

Wo? Im LVM? Da gehört er auch hin. Du solltest sicherstellen, dass der swap unter sdc1 nicht genutzt wird, da er unverschlüsselt ist (theoretische Sicherheitslücke).

JA - das andere "swap" ist deaktiviert und wird nach Abschluss des Umzugs aufgelöst.

Ein herrliches Durcheinander, selbst wenn man die loops wegdenkt.

STIMMT - weil ja das NEUE schon da ist und das alte noch nicht umgezogen - genau DA benötige ich Hilfe!

sda ist/wird die "neue" Installation. / sda1: "boot" / "sda2" ist der LVM-Bereich :⇒ "ubuntu-vg-*"
sdb ist die alte SDD, die nach dem Umzug das neue "home" werden soll. ("sdb1" habe ich mit rsync in "ubuntu-vg-Mate18.04" kopiert)
sdc ist die HDD, die (noch) das bisherige "home" beinhaltet. Das "sdc1" (altes "swap") ist deaktiviert.
ubuntu-vg-*: LV1: das neue "root" / LV2:"Mate18.04"(Kopie von sdb1) / LV3:"SteHome" (Platzhalter bis sdb frei ist) / LV4: aktuelles "swap"
... der Rest: USB-Sticks für das "Arbeiten"

Wenn ich das richtig verstehe, hast du dein altes System innerhalb deines neuen Systems. Egal wo du das eingebunden hast bzw. einbinden wirst, erwartest du, dass unter /dev/mapper/ubuntu--vg-Mate18.04/boot nach dem startbaren Kernel gesucht wird und obwohl das alte System weder für Verschlüsselung, noch LVM konfiguriert war, es trotzdem startet. (?) Dir war wohl langweilig und konntest keine leichtere Herausforderung finden. 😉 😈

(Scherzkeks 😀 ) - in dem Grub-Startmenü (ganz am Anfang) steht die Partition "/dev/mapper/ubuntu--vg-Mate18.04/boot" zur Auswahl - also sollte Grub gefunden haben.
NUR - dort bekomme ich dann die Fehlermeldung: "Sie müssen zuerst den Kernel laden" ...

Und die Frage war: Wie bekomme ich es hin, dass das Grub für dieses System weiß, dass es in einem LVM-Bereich steht und seinen Startvorgang entsprechend anpasst...
Wie dann der Rest ins LVM übertragen werden kann, werde ich angehen, wenn "Mate18.04"(LVM) funktioniert ☺

b) das "bootinfoscript" installiert und ausgeführt und

Und was steht da drin? Wurde die gut versteckte /boot gefunden?

Yep - steht im Grub-Startmenü - ergo "gefunden" und im Bereich "sda1/grub/grub.cfg":
zum Vergleich: der Eintrag für die (funktionierende) "root"

menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-89dce358-166b-442f-977e-01b7b314d8db' {
	recordfail
	load_video
	gfxmode $linux_gfx_mode
	insmod gzio
	if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
	insmod part_msdos
	insmod ext2
	set root='hd0,msdos1'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  58c83153-3c59-445b-9aae-e2724fb8dd88
	else
	  search --no-floppy --fs-uuid --set=root 58c83153-3c59-445b-9aae-e2724fb8dd88
	fi
        linux	/vmlinuz-5.3.0-46-generic root=/dev/mapper/ubuntu--vg-root ro  quiet splash $vt_handoff
	initrd	/initrd.img-5.3.0-46-generic

und der für "/dev/ubuntu-vg/Mate18.04" (auch in "sda1/grub/grub.cfg"):

menuentry 'Ubuntu 18.04.4 LTS (18.04) (auf /dev/mapper/ubuntu--vg-Mate18.04)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-860f17cf-7703-4156-8cfe-43bbc94e621b' {
	insmod part_msdos
	insmod cryptodisk
	insmod luks
	insmod gcry_rijndael
	insmod gcry_rijndael
	insmod gcry_sha256
	insmod lvm
	insmod ext2
	set root='lvmid/DMZQVJ-k4iB-WovZ-aQwg-fchc-B1AN-o7D120/d7PNzy-DGOb-OH2p-LR7r-IlZF-HdjI-cnCZFe'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint='lvmid/DMZQVJ-k4iB-WovZ-aQwg-fchc-B1AN-o7D120/d7PNzy-DGOb-OH2p-LR7r-IlZF-HdjI-cnCZFe'  860f17cf-7703-4156-8cfe-43bbc94e621b
	else
	  search --no-floppy --fs-uuid --set=root 860f17cf-7703-4156-8cfe-43bbc94e621b
	fi
	linux /boot/vmlinuz-5.3.0-46-generic root=UUID=0bf920bb-eaad-40eb-90d8-3eb16d7884c9 ro quiet splash $vt_handoff
	initrd /boot/initrd.img-5.3.0-46-generic

(die RESULTS.txt ist sehr umfangreich und ich überblicke nicht, ob darin auch sensible Informationen stehen)

Danke und Gruß
Stefan

Hallo StefanP,

Poste bitte mal die Ausgaben von:

sudo parted -l
sudo fdisk -l

Gruss Lidux

Das Projekt ist sicher spannend, ein unverschlüsseltes System in LUKS, LVM zu packen und schauen, was man alles ändern muss, damit es startet. Die Frage, die ich mir dabei stelle, ist natürlich „Wozu das Ganze?". Du möchtest deine Partitionen sauber einteilen und das Geasmtsystem aufräumen und es bedarf nun grösserer Anstrengungen. Und am Ende ist das Ergebnis dieser Aktion dir wieder ein Klotz am Bein. Manchmal muss man altes auch hinter sich lassen.

Selbst wenn du das alte unbedingt brauchst. Die Liste der installierten Pakete sichern, die Einstellungen aus /etc und /home ebenfalls und in ein frisch installiertes System einspielen geht sicher schneller.

jm2c

Noch eins. Ich habe damit keine Erfahrung und kann hoffentlich einen Schubs in die richtige Richtung geben.

Zu der Bootsituation:

Immerhin sind die Module für LUKS und LVM. Was mir auffällt, ist folgendes:

menuentry 'Ubuntu 18.04.4 LTS (18.04) (auf /dev/mapper/ubuntu--vg-Mate18.04)' – {
…
	linux /boot/vmlinuz-5.3.0-46-generic root=UUID=0bf920bb-eaad-40eb-90d8-3eb16d7884c9 ro quiet splash $vt_handoff
…

Das ist die UUID von /dev/sdb1. Vielleicht, weil /dev/mapper/ubuntu--vg-Mate18.04/etc/fstab darauf verweist(?).

Solltest du es schaffen, dass das „spezielle“ System bootet, sollte es entweder nie den Grub schreiben oder du musst dran denken, den GRUB darauf vor zu bereiten, dass es keine unverschlüsselte /boot gibt. → https://forum.ubuntuusers.de/post/8669683/

Lidux schrieb:

...

sudo parted -l
sudo fdisk -l

kann ich das auch vom "neuen" root aus erstellen oder sollte ich mit dem "alten" System (sdb1:Mate18.04) neu starten?

LG Stefan

SO - ich kann wieder in das "alte" System ☺:

fleet_street schrieb:

Das "swap" wurde dort automatisch angelegt

Wo? Im LVM? Da gehört er auch hin. Du solltest sicherstellen, dass der swap unter sdc1 nicht genutzt wird, da er unverschlüsselt ist (theoretische Sicherheitslücke).

Ja - dort liegt das aktuelle "swap" - das unter sdc1 ist deaktiviert und wird natürlich entfernt, wenn die Umstellung abgeschlossen ist.

Mein Systems sieht seitdem SO aus:

Ein herrliches Durcheinander, selbst wenn man die loops wegdenkt.

YEP - ich weiß ... ist ja ein Zwischenstand.
OK - "sdb" hätte ich aus dem System herausnehmen können (oder sollen) - ich muss es (trotz der Probleme) noch solange einsetzen, bis ich über "/dev/mapper/ubuntu--vg-Mate18.04" starten kann.
Danach wird sdb komplett frei gemacht und soll dann das zukünftige "/home/stefan" werden.

Wenn ich das richtig verstehe, hast du dein altes System innerhalb deines neuen Systems. Egal wo du das eingebunden hast bzw. einbinden wirst, erwartest du, dass unter /dev/mapper/ubuntu--vg-Mate18.04/boot nach dem startbaren Kernel gesucht wird und obwohl das alte System weder für Verschlüsselung, noch LVM konfiguriert war, es trotzdem startet. (?)

Genau darum geht es ja - ich will einen Weg finden, wie ich die Funktionalität des alten Systems in eine Neue mit LVM verschlüsselte übertragen kann.
Verstehe ich deine Frage richtig wenn ich darin ein wenig Ironie herauslese? Hmmm....

Dir war wohl langweilig und konntest keine leichtere Herausforderung finden. 😉 😈

ha ha ha ... SEHR LUSTIG ... 😉 hätte ich jetzt nicht so formuliert - aber - vielleicht hast du ja recht ☺ ...

fleet_street schrieb:

[...] Zu der Bootsituation:

Immerhin sind die Module für LUKS und LVM. Was mir auffällt, ist folgendes:

menuentry 'Ubuntu 18.04.4 LTS (18.04) (auf /dev/mapper/ubuntu--vg-Mate18.04)' – {
> …
> 	linux /boot/vmlinuz-5.3.0-46-generic root=UUID=0bf920bb-eaad-40eb-90d8-3eb16d7884c9 ro quiet splash $vt_handoff
> …

Das ist die UUID von /dev/sdb1. Vielleicht, weil /dev/mapper/ubuntu--vg-Mate18.04/etc/fstab darauf verweist(?).

... ist ein interessanter Ansatz - da werde ich mal genauer nachsehen ... WENN ICH MICH AN GRUB TRAUE ☺

Jetzt muß ich erst einmal die "täglichen" Pflichten nachholen .. dann soll es HIER weiter gehen ...

Herzlichen Dank fürs Mitdenken und HinweiseGeben und überhaupt ...
dass ich trotz Quarantäne nicht ganz so alleine wurstle - eine (fast) neue Wahrnehmung
Lieben Gruß Stefan

Meinen Beitrag vom 19. hast du nun zwei Mal beantwortet. 😉 (Schadet nicht 😀)

StefanP schrieb:

SO - ich kann wieder in das "alte" System ☺:

Wie das? Der Rest deiner Antwort lässt nicht darauf schließen. Oder meinst du das unverschlüsselte Alte?

Das ist die UUID von /dev/sdb1. Vielleicht, weil /dev/mapper/ubuntu--vg-Mate18.04/etc/fstab darauf verweist(?).

... ist ein interessanter Ansatz - da werde ich mal genauer nachsehen ... WENN ICH MICH AN GRUB TRAUE ☺

Ich hätte erst in der entsprechenden fstab nachgeschaut und würde GRUB nicht manuell editieren.

Übrigens: Für sudo parted --list ist es egal, von wo du es ausführst.

Ich bin jetzt erst einmal im "alten" System - kann deshalb nicht in den Bereich von LVM sehen.

Lidux schrieb:

Poste bitte mal die Ausgaben von:

sudo parted -l
sudo fdisk -l

DAS wird etwas Umfangreich ... denn ich habe mehrere HDD mit sehr vielen Daten... (und vmtl. auch Leichen)

zur Erklärung:
- sda (126GB SSD) ist die "neue" Struktur mit unverschlüsseltem "boot" [sda1] und LUKS/LVM [sda5] mit "root", "Mate18.04"(Neu), "SteHome",
- sdb (500GB SSD) enthält das alte"root" [sdb2] und freigeschaufelter Bereich. Die soll als Ganzes das zukünftige "home" werden.
- sdc (2TB HDD) Sonderpartition für Bilder, Videos etc
- sdd (2TB HDD) Sonderpartition für Datensicherungen, Downloads etc
- sde (2TB HDD) enthält das alte "swap"[sde1], das alte"home"[sde3] und [sde2], das meine Virtualbox-Daten enthält
- sdf ist ein USB-Stick zum zwischenspeichern von TempDaten
- sdg (2TB USB3-HDD) ist eine externe, mit LUKS verschlüsselte Platte für externe Datensicherungen

Im Rahmen der Aufräumaktion will ich:
a) alles im laufenden System verschlüsseln und die externen Datensicherungen in unverschlüsselten HDDs ablegen (diese liegen dann in einem separaten, abgeschlossenen Bereich)

der Plan zum weiteren Vorgehen:
a) das neue System (Ubuntu18.04.4) mit LUKS / LVM anlegen (funktioniert)
b) das alte System (bereinigen und) in den LUKS/LVM-Bereich übertragen
c) die weiteren HDD bereinigen + leeren und als zusätzliche,externe Datensicherungen (unverschlüsselt) einsetzen.
d) eine automatische DatensicherungsStruktur einrichten ...
es ist mir NICHT langweilig und ich suche nicht das UbuntuAbenteuer ☺ - aber DAS alles steht schon länger an (sprich den gewachsenen Verhau aufräumen)

SO - nun die Ausgaben:

stefan@StePc08:~$ sudo parted -l
[sudo] Passwort für stefan: 
Modell: ATA SanDisk SDSSDP12 (scsi)
Festplatte  /dev/sda:  126GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: msdos
Disk-Flags: 

Nummer  Anfang  Ende   Größe  Typ       Dateisystem  Flags
 1      1049kB  768MB  767MB  primary   ext4         boot
 2      769MB   126GB  125GB  extended
 5      769MB   126GB  125GB  logical


Modell: ATA Samsung SSD 860 (scsi)
Festplatte  /dev/sdb:  500GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: msdos
Disk-Flags: 

Nummer  Anfang  Ende   Größe  Typ      Dateisystem  Flags
 1      1049kB  100GB  100GB  primary  ext4         boot
 2      100GB   500GB  400GB  primary


Modell: ATA ST2000DM001-9YN1 (scsi)
Festplatte  /dev/sdc:  2000GB
Sektorgröße (logisch/physisch): 512B/4096B
Partitionstabelle: msdos
Disk-Flags: 

Nummer  Anfang  Ende    Größe   Typ      Dateisystem  Flags
 3      1086MB  2000GB  1999GB  primary  ext4


Modell: ATA ST2000DM001-9YN1 (scsi)
Festplatte  /dev/sdd:  2000GB
Sektorgröße (logisch/physisch): 512B/4096B
Partitionstabelle: msdos
Disk-Flags: 

Nummer  Anfang  Ende    Größe   Typ      Dateisystem  Flags
 3      1086MB  2000GB  1999GB  primary  ext4


Modell: ATA ST2000DM001-9YN1 (scsi)
Festplatte  /dev/sde:  2000GB
Sektorgröße (logisch/physisch): 512B/4096B
Partitionstabelle: gpt
Disk-Flags: 

Nummer  Anfang  Ende    Größe   Dateisystem     Name  Flags
 1      1049kB  26,8GB  26,8GB  linux-swap(v1)
 3      26,8GB  1893GB  1866GB  ext4
 2      1893GB  2000GB  107GB   ext4


Modell: TUXEDO USB DISK (scsi)
Festplatte  /dev/sdf:  16,0GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: loop
Disk-Flags: 

Nummer  Anfang  Ende    Größe   Dateisystem  Flags
 1      0,00B   16,0GB  16,0GB  ntfs


Modell: ASMT 2105 (scsi)
Festplatte  /dev/sdg:  2000GB
Sektorgröße (logisch/physisch): 512B/4096B
Partitionstabelle: msdos
Disk-Flags: 

Nummer  Anfang  Ende    Größe   Typ      Dateisystem  Flags
 1      32,3kB  2000GB  2000GB  primary

und

stefan@StePc08:~$ sudo fdisk -l
Festplatte /dev/loop0: 7,9 MiB, 8306688 Bytes, 16224 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/loop1: 16 KiB, 16384 Bytes, 32 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/loop2: 297 MiB, 311455744 Bytes, 608312 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/loop3: 160,2 MiB, 167931904 Bytes, 327992 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/loop4: 33 MiB, 34557952 Bytes, 67496 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/loop5: 53,7 MiB, 56328192 Bytes, 110016 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/loop6: 2,1 MiB, 2224128 Bytes, 4344 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/loop7: 94,9 MiB, 99467264 Bytes, 194272 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/sda: 117,4 GiB, 126035288064 Bytes, 246162672 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
Festplattenbezeichnungstyp: dos
Festplattenbezeichner: 0x176bef1c

Gerät      Boot  Anfang      Ende  Sektoren  Größe Kn Typ
/dev/sda1  *       2048   1499135   1497088   731M 83 Linux
/dev/sda2       1501182 246161407 244660226 116,7G  5 Erweiterte
/dev/sda5       1501184 246161407 244660224 116,7G 83 Linux


Festplatte /dev/sdb: 465,8 GiB, 500107862016 Bytes, 976773168 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
Festplattenbezeichnungstyp: dos
Festplattenbezeichner: 0xbf77df4f

Gerät      Boot    Anfang      Ende  Sektoren  Größe Kn Typ
/dev/sdb1  *         2048 195522559 195520512  93,2G 83 Linux
/dev/sdb2       195522560 976773119 781250560 372,5G 83 Linux


Festplatte /dev/sdc: 1,8 TiB, 2000398934016 Bytes, 3907029168 Sektoren
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 4096 Bytes
E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes
Festplattenbezeichnungstyp: dos
Festplattenbezeichner: 0x000d26a3

Gerät      Boot  Anfang       Ende   Sektoren Größe Kn Typ
/dev/sdc3       2120584 3906011969 3903891386  1,8T 83 Linux


Festplatte /dev/sdd: 1,8 TiB, 2000398934016 Bytes, 3907029168 Sektoren
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 4096 Bytes
E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes
Festplattenbezeichnungstyp: dos
Festplattenbezeichner: 0x0009f045

Gerät      Boot  Anfang       Ende   Sektoren Größe Kn Typ
/dev/sdd3       2120584 3906011969 3903891386  1,8T 83 Linux




Festplatte /dev/sde: 1,8 TiB, 2000398934016 Bytes, 3907029168 Sektoren
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 4096 Bytes
E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes
Festplattenbezeichnungstyp: gpt
Festplattenbezeichner: 6AC4F907-0A31-479B-BEC8-626A07F4E6ED

Gerät          Anfang       Ende   Sektoren Größe Typ
/dev/sde1        2048   52430847   52428800   25G Linux Swap
/dev/sde2  3697313792 3907028991  209715200  100G Linux-Dateisystem
/dev/sde3    52430848 3697313791 3644882944  1,7T Linux-Dateisystem

Partitionstabelleneinträge sind nicht in Festplatten-Reihenfolge.


Festplatte /dev/sdf: 15 GiB, 16043212800 Bytes, 31334400 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
Festplattenbezeichnungstyp: dos
Festplattenbezeichner: 0x00000000


Festplatte /dev/loop8: 93,8 MiB, 98336768 Bytes, 192064 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/loop9: 55 MiB, 57614336 Bytes, 112528 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/loop10: 91,4 MiB, 95805440 Bytes, 187120 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/loop11: 33 MiB, 34570240 Bytes, 67520 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/loop12: 14,9 MiB, 15560704 Bytes, 30392 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/loop13: 174,8 MiB, 183242752 Bytes, 357896 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/loop14: 2,1 MiB, 2215936 Bytes, 4328 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/loop15: 156,7 MiB, 164290560 Bytes, 320880 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/loop16: 16 KiB, 16384 Bytes, 32 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/loop17: 95,6 MiB, 100233216 Bytes, 195768 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/loop18: 172 MiB, 180338688 Bytes, 352224 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/loop19: 48,3 MiB, 50642944 Bytes, 98912 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/loop20: 132 KiB, 135168 Bytes, 264 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/loop21: 14,9 MiB, 15589376 Bytes, 30448 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/loop22: 173,7 MiB, 182165504 Bytes, 355792 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/loop23: 54,8 MiB, 57479168 Bytes, 112264 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/loop24: 54,7 MiB, 57294848 Bytes, 111904 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/loop25: 35,3 MiB, 37027840 Bytes, 72320 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/loop26: 7,9 MiB, 8310784 Bytes, 16232 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/loop27: 95,6 MiB, 100204544 Bytes, 195712 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/loop28: 173,7 MiB, 182165504 Bytes, 355792 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/sdg: 1,8 TiB, 2000398934016 Bytes, 3907029168 Sektoren
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 4096 Bytes
E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes
Festplattenbezeichnungstyp: dos
Festplattenbezeichner: 0xb377dbd9

Gerät      Boot Anfang       Ende   Sektoren Größe Kn Typ
/dev/sdg1           63 3907029167 3907029105  1,8T 83 Linux

Partition 1 beginnt nicht an einer physikalischen Sektorgrenze.

habe fertig..... DANKE

fleet_street schrieb:

SO - ich kann wieder in das "alte" System ☺:

Wie das? Der Rest deiner Antwort lässt nicht darauf schließen. Oder meinst du das unverschlüsselte Alte?

GENAU!

Das ist die UUID von /dev/sdb1. Vielleicht, weil /dev/mapper/ubuntu--vg-Mate18.04/etc/fstab darauf verweist(?).

... ist ein interessanter Ansatz - da werde ich mal genauer nachsehen ... WENN ICH MICH AN GRUB TRAUE ☺

Ich hätte erst in der entsprechenden fstab nachgeschaut und würde GRUB nicht manuell editieren.

ok - habe nun alle (drei) fstab überprüft und angepasst ... jetzt stimmen alle Verweise auf die jew. UUID
Wenn die nun stimmen - sollte ich dann Grub nicht "aktualisieren/reparieren"? Bin mir da unsicher...

Danke und herzl. Gruß, Stefan

Übrigens: Für sudo parted --list ist es egal, von wo du es ausführst.

Danke ... Lernfaktor steigt ..☺

Entschuldige meine Neugier, aber du hast immer noch nicht verraten, warum du das „alte“ nun unbedingt noch in die Verschlüsselung retten möchtest. Warum schneidest du den alten Zopf nicht ab? Warum so kompliziert? 😇

StefanP schrieb:

ok - habe nun alle (drei) fstab überprüft und angepasst ... jetzt stimmen alle Verweise auf die jew. UUID
Wenn die nun stimmen - sollte ich dann Grub nicht "aktualisieren/reparieren"? Bin mir da unsicher...

„Wenn die stimmen“ klingt nicht nach „überprüft und angepasst“. Möchtest du die vielleicht vorher noch zeigen, bevor du im neuen, verschlüsselten System update-grub ausführst?

fleet_street schrieb:

Entschuldige meine Neugier, aber du hast immer noch nicht verraten, warum du das „alte“ nun unbedingt noch in die Verschlüsselung retten möchtest. Warum schneidest du den alten Zopf nicht ab? Warum so kompliziert? 😇

1. weil sich dort mein Tun der letzte 20 Jahre drängt - und ich nicht nicht alle Änderungen/Installationen mitgeschrieben/dokumentiert habe
und ich beim letzten Upgrade (von 14 auf 16) "neu aufgesetzt" und dabei ziemlich "Federn gelassen" hatte..

2. ich also neben dem "neu aufsetzen" das "alte" erreichbar und nutzbar halten will - solange, bis die "alten Funktionen" als "Neue Funktionen" verfügbar sind.
DANN soll die alte Struktur endgültig aufgelöst werden.

3. weil es mich interessiert, wie ich ein laufendes unverschlüsseltes System in ein verschlüsseltes übertragen kann...

Sind DAS genug Gründe?

StefanP schrieb:

ok - habe nun alle (drei) fstab überprüft und angepasst ... jetzt stimmen alle Verweise auf die jew. UUID
Wenn die nun stimmen - sollte ich dann Grub nicht "aktualisieren/reparieren"? Bin mir da unsicher...

„Wenn die stimmen“ klingt nicht nach „überprüft und angepasst“. Möchtest du die vielleicht vorher noch zeigen, bevor du im neuen, verschlüsselten System update-grub ausführst?

wenn ich schreibe "stimmen" dann heißt das: jeden Eintrag detailliert überpüft und ggf. korrigiert. Aber du kannst gerne noch einen Blick darauf werfen...
( Es steht oben im Kopf immer für welchen Bereich die fstab gilt)

# /etc/fstab: static file system information.
# StePc08b
# 2020-04-20 Ubuntu18.04.4 (NEU) in LUKS/LVM
#
# 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>

# /boot was on /dev/sda1 during installation
# /dev/sda1 				  	/boot				        ext4    defaults        0       2
UUID=58c83153-3c59-445b-9aae-e2724fb8dd88 	/boot           			ext4    defaults        0       2

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# 2020-04-19 Ste: LVM eingerichtet: 
# 	Partition "root" auf 30GB verkleinert, Partitionen "SteHome" und "Mate18.04"(:= Kopie des alten Systems) angelegt
# 	und in fstab eingebaut

#===================================================================================================
# /dev/mapper/ubuntu--vg-root 			/               		       	ext4    errors=remount-ro 0       1
UUID=89dce358-166b-442f-977e-01b7b314d8db 	/               		       	ext4    errors=remount-ro 0       1

# "/dev/mapper/ubuntu--vg-SteHome" soll zukünftig die (schnelle) "/home/stefan"-Partition sein/werden:
# /dev/mapper/ubuntu--vg-SteHome 		/home/stefan/0-NewSteHome               ext4    errors=remount-ro 0       1
UUID=fee5b921-042e-4bec-8a81-a2eb24db35dc  	/home/stefan/0-NewSteHome               ext4    errors=remount-ro 0       1

# /dev/mapper/ubuntu--vg-swap_1 	  	none            			swap    sw              0       0
UUID=8ed57e9d-53f4-4d34-a58d-47c9824cd4d6 	none            			swap    sw              0       0

# /dev/mapper/ubuntu--vg-Mate18.04        	/home/stefan/0-NewMate18.04             ext4    errors=remount-ro 0       1
UUID=860f17cf-7703-4156-8cfe-43bbc94e621b 	/home/stefan/0-NewMate18.04             ext4    errors=remount-ro 0       1
#===================================================================================================

# LVM/LUKS-Partition
# /dev/sda5: UUID="de247f5d-9b4e-4c6d-a090-18843bf808c2" TYPE="crypto_LUKS" PARTUUID="176bef1c-05"

# /dev/sdb1 				  	/home/stefan/0-OldMate18.04             ext4    errors=remount-ro 0       1
UUID=0bf920bb-eaad-40eb-90d8-3eb16d7884c9 	/home/stefan/0-OldMate18.04             ext4    errors=remount-ro 0       1

# /dev/sdc3 				  	/home/stefan/0-Multimedia             	ext4    errors=remount-ro 0       1
UUID=f15b434d-0655-454f-b4ad-aac50af52441 	/home/stefan/0-Multimedia               ext4    errors=remount-ro 0       1

# /dev/sdd3 				  	/home/stefan/0-SteBAK             	ext4    errors=remount-ro 0       1
UUID=efba6276-ce66-4525-83a7-b368663f24e5 	/home/stefan/0-SteBAK                   ext4    errors=remount-ro 0       1

# /dev/sde2 				  	/home/stefan/0-HDD(VBox)             	ext4    errors=remount-ro 0       1
UUID=61421da9-883e-43b2-b4b2-67f9390fcc56 	/home/stefan/0-HDD(VBox)                ext4    errors=remount-ro 0       1

# /dev/sde3 				  	/home/stefan/0-OldSteHome             	ext4    errors=remount-ro 0       1
UUID=ec943b66-96b3-4b2c-981c-8172b8dfd016 	/home/stefan/0-OldSteHome             	ext4    errors=remount-ro 0       1

#===================================================================================================
# 19-04-2020-Ste: /tmp aus SSD ins RAM auslagern
tmpfs	/tmp	tmpfs	nosuid	0	0

# /etc/fstab: static file system information.
# StePc08b  
# 2020-04-20  Mate18.04(NEU) im LUKS/LVM-System
#
# 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).
#
# STRUKTUR:
# 
# /boot was on /dev/sda1 during installation
# /dev/sda1 				  	/boot				        ext4    defaults        0       2
UUID=58c83153-3c59-445b-9aae-e2724fb8dd88 	/boot           			ext4    defaults        0       2

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# 2020-04-19 Ste: LVM eingerichtet: 
# 	Partition "root" auf 30GB verkleinert, Partitionen "SteHome" und "Mate18.04"(:= Kopie des alten Systems) angelegt
# 	und in fstab eingebaut

#===================================================================================================
# /dev/mapper/ubuntu--vg-root 			/media/stefan/0-Ubuntu18.04.4	       	ext4    errors=remount-ro 0       1
UUID=89dce358-166b-442f-977e-01b7b314d8db 	/media/stefan/0-Ubuntu18.04.4	       	ext4    errors=remount-ro 0       1

# "/dev/mapper/ubuntu--vg-SteHome" soll zukünftig die (schnelle) "/home/stefan"-Partition sein/werden:
# /dev/mapper/ubuntu--vg-SteHome 		/home/stefan/0-NewSteHome               ext4    errors=remount-ro 0       1
UUID=fee5b921-042e-4bec-8a81-a2eb24db35dc  	/home/stefan/0-NewSteHome               ext4    errors=remount-ro 0       1

# /dev/mapper/ubuntu--vg-swap_1 	  	none            			swap    sw              0       0
UUID=8ed57e9d-53f4-4d34-a58d-47c9824cd4d6 	none            			swap    sw              0       0

# /dev/mapper/ubuntu--vg-Mate18.04        	/                                       ext4    errors=remount-ro 0       1
UUID=860f17cf-7703-4156-8cfe-43bbc94e621b 	/                                       ext4    errors=remount-ro 0       1
#===================================================================================================

# LVM/LUKS-Partition
# /dev/sda5: UUID="de247f5d-9b4e-4c6d-a090-18843bf808c2" TYPE="crypto_LUKS" PARTUUID="176bef1c-05"

# /dev/sdb1 				  	/home/stefan/0-OldMate18.04	        ext4    errors=remount-ro 0       1
UUID=0bf920bb-eaad-40eb-90d8-3eb16d7884c9 	/home/stefan/0-OldMate18.04             ext4    errors=remount-ro 0       1

# /dev/sdc3 				  	/home/stefan/0-Multimedia             	ext4    errors=remount-ro 0       1
UUID=f15b434d-0655-454f-b4ad-aac50af52441 	/home/stefan/0-Multimedia               ext4    errors=remount-ro 0       1

# /dev/sdd3 				  	/home/stefan/0-SteBAK             	ext4    errors=remount-ro 0       1
UUID=efba6276-ce66-4525-83a7-b368663f24e5 	/home/stefan/0-SteBAK                   ext4    errors=remount-ro 0       1

# /dev/sde2 				  	/home/stefan/0-HDD(VBox)             	ext4    errors=remount-ro 0       1
UUID=61421da9-883e-43b2-b4b2-67f9390fcc56 	/home/stefan/0-HDD(VBox)                ext4    errors=remount-ro 0       1

# /dev/sde3 				  	/home/stefan		             	ext4    errors=remount-ro 0       1
UUID=ec943b66-96b3-4b2c-981c-8172b8dfd016 	/home/stefan     	             	ext4    errors=remount-ro 0       1

#===================================================================================================
# 19-04-2020-Ste: /tmp aus SSD ins RAM auslagern
tmpfs	/tmp	tmpfs	nosuid	0	0

# /etc/fstab: static file system information.
# StePc08b  
# 2020-04-20  Mate18.04(ALT) auf /dev/sdb1
#
# 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).
#
# STRUKTUR:
# 
# /boot was on /dev/sda1 during installation
# /dev/sda1 				  	/boot				        ext4    defaults        0       2
UUID=58c83153-3c59-445b-9aae-e2724fb8dd88 	/boot           			ext4    defaults        0       2

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# 2020-04-19 Ste: LVM eingerichtet: 
# 	Partition "root" auf 30GB verkleinert, Partitionen "SteHome" und "Mate18.04"(:= Kopie des alten Systems) angelegt
# 	und in fstab eingebaut

#===================================================================================================
# /dev/mapper/ubuntu--vg-root 			/media/stefan/0-Ubuntu18.04.4	       	ext4    errors=remount-ro 0       1
UUID=89dce358-166b-442f-977e-01b7b314d8db 	/media/stefan/0-Ubuntu18.04.4	       	ext4    errors=remount-ro 0       1

# "/dev/mapper/ubuntu--vg-SteHome" soll zukünftig die (schnelle) "/home/stefan"-Partition sein/werden:
# /dev/mapper/ubuntu--vg-SteHome 		/home/stefan/0-NewSteHome               ext4    errors=remount-ro 0       1
UUID=fee5b921-042e-4bec-8a81-a2eb24db35dc  	/home/stefan/0-NewSteHome               ext4    errors=remount-ro 0       1

# /dev/mapper/ubuntu--vg-swap_1 	  	none            			swap    sw              0       0
# UUID=8ed57e9d-53f4-4d34-a58d-47c9824cd4d6 	none            			swap    sw              0       0

# /dev/mapper/ubuntu--vg-Mate18.04        	/home/stefan/0-NewMate18.04             ext4    errors=remount-ro 0       1
UUID=860f17cf-7703-4156-8cfe-43bbc94e621b 	/home/stefan/0-NewMate18.04             ext4    errors=remount-ro 0       1
#===================================================================================================

# LVM/LUKS-Partition
# /dev/sda5: UUID="de247f5d-9b4e-4c6d-a090-18843bf808c2" TYPE="crypto_LUKS" PARTUUID="176bef1c-05"

# /dev/sdb1 				  	/				        ext4    errors=remount-ro 0       1
UUID=0bf920bb-eaad-40eb-90d8-3eb16d7884c9 	/				        ext4    errors=remount-ro 0       1

# /dev/sdc3 				  	/home/stefan/0-Multimedia             	ext4    errors=remount-ro 0       1
UUID=f15b434d-0655-454f-b4ad-aac50af52441 	/home/stefan/0-Multimedia               ext4    errors=remount-ro 0       1

# /dev/sdd3 				  	/home/stefan/0-SteBAK             	ext4    errors=remount-ro 0       1
UUID=efba6276-ce66-4525-83a7-b368663f24e5 	/home/stefan/0-SteBAK                   ext4    errors=remount-ro 0       1

# /dev/sde1 				  	none            			swap    sw                0       0
UUID=fad598f4-34ec-4edb-9849-b6d044c35e8f 	none            			swap    sw                0       0

# /dev/sde2 				  	/home/stefan/0-HDD(VBox)             	ext4    errors=remount-ro 0       1
UUID=61421da9-883e-43b2-b4b2-67f9390fcc56 	/home/stefan/0-HDD(VBox)                ext4    errors=remount-ro 0       1

# /dev/sde3 				  	/home/stefan		             	ext4    errors=remount-ro 0       1
UUID=ec943b66-96b3-4b2c-981c-8172b8dfd016 	/home/stefan		             	ext4    errors=remount-ro 0       1

#===================================================================================================
# 19-04-2020-Ste: /tmp aus SSD ins RAM auslagern
tmpfs	/tmp	tmpfs	nosuid	0	0

.... und - dann (nach deinem "ok") soll ich update-grub ausführen ... richtig verstanden?
und aus welchem System heraus?

Nachtrag: inzwischen kann ich wieder mit "Mate18.04" auf sdb1 booten. Nur das "Mate18.04" im LVM klemmt noch ... ☺

OMG 😲 Was hast du denn da alles editiert?

Warum benutzen alle Systeme die gleiche /boot? Bei der nächsten Installation eines Kernels auf einem System hast du den schon auf /boot, aber die Paketverwaltungen der anderen Systeme wissen nichts davon und möchten den nochmal aktualisieren. Hoffentlich machst du dir Notizen, in welchem System du den Kernel wieder deinstallieren kannst, was ja eigentlich die Aufgabe der Paketverwaltung wäre. Und ich dachte du wolltest Aufräumen.

PS: Von mir bekommst du so kein OK.

fleet_street schrieb:

OMG 😲 ...

übrigens - ich heiße Stefan nicht "G" .. ☺

... Was hast du denn da alles editiert?

... ich habe alles auf die UUID umgestellt, denn ich hatte mal die Platten ausgebaut und in einer anderen Reihenfolge wieder verbaut und dann stimmten die "sdx" nicht mehr... mit der UUID ist es eindeutig(er) - oder???
Und so kenne ich mich auch nächste Woche noch etwas aus ... bin mit fortschreitendem ALter doch deutlich vergesslicher geworden ☹

... und ich war sooo stolz auf die übersichtliche Struktur ... ☹

Warum benutzen alle Systeme die gleiche /boot? Bei der nächsten Installation eines Kernels auf einem System hast du den schon auf /boot, aber die Paketverwaltungen der anderen Systeme wissen nichts davon und möchten den nochmal aktualisieren. Hoffentlich machst du dir Notizen, in welchem System du den Kernel wieder deinstallieren kannst, was ja eigentlich die Aufgabe der Paketverwaltung wäre. Und ich dachte du wolltest Aufräumen.

OHA ... STIMMT !!! .... Gut, dass ich's dir gezeigt und dich gefragt habe. DAS hatte ich übersehen und nicht zu Ende gedacht ... DANKE ❗
d.h. ich sollte DREI eigenständige "boot" haben ... [GANZ SCHÖN BLÖD VON MIR]

hmmm.... die "Mate18.04"(alt) hat ihr eigenes "boot" (außerhalb von LVM) ... da ist es kein Problem, dies in eine eigene Partition zu verschieben , bzw das "andere boot" auszukommentieren ...
ABER - wie bringe ich die "boot" von "Mate18.04"(NEU) (die ja eine Kopie aus "Mate"(ALT) ist, und nun innerhalb von LVM steht) vor den LVM-Bereich?
Jetzt ist auch KLAR, warum ich die "Mate18.04"(NEU) nicht booten kann... und es wird schwierig ☹

OK - JETZT verstehe ich auch deine Aussage zu meiner Langeweile ☺ ...

Kannst du mir einen "einfachen" Weg nennen, wie ich entweder
a) eine passende "boot" außerhalb von "LVM" auf Basis der innerhalb von "Mate18.04"(NEU) erzeuge, oder
b) dem System beibringe, dass es erst LVM entschlüsseln soll und dann in "Mate18.04"(NEU) seine eigentlihe "boot" findet?

Sorry, dass ich soooo blöd frage -

fleet_street schrieb:

PS: Von mir bekommst du so kein OK.

Gut so! - DANKE!

Schönen Abend und vielen Dank für deine Geduld!
Stefan

Entschuldige. Das Ganze wirkt ziemlich planlos. Du weißt jetzt schon nicht mehr, wem die separate boot-Partition gehört.

• Die alte Installation auf HDD braucht keine separate boot-Partition, weil /boot ein normales Verzeichnis innerhalb des Wurzelverzeichnis ist.

• Das frisch installierte, Verschlüsselte behält seine unverschlüsselte /boot für sich alleine.

• Das umgezogene alte System kann theoretisch auch ohne separater boot-Partition betrieben werden. Wie man das nachträglich beibiegt – schrieb ich bereits – weiß ich auch nicht. (Ich habe auf meinem Testsystem auch kein Platz, dass ich die Spielerei nachbauen könnte.) Ich habe lediglich auf meinem Produktivrechner bei der Installation auf die unverschlüsselte boot direkt verzichtet. Daher weiß ich, dass der Tipp von lionlizard funktioniert.

Wo würdest du eine unverschlüsselte boot einrichten wollen? Auf der 125 G SSD ist kein Platz. Eine Größenänderung eines verschlüsselten LVM ist zwar möglich, aber nicht einfach und ich bin daran beinahe gescheitert. (Jedenfalls kann ich es nicht erklären.) Sinnigerweise sollte die boot-Partition aber auf dem gleichen Datenträger sein, auf dem auch das System ist. 😕

OK - JETZT verstehe ich auch deine Aussage zu meiner Langeweile ☺ ...

Ja, manchmal fällt der Groschen centweise. 😉 😀