Schönen Sonntag zusmmen,

auf einem zweiten Rechner hab ich auch das upgrade auf
bookworm gemacht. Sound funktioniert übrigens :-)

Was nicht funktioniert ist der Startvorgang.
Grub lädt und fängt an den kernel 6.1.0 zu laden. Dann kommt die Passwortabfrage (LVM auf LUKS). Dann wird aber root nicht
gefunden und ich lande in der BusyBox.

Wenn ich jetzt
# vgchange -ay
# exit
eingebe, läuft der Bootvorgang normal und ohne weitere Probleme durch.

Ich habe analog zum Laptop hier ein rootdelay von 5 Sekunden mit
gegeben bzw. jetzt probehalber sogar 10, leider hilft das auf diesem
Rechner nicht.
$ egrep rootdelay /boot/grub/grub.cfg
linux /vmlinuz-6.1.0-9-amd64
root=/dev/mapper/terravm-root ro rootdelay=10 quiet
ist also auch tatsächlich dort angekommen.

Kann mir da bitte jemand helfen?
Danke
Ulrich

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

Hallo,

Am 18.06.23 um 20:45 schrieb Ulrich Fürst:

Schönen Sonntag zusmmen,

auf einem zweiten Rechner hab ich auch das upgrade auf
bookworm gemacht. Sound funktioniert übrigens :-)

Was nicht funktioniert ist der Startvorgang.
Grub lädt und fängt an den kernel 6.1.0 zu laden. Dann kommt die Passwortabfrage (LVM auf LUKS). Dann wird aber root nicht
gefunden und ich lande in der BusyBox.

Wenn ich jetzt
# vgchange -ay
# exit
eingebe, läuft der Bootvorgang normal und ohne weitere Probleme durch.

Ich habe analog zum Laptop hier ein rootdelay von 5 Sekunden mit
gegeben bzw. jetzt probehalber sogar 10, leider hilft das auf diesem
Rechner nicht.
$ egrep rootdelay /boot/grub/grub.cfg
linux /vmlinuz-6.1.0-9-amd64
root=/dev/mapper/terravm-root ro rootdelay=10 quiet
ist also auch tatsächlich dort angekommen.

Kann mir da bitte jemand helfen?
Danke
Ulrich

nimm erstmal das "quiet" raus. Das System versucht sicher schon dir zu
sagen was los ist. Es wird aber durch quiet verhindert, dass du es sehen kannst.

Andreas

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

Am Mon, 19 Jun 2023 16:25:32 +0200
schrieb Andreas <ahort@t-online.de>:

nimm erstmal das "quiet" raus. Das System versucht sicher schon dir
zu sagen was los ist. Es wird aber durch quiet verhindert, dass du es
sehen kannst.

Hm, ich sehe da nicht viel unterschied. Außer, dass am Anfang schnelle Meldungen kommen, dass diverse Geräte (Festplatten, Maus, Tastatur,
usw.) erkannt werden.
dann kommt:

done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top
... [ 7.303066] device-mapper: core: CONFIG_IMA_DISABLE_HTABLE is
disabled. Duplicate IMA measurements will not bei recorded in the IMA
log.
[ 7.303113] device-mapper: uevent: version 1.0.3
[ 7.303174] device-mapper: ioctl: 4.47.0-ioctl (2022-07-28)
initialised: dm_devel@redhat.com

Please unlock disk nvme0n1p8_crypt:

nach Eingabe des Passwortes:

cryptsetup: nvme0n1p8_crypt: set up successfully
done.
Begin: Running /scripts/local-premount ... Begin: Waiting for
suspend/resume device ... Beginn: Running /scripts/local/block ...
done. Begin: Running /scripts/local-block ... done.
[kommt 7 mal]
done.
Gave up waiting for suspend/resume device
done.
Begin: Waiting for root file system ... Begin: Running
/scripts/local-block ... done.
done.
Gave up waiting for root file system device. Common problems:
- Boot args (cat /proc/cmdline)
- Check rootdelay= (did the system wait long enough?)
- Missing modules (cat /proc/modules; ls /dev/)
ALERT! /dev/mapper/terravm-root does not exist. Dropping to a shell!

cat /proc/cmdline ergibt die Zeile die in der grub config steht.

rootdelay: auf dem Laptop reichen 5, hier machen auch 10 keinen
Unterschied (mehr hab ich noch nicht ausprobiert).

die Module sind m.E. da, sonst könnte ich doch auch nicht, ohne Module
nach zu laden, das LVM manuell aktivieren)?

in /dev/ sind die Devices nvme0, nvme0n1 und nvme0n1p1 bis ...p8 zu
sehen. Genauso wie auch jetzt im gebooteten System. Der Unterschied
ist, dass ich natürlich jetzt auch in /dev/mapper/ die einzelnen LV
sehe.

Mir hilft das leider nicht :-(
Ich hoffe Dir?

TIA
Ulrich

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

Am 19.06.23 um 18:42 schrieb Ulrich Fürst:

Hallo

cryptsetup: nvme0n1p8_crypt: set up successfully
done.
Begin: Running /scripts/local-premount ... Begin: Waiting for
suspend/resume device ... Beginn: Running /scripts/local/block ...
done. Begin: Running /scripts/local-block ... done.
[kommt 7 mal]
done.

Das entschlüsseln hat ja noch geklappt.

Gave up waiting for suspend/resume device
done.
Begin: Waiting for root file system ... Begin: Running
/scripts/local-block ... done.
done.
Gave up waiting for root file system device. Common problems:
- Boot args (cat /proc/cmdline)
- Check rootdelay= (did the system wait long enough?)
- Missing modules (cat /proc/modules; ls /dev/)
ALERT! /dev/mapper/terravm-root does not exist. Dropping to a shell!

Der LVM Hook (nennt man das so, ich verwende schon lange Archlinux) wird
aber nicht mehr gestartet.

cat /proc/cmdline ergibt die Zeile die in der grub config steht.

rootdelay: auf dem Laptop reichen 5, hier machen auch 10 keinen
Unterschied (mehr hab ich noch nicht ausprobiert).

die Module sind m.E. da, sonst könnte ich doch auch nicht, ohne Module
nach zu laden, das LVM manuell aktivieren)?

in /dev/ sind die Devices nvme0, nvme0n1 und nvme0n1p1 bis ...p8 zu
sehen. Genauso wie auch jetzt im gebooteten System. Der Unterschied
ist, dass ich natürlich jetzt auch in /dev/mapper/ die einzelnen LV
sehe.

Mir hilft das leider nicht :-(
Ich hoffe Dir?

TIA
Ulrich

Schonmal versucht, das initramfs neu zu erstellen?

Andreas

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

Am Mon, 19 Jun 2023 21:31:45 +0200
schrieb Andreas <ahort@t-online.de>:

Schonmal versucht, das initramfs neu zu erstellen?

AFAIR schon. Hab's jetzt aber noch mal gemacht.
# update-initramfs -u
# update-grub

hat leider nichts geholfen.

Beim update-grub fällt mir auf, dass hier

Found Debian GNU/Linux 10 (buster) on /dev/nvme0n1p5

gefunden wird.
Wie finde ich heraus, was nvme0n1p5 ist, falls mir hier Altlasten
dazwischen funken?

Mounte ich nvme0n1p5 auf /mnt sieht das so aus (ist aber an sich nicht
viel drin - du -sh sagt 235M). Vor allem ist hier keine initrd o.ä.
drauf
$ ls /mnt/
bin debootstrap etc lib lib64 lost+found mnt proc run
srv tmp var boot dev home lib32 libx32 media opt
root sbin sys usr

/mnt/tmp ist vom 10.04.2021 (Älter als der Rechner).

# touch /mnt/nvme0n1p5
# updatedb
# locate nvme0n1p5
/dev/nvme0n1p5
/mnt/nvme0n1p5

Scheint also nirgendwo anders aufzutauchen. Was ist das für eine
Partition / LV?

Ulrich

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

On Mon, 19 Jun 2023 23:47:36 +0200, Ulrich Fürst
<fuerst.ulrich@web.de> wrote:

Mounte ich nvme0n1p5 auf /mnt sieht das so aus (ist aber an sich nicht
viel drin - du -sh sagt 235M). Vor allem ist hier keine initrd o.ä.
drauf
$ ls /mnt/
bin debootstrap etc lib lib64 lost+found mnt proc run
srv tmp var boot dev home lib32 libx32 media opt
root sbin sys usr

Wie sind denn da die Zeitstempel, steht was in /boot?

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

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

Am Tue, 20 Jun 2023 07:59:51 +0200
schrieb Marc Haber <mh+debian-user-german@zugschlus.de>:

Wie sind denn da die Zeitstempel, steht was in /boot?

$ ls -al /mnt/boot/
insgesamt 12
drwxr-xr-x 3 root root 4096 20. Mär 2021 .
drwxr-xr-x 19 root root 4096 19. Jun 23:42 ..
drwxr-xr-x 2 root root 4096 10. Apr 2021 efi

Das einzige in /boot ist das Verzeichnis efi. Die anderen Zeitstempel
sind auch alle so März bis Mai 2021. Das /boot/.. von gestern ist,
dürfte daran liegen das ich es gestern im Wurzelverzeichnis dieser
Partition die Datei nvme0n1p5 angelegt habe, oder?
Der Rechner und damit die Erstinstallation müsste Mitte/Ende März
gewesen sein. ob allerdings schon am 20.03.21 weiß ich nicht mehr.

VG
Ulrich

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

Hallo

Am 20.06.23 um 20:34 schrieb Ulrich Fürst:

Am Tue, 20 Jun 2023 07:59:51 +0200
schrieb Marc Haber <mh+debian-user-german@zugschlus.de>:

Wie sind denn da die Zeitstempel, steht was in /boot?

$ ls -al /mnt/boot/
insgesamt 12
drwxr-xr-x 3 root root 4096 20. Mär 2021 .
drwxr-xr-x 19 root root 4096 19. Jun 23:42 ..
drwxr-xr-x 2 root root 4096 10. Apr 2021 efi

Das einzige in /boot ist das Verzeichnis efi. Die anderen Zeitstempel
sind auch alle so März bis Mai 2021. Das /boot/.. von gestern ist,
dürfte daran liegen das ich es gestern im Wurzelverzeichnis dieser
Partition die Datei nvme0n1p5 angelegt habe, oder?
Der Rechner und damit die Erstinstallation müsste Mitte/Ende März
gewesen sein. ob allerdings schon am 20.03.21 weiß ich nicht mehr.

VG
Ulrich

Ich bin mir nicht sicher, ob du dich hier etwas festgefahren hast. Ich
denke diese Partition hat nichts mit deinem Bootproblem zu tun. Die
Tatsache, das der os-prober da was findet ist ja kein Problem. So lange
du beim Booten in Grub den richtigen Booteintrag auswählst, sollte das
normal starten. Hat es ja bis vor dem Update auch.

Es könnte natürlich sein, das dein BIOS/UEFI nicht das aktuelle Grub
nimmt. Falls du UEFI nutzt, könntest du ja mal ins UEFI Bootmenü gehen
und schauen welche Optionen es gibt.

Andreas

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

On Tue, 20 Jun 2023 20:34:09 +0200, Ulrich Fürst
<fuerst.ulrich@web.de> wrote:

Am Tue, 20 Jun 2023 07:59:51 +0200
schrieb Marc Haber <mh+debian-user-german@zugschlus.de>:

Wie sind denn da die Zeitstempel, steht was in /boot?

$ ls -al /mnt/boot/
insgesamt 12
drwxr-xr-x 3 root root 4096 20. Mär 2021 .
drwxr-xr-x 19 root root 4096 19. Jun 23:42 ..
drwxr-xr-x 2 root root 4096 10. Apr 2021 efi

Das einzige in /boot ist das Verzeichnis efi.

Das ist nicht das /boot aus dem Dein System startet. Vermutlich ist es
auch nicht das Rootfilesystems deines Systems.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

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

Am Wed, 21 Jun 2023 10:28:47 +0200
schrieb Marc Haber <mh+debian-user-german@zugschlus.de>:

On Tue, 20 Jun 2023 20:34:09 +0200, Ulrich Fürst
<fuerst.ulrich@web.de> wrote:

Am Tue, 20 Jun 2023 07:59:51 +0200
schrieb Marc Haber <mh+debian-user-german@zugschlus.de>:

Wie sind denn da die Zeitstempel, steht was in /boot?

$ ls -al /mnt/boot/
insgesamt 12
drwxr-xr-x 3 root root 4096 20. Mär 2021 .
drwxr-xr-x 19 root root 4096 19. Jun 23:42 ..
drwxr-xr-x 2 root root 4096 10. Apr 2021 efi

Das einzige in /boot ist das Verzeichnis efi.

Das ist nicht das /boot aus dem Dein System startet. Vermutlich ist es
auch nicht das Rootfilesystems deines Systems.

nein sicher nicht, hat eine andere UUID. Root wird ja auch korrekt
eingebunden. Nur eben nicht automatisch :-(

Ulrich

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

Am Tue, 20 Jun 2023 21:27:15 +0200
schrieb Andreas <ahort@t-online.de>:

Ich bin mir nicht sicher, ob du dich hier etwas festgefahren hast.
Ich denke diese Partition hat nichts mit deinem Bootproblem zu tun.

Ich wollte es nur erwähnt haben, weil bootproblem und unerwartete
Meldung von grub
Ãœbrigens: ii grub-efi-amd64 2.06-13 amd64

Die Tatsache, das der os-prober da was findet ist ja kein Problem. So
lange du beim Booten in Grub den richtigen Booteintrag auswählst,
sollte das normal starten. Hat es ja bis vor dem Update auch.

Es gibt später noch nicht mal einen Eintrag zum Auswählen.

Es könnte natürlich sein, das dein BIOS/UEFI nicht das aktuelle Grub nimmt. Falls du UEFI nutzt, könntest du ja mal ins UEFI Bootmenü
gehen und schauen welche Optionen es gibt.

Im Grub-GUI steht beim booten die Version 2.06-13 und die ist ja auch installiert. Und es kommt auch die Meldung das EFI-Secure-boot aktiv
ist.

Wonach soll ich den in dem Setup suchen? Ich bin, was dieses Menü
angeht völlig unerfahren.

Ulrich

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

Ich hab gerade mal die /e/lvm/lvm.conf jetzt mit der von bullseye
verglichen. Die jetzt ist "leer".
$ egrep -v '^\s*$|#' /etc/lvm/lvm.conf
config {
}
devices {
}
allocation {
}
log {
}
backup {
}
shell {
}
global {
}
activation {
}
dmeventd {
}

die alte hab ich an den Schluss gestellt.

Ich hab die alte lvm.conf mal versuchsweise in /etc/lvm/ getauscht und
dann initramfs -k all -u && update-grub
Leider ohne eine Veränderung.

Schönen Abend noch zusammen
Ulrich

--

$ egrep -v '^\s*$|#' /etc/lvm/lvm.conf.bullseye
config {
checks = 1
abort_on_errors = 0
profile_dir = "/etc/lvm/profile"
}
devices {
dir = "/dev"
scan = [ "/dev" ]
obtain_device_list_from_udev = 1
external_device_info_source = "none"
sysfs_scan = 1
scan_lvs = 0
multipath_component_detection = 1
md_component_detection = 1
fw_raid_component_detection = 0
md_chunk_alignment = 1
data_alignment_detection = 1
data_alignment = 0
data_alignment_offset_detection = 1
ignore_suspended_devices = 0
ignore_lvm_mirrors = 1
require_restorefile_with_uuid = 1
pv_min_size = 2048
issue_discards = 0
allow_changes_with_duplicate_pvs = 0
allow_mixed_block_sizes = 0
}
allocation {
maximise_cling = 1
use_blkid_wiping = 1
wipe_signatures_when_zeroing_new_lvs = 1
mirror_logs_require_separate_pvs = 0
}
log {
verbose = 0
silent = 0
syslog = 1
overwrite = 0
level = 0
command_names = 0
prefix = " "
activation = 0
debug_classes = [ "memory", "devices", "

Hallo nochmal

Ich hab das eben mal in einer VM gemacht und habe Debian 11 auf 12
updated. Bei mir ist jetzt auch die /etc/lvm/lvm.conf leer und es funktioniert trotzdem wie vorher. Daran liegts wohl nicht.

Andreas

Ich verwende übrigens auch kein rootdelay. Das Update ist "fast"
problemlos durchgelaufen und hat beim ersten Mal direkt ins LVM-root
gestartet.

Ich habe allerdings in der VM keine Verschlüsselung, da es sich genau
für solche Testzwecke um kein Produktivsystem handelt. Eventuell auch
mal ohne Delay probieren.


Wie lautet denn deine grub Kommandozeile. Bei mir steht da nur "BOOT_IMAGE=/boot/vmlinuz-6.1.0-9-amd64 root=/dev/mapper/main-root ro quiet"

Andreas

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

Hallo

Am 21.06.23 um 21:19 schrieb Ulrich Fürst:

Ich hab gerade mal die /e/lvm/lvm.conf jetzt mit der von bullseye
verglichen. Die jetzt ist "leer".
$ egrep -v '^\s*$|#' /etc/lvm/lvm.conf
config {
}
devices {
}
allocation {
}
log {
}
backup {
}
shell {
}
global {
}
activation {
}
dmeventd {
}

die alte hab ich an den Schluss gestellt.

Ich hab die alte lvm.conf mal versuchsweise in /etc/lvm/ getauscht und
dann initramfs -k all -u && update-grub
Leider ohne eine Veränderung.

Schönen Abend noch zusammen
Ulrich

Ich hab das eben mal in einer VM gemacht und habe Debian 11 auf 12
updated. Bei mir ist jetzt auch die /etc/lvm/lvm.conf leer und es
funktioniert trotzdem wie vorher. Daran liegts wohl nicht.

Andreas

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

Am Sat, 24 Jun 2023 09:21:36 +0200
schrieb Ulrich Fürst <fuerst.ulrich@web.de>:

Vllt. sollte ich noch erwähnen, dass ich UUID verwende. Ich habe, weil
das mal als bug in grub war, auch mal GRUB_DISABLE_LINUX_UUID=true
in der /e/d/grub aktiviert.

Andererseits: auf dem Laptop ist das System identisch und da ist UUID
nicht disabled.

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

Am Thu, 22 Jun 2023 17:33:21 +0200
schrieb Andreas <ahort@t-online.de>:

Hallo nochmal

Ich hab das eben mal in einer VM gemacht und habe Debian 11 auf 12 updated. Bei mir ist jetzt auch die /etc/lvm/lvm.conf leer und es funktioniert trotzdem wie vorher. Daran liegts wohl nicht.

Ich verwende übrigens auch kein rootdelay. Das Update ist "fast"

Hallo Andreas, sorry für die späte Reaktion.
Danke für's probieren. rootdelay hab ich gerade mal (händisch, beim
booten) herausgenommen. Ändert leider nichts. Ich hab das aber AFAIR
auch erst nach dem ersten erfolglosen booten rein genommen.

Wie lautet denn deine grub Kommandozeile. Bei mir steht da nur "BOOT_IMAGE=/boot/vmlinuz-6.1.0-9-amd64 root=/dev/mapper/main-root ro
quiet"

/vmlinuz-6.1.0-9-amd64 root=/dev/mapper/terravm-root ro
wobei
$ ls -l /vmlinuz*
/vmlinuz -> boot/vmlinuz-6.1.0-9-amd64

Und BOOT_IMAGE steht bei mir nirgends (mit "egrep -R BOOT_IMAGE /boot/"
bzw. ".../etc/grub/" gesucht.

Füge ich beim booten in grub per edit /boot/ vor mein vmlinuz ein (also
wie bei Dir dann /boot/vmlinuz-6.1.0-9-amd64 in der Zeile) findet er
den Kernel nicht.

Vllt. sollte ich noch erwähnen, dass ich UUID verwende. Ich habe, weil
das mal als bug in grub war, auch mal GRUB_DISABLE_LINUX_UUID=true
in der /e/d/grub aktiviert. Der Eintrag in /boot/grub/grub.cfg lautet
aber weiterhin:
menuentry 'Debian GNU/Linux, with Linux 6.1.0-9-amd64' --class debian --class gnu-linux --class gnu --class os \
$menuentry_id_option 'gnulinux-6.1.0-9-amd64-advanced-286e9583-54a1-4c80-81db-75f16c6ecc0f' {
savedefault
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root 86e6180d-60ea-4b79-8a3b-13251ce265e6
echo 'Loading Linux 6.1.0-9-amd64 ...'
linux /vmlinuz-6.1.0-9-amd64 root=/dev/mapper/terravm-root ro rootdelay=5
echo 'Loading initial ramdisk ...'
initrd /initrd.img-6.1.0-9-amd64
}

Müsste dann nicht das "--set=root $UUID_von_root" ersetzt werden?

Danke schon mal
Ulrich

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

Hallo

Am 24.06.23 um 09:21 schrieb Ulrich Fürst:

/vmlinuz-6.1.0-9-amd64 root=/dev/mapper/terravm-root ro
wobei
$ ls -l /vmlinuz*
/vmlinuz -> boot/vmlinuz-6.1.0-9-amd64

Und BOOT_IMAGE steht bei mir nirgends (mit "egrep -R BOOT_IMAGE /boot/"
bzw. ".../etc/grub/" gesucht.

Füge ich beim booten in grub per edit /boot/ vor mein vmlinuz ein (also
wie bei Dir dann /boot/vmlinuz-6.1.0-9-amd64 in der Zeile) findet er
den Kernel nicht.

Vllt. sollte ich noch erwähnen, dass ich UUID verwende. Ich habe, weil
das mal als bug in grub war, auch mal GRUB_DISABLE_LINUX_UUID=true
in der /e/d/grub aktiviert. Der Eintrag in /boot/grub/grub.cfg lautet
aber weiterhin:
menuentry 'Debian GNU/Linux, with Linux 6.1.0-9-amd64' --class debian --class gnu-linux --class gnu --class os \
$menuentry_id_option 'gnulinux-6.1.0-9-amd64-advanced-286e9583-54a1-4c80-81db-75f16c6ecc0f' {
savedefault
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root 86e6180d-60ea-4b79-8a3b-13251ce265e6
echo 'Loading Linux 6.1.0-9-amd64 ...'
linux /vmlinuz-6.1.0-9-amd64 root=/dev/mapper/terravm-root ro rootdelay=5
echo 'Loading initial ramdisk ...'
initrd /initrd.img-6.1.0-9-amd64
}

Müsste dann nicht das "--set=root $UUID_von_root" ersetzt werden?

Danke schon mal
Ulrich

Für mich ist das auch etwas verwirrend. Das mit dem "BOOT_IMAGE=" wird
mir angezeigt, wenn ich "cat /proc/cmdline" ausführe. In der grub.cfg
steht das aber so nicht drin.

Sorry wenn ich dich da auf ne falsche Fährte gebracht habe.

Bei mir sieht das folgendermaßen aus:

menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class
gnu --class os $menuentry_id_option 'gnulinux-simple-5eb56d7b-a667-4129-9fa0-849c11d85fab' {
    load_video
    insmod gzio
    if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
    insmod part_msdos
    insmod lvm
    insmod ext2
    set root='lvmid/U9NAwN-F1yI-H95c-nFnC-K431-w6Co-vssLMg/3if5nc-fOJl-HL5f-NVU0-HT3p-ZMWi-cu9d35'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint='lvmid/U9NAwN-F1yI-H95c-nFnC-K431-w6Co-vssLMg/3if5nc-fOJl-HL5f-NVU0-HT3p-ZMWi-cu9d35'
5eb56d7b-a667-4129-9fa0-849c11d85fab
    else
      search --no-floppy --fs-uuid --set=root 5eb56d7b-a667-4129-9fa0-849c11d85fab
    fi
    echo    'Loading Linux 6.1.0-9-amd64 ...'
    linux    /boot/vmlinuz-6.1.0-9-amd64 root=/dev/mapper/main-root ro  quiet
    echo    'Loading initial ramdisk ...'
    initrd    /boot/initrd.img-6.1.0-9-amd64
}

Andreas

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

Am Sat, 24 Jun 2023 09:38:33 +0200
schrieb Andreas <ahort@t-online.de>:

Hallo

Am 24.06.23 um 09:21 schrieb Ulrich Fürst:

/vmlinuz-6.1.0-9-amd64 root=/dev/mapper/terravm-root ro
wobei
$ ls -l /vmlinuz*
/vmlinuz -> boot/vmlinuz-6.1.0-9-amd64

Und BOOT_IMAGE steht bei mir nirgends (mit "egrep -R BOOT_IMAGE
/boot/" bzw. ".../etc/grub/" gesucht.

Füge ich beim booten in grub per edit /boot/ vor mein vmlinuz ein
(also wie bei Dir dann /boot/vmlinuz-6.1.0-9-amd64 in der Zeile)
findet er den Kernel nicht.

Vllt. sollte ich noch erwähnen, dass ich UUID verwende. Ich habe,
weil das mal als bug in grub war, auch mal
GRUB_DISABLE_LINUX_UUID=true in der /e/d/grub aktiviert. Der
Eintrag in /boot/grub/grub.cfg lautet aber weiterhin:
menuentry 'Debian GNU/Linux, with Linux 6.1.0-9-amd64'
--class debian --class gnu-linux --class gnu --class os \ $menuentry_id_option 'gnulinux-6.1.0-9-amd64-advanced-286e9583-54a1-4c80-81db-75f16c6ecc0f'
{ savedefault load_video insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio;
insmod lzopio; fi insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root 86e6180d-60ea-4b79-8a3b-13251ce265e6 echo 'Loading Linux
6.1.0-9-amd64 ...' linux /vmlinuz-6.1.0-9-amd64 root=/dev/mapper/terravm-root ro rootdelay=5 echo 'Loading
initial ramdisk ...' initrd /initrd.img-6.1.0-9-amd64
}

Müsste dann nicht das "--set=root $UUID_von_root" ersetzt werden?

Danke schon mal
Ulrich

Für mich ist das auch etwas verwirrend. Das mit dem "BOOT_IMAGE="
wird mir angezeigt, wenn ich "cat /proc/cmdline" ausführe. In der
grub.cfg steht das aber so nicht drin.

$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.1.0-9-amd64 root=/dev/mapper/terravm-root ro
rootdelay=5

root='lvmid/U9NAwN-F1yI-H95c-nFnC-K431-w6Co-vssLMg/3if5nc-fOJl-HL5f-NVU0-HT3p-ZMWi-cu9d35'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint='lvmid/U9NAwN-F1yI-H95c-nFnC-K431-w6Co-vssLMg/3if5nc-fOJl-HL5f-NVU0-HT3p-ZMWi-cu9d35'
5eb56d7b-a667-4129-9fa0-849c11d85fab

Der Unterschied dürfte v.a. dieses --hint sein?

Ulrich

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

Hallo

Am 24.06.23 um 15:21 schrieb Ulrich Fürst:

$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.1.0-9-amd64 root=/dev/mapper/terravm-root ro rootdelay=5

root='lvmid/U9NAwN-F1yI-H95c-nFnC-K431-w6Co-vssLMg/3if5nc-fOJl-HL5f-NVU0-HT3p-ZMWi-cu9d35'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root
--hint='lvmid/U9NAwN-F1yI-H95c-nFnC-K431-w6Co-vssLMg/3if5nc-fOJl-HL5f-NVU0-HT3p-ZMWi-cu9d35'
5eb56d7b-a667-4129-9fa0-849c11d85fab

Der Unterschied dürfte v.a. dieses --hint sein?

Ulrich

Ich glaube nicht, das das einen Einfluß auf den Bootvorgang hat. An den
Kernel wird davon nichts übergeben. Da ja das Booten bei dir von der
Sache her geklappt hat, inklusive entschlüsseln, denke ich der Fehler
ist irgendwo im Detail.

Erstreckt sich dein logical Volume eventuell über mehrere Platten?
Vielleicht fehlt eine beim Starten.

Irgendwas läuft da im initramfs nicht korrekt. Ich bin allerdings hier
am Ende. So genau kenn ich mich da nicht aus. Ich verwende Debian nur in
VM's ohne lvm und nutze am Desktop seit Jahren Archlinux.

Das allerdings auch mit verschlüsseltem physical Volume für lvm2.

Andreas

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

Am Sat, 24 Jun 2023 16:55:19 +0200
schrieb Andreas <ahort@t-online.de>:

Am 24.06.23 um 15:21 schrieb Ulrich Fürst:

$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.1.0-9-amd64 root=/dev/mapper/terravm-root ro rootdelay=5

root='lvmid/U9NAwN-F1yI-H95c-nFnC-K431-w6Co-vssLMg/3if5nc-fOJl-HL5f-NVU0-HT3p-ZMWi-cu9d35'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root
--hint='lvmid/U9NAwN-F1yI-H95c-nFnC-K431-w6Co-vssLMg/3if5nc-fOJl-HL5f-NVU0-HT3p-ZMWi-cu9d35'
5eb56d7b-a667-4129-9fa0-849c11d85fab

Der Unterschied dürfte v.a. dieses --hint sein?

Ulrich

Ich glaube nicht, das das einen Einfluß auf den Bootvorgang hat. An
den Kernel wird davon nichts übergeben. Da ja das Booten bei dir von
der Sache her geklappt hat, inklusive entschlüsseln, denke ich der
Fehler ist irgendwo im Detail.

Erstreckt sich dein logical Volume eventuell über mehrere Platten? Vielleicht fehlt eine beim Starten.

Tut es, allerdings ist nur /home/ auf einer anderen Platte, das System
selber ist auf einer SSD.
Deshalb muss ich wohl aktuell auch für /home/ nochmal das Passwort
eingeben. Kenne ich aber aus anderen Problemen mit dieser
Konstellation.

Ulrich

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

Hallo

Am 25.06.23 um 14:21 schrieb Andreas:

Deine volume group terravm beinhaltet also sda4_crypt und
nvme0n1p8_crypt. Die beiden physical volumes müssen also beide vor dem eigentlichen Start in das root System entschlüsselt werden. Hast du
für beide das selbe Passwort? Da könnte aus meiner Sicht das Problem liegen. Werden denn innerhalb des initramfs beide PV's entschlüsselt.?
Da habe ich ehrlich gesagt nicht drauf geachtet bei deinen früheren Nachrichten.

Selbst wenn dein root nicht auf dem PV sda4_crypt liegt, so muss doch
meiner Meinung nach die komplette VG verfügbar sein, bevor
irgendwelche LV's eingehängt werden können.

Zur Not könnte ja sda4_cryptin eine eigene VG rein und die terravm nur
noch über nvme0n1p8 gehen.

Kann aber auch sein, das ich hier auf dem Holzweg bin.

Andreas

Kleine Frage noch. Wie sieht denn deine /etc/crypttab aus. Stehen da
beide verschlüsselten Platten drin?

Andreas

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

Hallo

Am 25.06.23 um 08:31 schrieb Ulrich Fürst:

Meine Aufteilung:

root@terra:~# pvs
PV VG Fmt Attr PSize PFree
/dev/mapper/nvme0n1p8_crypt terravm lvm2 a-- <46.86g 0
/dev/mapper/sda4_crypt terravm lvm2 a-- <1.71t 0
root@terra:~# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert home terravm -wi-ao---- <1.71t root terravm
-wi-ao---- 2.79g swap terravm -wi-ao---- <10.54g tmp terravm
-wi-ao---- <5.59g usr terravm -wi-ao---- 23.28g var terravm
-wi-ao---- <4.66g root@terra:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 1.8T 0 disk
├─sda1 8:1 0 16M 0 part
├─sda2 8:2 0 115G 0 part
└─sda3 8:3 0 1.7T 0 part
└─sda4_crypt 254:6 0 1.7T 0 crypt
└─terravm-home 254:7 0 1.7T 0 lvm /home
sdb 8:16 0 931.5G 0 disk
└─sdb1 8:17 0 931.5G 0 part /media/ulrich/A0E09159E091370E sdc 8:32 1 0B 0
disk sr0 11:0 1 1024M 0 rom
nvme0n1 259:0 0 238.5G 0 disk
├─nvme0n1p1 259:1 0 260M 0 part /boot/efi
├─nvme0n1p2 259:2 0 128M 0 part
├─nvme0n1p3 259:3 0 188.3G 0 part
├─nvme0n1p4 259:4 0 1G 0 part
├─nvme0n1p5 259:5 0 954M 0 part
├─nvme0n1p6 259:6 0 572M 0 part
├─nvme0n1p7 259:7 0 477M 0 part /boot
└─nvme0n1p8 259:8 0 46.9G 0 part
└─nvme0n1p8_crypt 254:0 0 46.9G 0 crypt
├─terravm-root 254:1 0 2.8G 0 lvm /
├─terravm-usr 254:2 0 23.3G 0 lvm /usr
├─terravm-tmp 254:3 0 5.6G 0 lvm /tmp
├─terravm-var 254:4 0 4.7G 0 lvm /var
└─terravm-swap 254:5 0 10.5G 0 lvm [SWAP]

Deine volume group terravm beinhaltet also sda4_crypt und
nvme0n1p8_crypt. Die beiden physical volumes müssen also beide vor dem eigentlichen Start in das root System entschlüsselt werden. Hast du für
beide das selbe Passwort? Da könnte aus meiner Sicht das Problem liegen. Werden denn innerhalb des initramfs beide PV's entschlüsselt.? Da habe
ich ehrlich gesagt nicht drauf geachtet bei deinen früheren Nachrichten.

Selbst wenn dein root nicht auf dem PV sda4_crypt liegt, so muss doch
meiner Meinung nach die komplette VG verfügbar sein, bevor irgendwelche
LV's eingehängt werden können.

Zur Not könnte ja sda4_cryptin eine eigene VG rein und die terravm nur
noch über nvme0n1p8 gehen.

Kann aber auch sein, das ich hier auf dem Holzweg bin.

Andreas

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

Am Sun, 25 Jun 2023 14:21:34 +0200
schrieb Andreas <ahort@t-online.de>:

Hallo

Am 25.06.23 um 08:31 schrieb Ulrich Fürst:

Meine Aufteilung:

root@terra:~# pvs
PV VG Fmt Attr PSize PFree
/dev/mapper/nvme0n1p8_crypt terravm lvm2 a-- <46.86g 0
/dev/mapper/sda4_crypt terravm lvm2 a-- <1.71t 0
root@terra:~# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move
Log Cpy%Sync Convert home terravm -wi-ao---- <1.71t root terravm -wi-ao---- 2.79g swap terravm -wi-ao---- <10.54g tmp terravm
-wi-ao---- <5.59g usr terravm -wi-ao---- 23.28g var terravm
-wi-ao---- <4.66g root@terra:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 1.8T 0 disk
├─sda1 8:1 0 16M 0 part
├─sda2 8:2 0 115G 0 part
└─sda3 8:3 0 1.7T 0 part
└─sda4_crypt 254:6 0 1.7T 0 crypt
└─terravm-home 254:7 0 1.7T 0 lvm /home
sdb 8:16 0 931.5G 0 disk
└─sdb1 8:17 0 931.5G 0 part /media/ulrich/A0E09159E091370E sdc 8:32 1
0B 0 disk sr0 11:0 1 1024M 0 rom
nvme0n1 259:0 0 238.5G 0 disk
├─nvme0n1p1 259:1 0 260M 0 part /boot/efi ├─nvme0n1p2 259:2 0 128M 0 part
├─nvme0n1p3 259:3 0 188.3G 0 part
├─nvme0n1p4 259:4 0 1G 0 part
├─nvme0n1p5 259:5 0 954M 0 part
├─nvme0n1p6 259:6 0 572M 0 part
├─nvme0n1p7 259:7 0 477M 0 part /boot
└─nvme0n1p8 259:8 0 46.9G 0 part
└─nvme0n1p8_crypt 254:0 0 46.9G 0 crypt
├─terravm-root 254:1 0 2.8G 0 lvm /
├─terravm-usr 254:2 0 23.3G 0 lvm /usr
├─terravm-tmp 254:3 0 5.6G 0 lvm /tmp
├─terravm-var 254:4 0 4.7G 0 lvm /var
└─terravm-swap 254:5 0 10.5G 0 lvm [SWAP]

Deine volume group terravm beinhaltet also sda4_crypt und
nvme0n1p8_crypt. Die beiden physical volumes müssen also beide vor
dem eigentlichen Start in das root System entschlüsselt werden. Hast
du für beide das selbe Passwort? Da könnte aus meiner Sicht das

Das Passwort ist für beide gleich und vor dem Upgrade musste ich es
auch nur einmal eingeben. Da kam zwar eine Warnung, das das PV nicht
gefunden werden kann (/home) und ich

Use '--activationmode partial' to override.

verwenden kann. Konnte ich nicht, war dann nicht mehr bootfähig. Vllt.
sollte ich das jetzt noch mal probieren?

Problem liegen. Werden denn innerhalb des initramfs beide PV's entschlüsselt.? Da habe ich ehrlich gesagt nicht drauf geachtet bei
deinen früheren Nachrichten.

Selbst wenn dein root nicht auf dem PV sda4_crypt liegt, so muss doch
meiner Meinung nach die komplette VG verfügbar sein, bevor
irgendwelche LV's eingehängt werden können.

s.o. Ich vermute mal, dass sich LVM, unter bullseye zumindest, nicht
daran gestört hat.
Ich probier das mal aus. Aber nicht mehr heute. Da brauch ich mehr Ruhe
:-)

Ach so:
$ cat /etc/crypttab
nvme0n1p8_crypt UUID=c7e5ef18-e011-47df-9054-6d3a67c37225 none luks,discard sda4_crypt UUID=758849c6-d27b-40c1-96c0-735fb7997bd5 none luks,discard terra_1_crypt UUID=4adbf944-34ae-4202-8b7c-152dfd249455 /root/tb1 luks,hash=plain,noauto

Die dritte Platte ist die Backup-Platte, die bindet auch problemlos
ein, wenn ich sie einstöpsel.

Das "discard" bei sda4 (normale HDD) macht wohl wenig Sinn, oder? Das
sollte ich wohl raus nehmen.

Danke und LG
Ulrich

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

Hallo

Am 25.06.23 um 20:10 schrieb Ulrich Fürst:

Das "discard" bei sda4 (normale HDD) macht wohl wenig Sinn, oder? Das
sollte ich wohl raus nehmen.

Danke und LG
Ulrich

Ja, wenns ne HDD ist brauchst du das nicht.

Du kannst auch einfach mal testweise sda4_crypt aus der vg rausnehmen.
Musst nur vorher sicherstellen, das sich root/usr/var usw. komplett auf
der SSD befindet. Dann könntest du es testen obs daran liegt.

Wenn ja wie bereits beschrieben das LV home in eine eigene VG.

Man könnte dann auch das sda4_crypt automatisch entschlüsseln lassen
mittels keyfile.

Andreas

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

Andreas wrote:

Hallo

Am 25.06.23 um 20:10 schrieb Ulrich Fürst:

Das "discard" bei sda4 (normale HDD) macht wohl wenig Sinn, oder?
Das sollte ich wohl raus nehmen.

Danke und LG
Ulrich

Ja, wenns ne HDD ist brauchst du das nicht.

Du kannst auch einfach mal testweise sda4_crypt aus der vg
rausnehmen. Musst nur vorher sicherstellen, das sich root/usr/var
usw. komplett auf der SSD befindet. Dann könntest du es testen obs
daran liegt.

das versuche ich jetzt endlich gerade :-(
ich konnte es entfernen und offensichtlich auch der neuen hinzufügen: lvremove /dev/mapper/home
vgcreate --autobackup y vghome /dev/mapper/sda4_crypt

# pvscan
PV /dev/mapper/sda4_crypt VG vghome lvm2 [1.7 TiB/<1.7 TiB free]
PV /dev/mapper/nvme0n1p8_crypt VG terravm lvm2 [<46.9 GiB / 0 free ]

Bevor ich mir da jetzt was kaputt mache (Backup existiert, wäre
aber ärgerlich) fehlt mir da jetzt noch ein
# lvextend -r -l +100%FREE /dev/mapper/sda4_crypt
??

Danke schon mal
Ulrich

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

Am Tue, Jul 11, 2023 at 07:35:17PM +0200 schrieb Ulrich Fürst:

Ulf Volmer wrote:

Am Tue, Jul 11, 2023 at 06:50:06PM +0200 schrieb Ulrich Fürst:

Andreas wrote:

Du kannst auch einfach mal testweise sda4_crypt aus der vg
rausnehmen. Musst nur vorher sicherstellen, das sich root/usr/var
usw. komplett auf der SSD befindet. Dann könntest du es testen obs daran liegt.

das versuche ich jetzt endlich gerade :-(
ich konnte es entfernen und offensichtlich auch der neuen
hinzufügen: lvremove /dev/mapper/home
vgcreate --autobackup y vghome /dev/mapper/sda4_crypt

# pvscan
PV /dev/mapper/sda4_crypt VG vghome lvm2 [1.7 TiB/<1.7 TiB
free] PV /dev/mapper/nvme0n1p8_crypt VG terravm lvm2 [<46.9 GiB /
0 free ]

Bevor ich mir da jetzt was kaputt mache (Backup existiert, wäre
aber ärgerlich) fehlt mir da jetzt noch ein
# lvextend -r -l +100%FREE /dev/mapper/sda4_crypt

parse error. Wieso möchtest Du ein lv- Kommando auf ein PV loslassen?

Aufgrund fehlenden Durchblicks :-/

Was ich versuche ist, ein PV aus einer VG herausnehmen (das hat soweit geklappt) und in eine neue VG rein tun. Das hat teils geklappt.
Ich kann es nämlich nicht aktivieren.
# vgchange -ay
zeigt mir beide VG an. Eine mit den zu erwartenden 4 (root, tmp,
var, swap) und die neue vghome mit 1 inaktiven.

Wieso 1 inaktives? Du hast die VG vghome doch oben erst erstellt?
Die sollte doch leer sein?

Grüße
Ulf

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

Am Tue, Jul 11, 2023 at 06:50:06PM +0200 schrieb Ulrich Fürst:

Andreas wrote:

Du kannst auch einfach mal testweise sda4_crypt aus der vg
rausnehmen. Musst nur vorher sicherstellen, das sich root/usr/var
usw. komplett auf der SSD befindet. Dann könntest du es testen obs
daran liegt.

das versuche ich jetzt endlich gerade :-(
ich konnte es entfernen und offensichtlich auch der neuen hinzufügen: lvremove /dev/mapper/home
vgcreate --autobackup y vghome /dev/mapper/sda4_crypt

# pvscan
PV /dev/mapper/sda4_crypt VG vghome lvm2 [1.7 TiB/<1.7 TiB free]
PV /dev/mapper/nvme0n1p8_crypt VG terravm lvm2 [<46.9 GiB / 0 free ]

Bevor ich mir da jetzt was kaputt mache (Backup existiert, wäre
aber ärgerlich) fehlt mir da jetzt noch ein
# lvextend -r -l +100%FREE /dev/mapper/sda4_crypt

parse error. Wieso möchtest Du ein lv- Kommando auf ein PV loslassen?
Aus Deiner Schilderung oben lese ich, dass Du jetzt eine leere VG vghome
hast.
Wenn Du darin ein LV erstellen möchtest, geht das mit

lvcreate -n <name> -l +100%FREE vghome

Dann halt mkfs.XXX und fstab anpassen.

Viele Grüße
Ulf

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

Ulf Volmer wrote:

Am Tue, Jul 11, 2023 at 06:50:06PM +0200 schrieb Ulrich Fürst:

Andreas wrote:

Du kannst auch einfach mal testweise sda4_crypt aus der vg
rausnehmen. Musst nur vorher sicherstellen, das sich root/usr/var
usw. komplett auf der SSD befindet. Dann könntest du es testen obs
daran liegt.

das versuche ich jetzt endlich gerade :-(
ich konnte es entfernen und offensichtlich auch der neuen
hinzufügen: lvremove /dev/mapper/home
vgcreate --autobackup y vghome /dev/mapper/sda4_crypt

# pvscan
PV /dev/mapper/sda4_crypt VG vghome lvm2 [1.7 TiB/<1.7 TiB
free] PV /dev/mapper/nvme0n1p8_crypt VG terravm lvm2 [<46.9 GiB /
0 free ]

Bevor ich mir da jetzt was kaputt mache (Backup existiert, wäre
aber ärgerlich) fehlt mir da jetzt noch ein
# lvextend -r -l +100%FREE /dev/mapper/sda4_crypt

parse error. Wieso möchtest Du ein lv- Kommando auf ein PV loslassen?

Aufgrund fehlenden Durchblicks :-/

Was ich versuche ist, ein PV aus einer VG herausnehmen (das hat soweit geklappt) und in eine neue VG rein tun. Das hat teils geklappt.
Ich kann es nämlich nicht aktivieren.
# vgchange -ay
zeigt mir beide VG an. Eine mit den zu erwartenden 4 (root, tmp,
var, swap) und die neue vghome mit 1 inaktiven.

Der Plan war eben die Homepartition (die in einer VG aber auf eigener
HD lag) aus der VG heraus zu nehmen und in eine eigene VG zu packen,
in der Hoffnung die Bootprobleme zu lösen oder zumindest einzugrenzen.

Welche Befehlsausgaben braucht ihr um mir helfen zu können. Und v.a.
was von der Ausgabe? Abtippen ist leider fehlerträchtig :-(

Danke schon mal
Ulrich

P.S. Warum ich überhaupt LVM nutze? Hat mich auf dem Laptop schon öfter gerettet, weil sonst Updates gar nicht mehr machbar gewesen wären...

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

Ulf Volmer wrote:

Am Tue, Jul 11, 2023 at 07:35:17PM +0200 schrieb Ulrich Fürst:

Ulf Volmer wrote:

Am Tue, Jul 11, 2023 at 06:50:06PM +0200 schrieb Ulrich Fürst:

Andreas wrote:

Du kannst auch einfach mal testweise sda4_crypt aus der vg rausnehmen. Musst nur vorher sicherstellen, das sich
root/usr/var usw. komplett auf der SSD befindet. Dann
könntest du es testen obs daran liegt.

das versuche ich jetzt endlich gerade :-(
ich konnte es entfernen und offensichtlich auch der neuen
hinzufügen: lvremove /dev/mapper/home
vgcreate --autobackup y vghome /dev/mapper/sda4_crypt

# pvscan
PV /dev/mapper/sda4_crypt VG vghome lvm2 [1.7 TiB/<1.7
TiB free] PV /dev/mapper/nvme0n1p8_crypt VG terravm lvm2
[<46.9 GiB / 0 free ]

Bevor ich mir da jetzt was kaputt mache (Backup existiert, wäre
aber ärgerlich) fehlt mir da jetzt noch ein
# lvextend -r -l +100%FREE /dev/mapper/sda4_crypt

parse error. Wieso möchtest Du ein lv- Kommando auf ein PV
loslassen?

Aufgrund fehlenden Durchblicks :-/

Was ich versuche ist, ein PV aus einer VG herausnehmen (das hat
soweit geklappt) und in eine neue VG rein tun. Das hat teils
geklappt. Ich kann es nämlich nicht aktivieren.
# vgchange -ay
zeigt mir beide VG an. Eine mit den zu erwartenden 4 (root, tmp,
var, swap) und die neue vghome mit 1 inaktiven.

Wieso 1 inaktives? Du hast die VG vghome doch oben erst erstellt?
Die sollte doch leer sein?

Ich hatte es so verstanden, dass der vgcreate Befehl oben, das PV der
neuen VG hinzufügt. Und jetzt sagt:
# vgchange -ay vghome
0 logical volume(s) in vg "vghome" now active

Also keine aktiven.
Lass mich raten: ich hab mir mein /home bereits gelöscht?
Oder ist da noch was zu retten?

Die Hoffnung stirbt zuletzt
Ulrich

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

Andreas wrote:

Du kannst auch einfach mal testweise sda4_crypt aus der vg
rausnehmen. Musst nur vorher sicherstellen, das sich root/usr/var
usw. komplett auf der SSD befindet. Dann könntest du es testen obs
daran liegt.

Tat es wohl. Der Rechner startet jetzt - abgesehen davon, dass ich kein
/home mehr habe :-(

Ulrich

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

Noch eine Frage:
Wenn ich /home sowieso in einer anderen VG habe, kann ich den Platz
dort ja auch nicht mehr nutzen um z.B. einer der anderen LV in der
anderen VG Platz abzugeben. Das war quasi einer der Hauptgründe für die
ganze LVM-Geschichte.

Macht es dann einen Unterschied, wenn ich /home einfach in gar kein
neue VG packe, sondern einfach als normale Partition handhabe (solange
ich nicht eine dritte Festplatte einbauen will, weil mir der Platz
ausgeht...)?

Danke schon mal und schönen Abend
Ulrich

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

Am Tue, Jul 11, 2023 at 09:40:21PM +0200 schrieb Ulrich Fürst:

Noch eine Frage:
Wenn ich /home sowieso in einer anderen VG habe, kann ich den Platz
dort ja auch nicht mehr nutzen um z.B. einer der anderen LV in der
anderen VG Platz abzugeben. Das war quasi einer der Hauptgründe für die
ganze LVM-Geschichte.

Ja.

Macht es dann einen Unterschied, wenn ich /home einfach in gar kein
neue VG packe, sondern einfach als normale Partition handhabe (solange
ich nicht eine dritte Festplatte einbauen will, weil mir der Platz ausgeht...)?

Das macht dann keinen Unterschied mehr. Außer, Du möchtest auf Deiner
HDD weitere Filesysteme flexiblel verwalten können.
Hier z.B. ist /var/lib/libvirt ein solches.

Viele Grüße
Ulf

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

Am Tue, Jul 11, 2023 at 09:20:41PM +0200 schrieb Ulrich Fürst:

Ulf Volmer wrote:

Am Tue, Jul 11, 2023 at 07:35:17PM +0200 schrieb Ulrich Fürst:

Ulf Volmer wrote:

Am Tue, Jul 11, 2023 at 06:50:06PM +0200 schrieb Ulrich Fürst:

Andreas wrote:

Du kannst auch einfach mal testweise sda4_crypt aus der vg rausnehmen. Musst nur vorher sicherstellen, das sich
root/usr/var usw. komplett auf der SSD befindet. Dann
könntest du es testen obs daran liegt.

das versuche ich jetzt endlich gerade :-(
ich konnte es entfernen und offensichtlich auch der neuen
hinzufügen: lvremove /dev/mapper/home
vgcreate --autobackup y vghome /dev/mapper/sda4_crypt

# pvscan
PV /dev/mapper/sda4_crypt VG vghome lvm2 [1.7 TiB/<1.7
TiB free] PV /dev/mapper/nvme0n1p8_crypt VG terravm lvm2
[<46.9 GiB / 0 free ]

Bevor ich mir da jetzt was kaputt mache (Backup existiert, wäre
aber ärgerlich) fehlt mir da jetzt noch ein
# lvextend -r -l +100%FREE /dev/mapper/sda4_crypt

parse error. Wieso möchtest Du ein lv- Kommando auf ein PV
loslassen?

Aufgrund fehlenden Durchblicks :-/

Was ich versuche ist, ein PV aus einer VG herausnehmen (das hat
soweit geklappt) und in eine neue VG rein tun. Das hat teils
geklappt. Ich kann es nämlich nicht aktivieren.
# vgchange -ay
zeigt mir beide VG an. Eine mit den zu erwartenden 4 (root, tmp,
var, swap) und die neue vghome mit 1 inaktiven.

Wieso 1 inaktives? Du hast die VG vghome doch oben erst erstellt?
Die sollte doch leer sein?

Ich hatte es so verstanden, dass der vgcreate Befehl oben, das PV der
neuen VG hinzufügt. Und jetzt sagt:

vgcreate erzeugt halt ein neues VG. Ich würde mit einer Fehlermeldung
rechnen, wenn es schon existiert, aber egal.
Den gewünschten Effekt hätte wohl ein vgextend erzeugt.
Weiterhin hattest Du in der Zeile vorher mit lvremove Dein home LV ja
sowieso schon gelöscht.

# vgchange -ay vghome
0 logical volume(s) in vg "vghome" now active

Also keine aktiven.
Lass mich raten: ich hab mir mein /home bereits gelöscht?
Oder ist da noch was zu retten?

Ich würde mir da nicht viel Hoffnung machen.
Aber Du schriebst ja, Du hättest eine Backup, also was soll's.

Viele Grüße
Ulf

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

Am Tue, Jul 11, 2023 at 10:40:21PM +0200 schrieb Ulrich Fürst:

Ich möchte diesmal sicher gehen, dass ich mir nicht noch mehr Arbeit
mache.

Es ist halt schwierig, wenn man neue Techniken an einem produktiven
System lernt. Da mußt Du halt durch.

Mit
# vgremove vghome
lösche ich die neuangelegte VG

Jau. Im Anschluß noch ein pvremove um die LVM Signaturen vom PV zu
entfernen.

Jetzt einfach formatieren? mit
# mkfs.ext4 -c -L home

So in der Art.

Viele Grüße
Ulf

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

Ulf Volmer wrote:

Am Tue, Jul 11, 2023 at 09:40:21PM +0200 schrieb Ulrich Fürst:

Macht es dann einen Unterschied, wenn ich /home einfach in gar kein
neue VG packe, sondern einfach als normale Partition handhabe
(solange ich nicht eine dritte Festplatte einbauen will, weil mir
der Platz ausgeht...)?

Das macht dann keinen Unterschied mehr. Außer, Du möchtest auf Deiner
HDD weitere Filesysteme flexiblel verwalten können.
Hier z.B. ist /var/lib/libvirt ein solches.

Ich möchte diesmal sicher gehen, dass ich mir nicht noch mehr Arbeit
mache.

Mit
# vgremove vghome
lösche ich die neuangelegte VG
Jetzt einfach formatieren? mit
# mkfs.ext4 -c -L home

Da bekomme ich die Warnung, dass sda4_crypt ein LVM2_member file system enthält. Zerschieße ich mir damit jetzt auch den Rest oder darf ich das
als normal ansehen, immerhin war es ja in einem LVM.
lvscan listet es nicht und pvscan sagt
# pvscan
PV /d/m/nvme0n1p8_crypt (das ist Debian ohne /home) und
PV /d/m/sda4_crypt"
Total: 2 / in use: 1 / in no VG: 1

Viele Grüße
Ulrich

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

Hallo

Am 11.07.23 um 21:15 schrieb Ulrich Fürst:

Andreas wrote:

Du kannst auch einfach mal testweise sda4_crypt aus der vg
rausnehmen. Musst nur vorher sicherstellen, das sich root/usr/var
usw. komplett auf der SSD befindet. Dann könntest du es testen obs
daran liegt.

Tat es wohl. Der Rechner startet jetzt - abgesehen davon, dass ich kein
/home mehr habe :-(

Ulrich

Freut mich zu lesen. Das du dein Home gelöscht hast sollte kein Problem
sein da du ja ein Backup hast. Man kann über Umwege mittels vgsplit auch
ein LV von einer in eine neue VG "kopieren". Ist aber sehr umständlich
und das habe ich vor vielen Jahren das erste und einzige Mal gemacht.
Ich denke wenn du nun deine vghome erstellt hast und dein LV drin
formatiert hast kannst du es einfach einbinden und dein Backup zurückspiele.

Andreas

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

Ulf Volmer wrote:

Am Tue, Jul 11, 2023 at 10:40:21PM +0200 schrieb Ulrich Fürst:

Jetzt einfach formatieren? mit
# mkfs.ext4 -c -L home

So in der Art.

Was würdest Du anders machen? Anderes Dateisystem? root-Anteil
verkleinern (bei reiner Datenpartition)? Was ganz anderes?

Viele Grüße
Ulrich

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

Ulrich Fürst wrote:

Ulf Volmer wrote:

Am Tue, Jul 11, 2023 at 10:40:21PM +0200 schrieb Ulrich Fürst:

Jetzt einfach formatieren? mit
# mkfs.ext4 -c -L home

So in der Art.

Was würdest Du anders machen? Anderes Dateisystem? root-Anteil
verkleinern (bei reiner Datenpartition)? Was ganz anderes?

Oder meinst Du mit "So in der Art", es wäre eine gute Idee die Partition
noch mit anzugeben. Das hätte ich dann im Ernstfall schon gemacht :-)

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

On 13.07.23 13:43, Ulrich Fürst wrote:

Ulrich Fürst wrote:

Ulf Volmer wrote:

Am Tue, Jul 11, 2023 at 10:40:21PM +0200 schrieb Ulrich Fürst:

Jetzt einfach formatieren? mit
# mkfs.ext4 -c -L home

So in der Art.

Was würdest Du anders machen? Anderes Dateisystem? root-Anteil
verkleinern (bei reiner Datenpartition)? Was ganz anderes?

Oder meinst Du mit "So in der Art", es wäre eine gute Idee die Partition noch mit anzugeben. Das hätte ich dann im Ernstfall schon gemacht :-)

Ja, das wollte ich damit ausdrücken.

Viele Grüße
Ulf

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

Am Wed, 12 Jul 2023 16:17:47 +0200
schrieb Andreas <ahort@t-online.de>:

Freut mich zu lesen. Das du dein Home gelöscht hast sollte kein
Problem sein da du ja ein Backup hast. Man kann über Umwege mittels
vgsplit auch ein LV von einer in eine neue VG "kopieren". Ist aber
sehr umständlich und das habe ich vor vielen Jahren das erste und
einzige Mal gemacht. Ich denke wenn du nun deine vghome erstellt hast
und dein LV drin formatiert hast kannst du es einfach einbinden und
dein Backup zurückspiele.

Ja, ich danke Euch beiden!
das -c hat mich die letzte Nacht gekostet, heute Morgen dann Backup zurückgespielt (bzw. vor der Arbeit den Vorgang angschubst) und jetzt
ist alles wie vorher.
Fast, weil ja jetzt auch das booten ohne manuellen Eingriff klappt :-)

Lehrgeld gezahlt, Projekt abgeschlossen
Danke und schönes Wochenende
Ulrich

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