• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Nach der Aktualisierung von dracut kann die verschlüsselte Festplatte nicht mehr entschlüsselt werden

Hallo alle zusammen,

ich habe auf meinem Notebook openSUSE 15.0 installiert. Zuvor war openSUSE Leap 42.3 drauf. Die Installation von DVD, ohne die Aktualisierungen einzuspielen, verläuft problemlos. Wenn ich jedoch udev (bluez-qt-udev, dracut, libudev1, udev) mit seinen Abhängigkeiten (systemd-sysvinit, systemd) aktualisieren möchte, dann kann ich nach dem Neustart meine Festplatte nicht mehr entschlüsseln (Kennworteingabe schlägt jedes Mal fehl).
Weiß jemand von euch Rat? Danke! :)

Die Partitionierung sieht wie folgt aus:
(auf sda1 liegt boot; die Volumes habe ich über die SystemrescueCD nicht eingebunden)
Code:
blkid -o list
device     fs_type label    mount point    UUID
-------------------------------------------------------------------------------
/dev/loop0 squashfs         /livemnt/squashfs 
/dev/sda1  ext4             (not mounted)  2af229cd-98c3-44d0-bfd5-6e781a2f60ab
/dev/sda2  crypto_LUKS      (in use)       4217b44c-fccb-4dee-b9dc-ce9999773ce1
/dev/sr0   iso9660 sysrcd-5.1.2 /livemnt/boot 2017-11-05-07-58-07-00
/dev/mapper/HDD
           LVM2_member      (in use)       p8pUTI-dpQn-eLyI-sODS-ilt0-6rxi-J09ZXE
/dev/mapper/MeinPlatte-home
           ext4             (not mounted)  ad8b36ff-7200-498a-b76a-2d5863994f1f
/dev/mapper/MeinPlatte-root
           ext4             (not mounted)  2f95f855-d426-4223-b7ed-59ecb8e04c21
/dev/mapper/MeinPlatte-swap
           swap             (not mounted)  89933b0e-87d8-4f43-bd72-2660ab6d9a18
/dev/mapper/MeinPlatte-tmp
           ext4             (not mounted)  dff28b47-02e0-413f-9fad-177321961407

(Teil-)Lösung: Die Aktualisierung von dracut ändert bei der Kennworteingabe die deutsche Tastaturbelegung auf die US-Belegung.
Auf meinem Notebook verschwand, nach einer Neuinstallation, das Problem. Dies funktionierte allerdings nur bei meinem Notebook, bisher jedoch nicht bei meinem Hauptrechner.
Wie man die Tastaturbelegung unter openSUSE 15.0 wieder rückgängig machen kann ist mir bisher nicht gekannt.
 

spoensche

Moderator
Teammitglied
Step 1:

Das installierte System mounten. Die ganzen LVM's.

Code:
mount /dev/mapper/MeinPlatte-root /mnt
mount /dev/mapper/MeinPlatte-home /mnt/home
mount /dev/mapper/MeinPlatte-tmp /mnt/tmp

Step 2:
Dein installiertes System Root Umgebung nutzen, damit du dir das systemd Log ansehen kannst.

Code:
chroot /mnt

Step 3:
Poste mal bitte die Ausgabe von

Code:
journalctl --no-pager | egrep "cryptsetup|luks"

Step 4:
Rebuild der initrd

Code:
dracut -f

Step 5:
chroot Umgebung verlassen.

Code:
exit

Step 6:

System rebooten und das installierte System hochfahren lassen.
 
Hallo,
vielen Dank für deine Antwort und entschuldige bitte, dass meine Antwort erst jetzt kommt.
Ich habe die von dir genannten Befehle unter Knoppix 8.1 ausgeführt, doch sie haben nicht funktioniert:
Code:
knoppix@Microknoppix:~$ su
root@Microknoppix:/home/knoppix# mkdir /mnt/home
root@Microknoppix:/home/knoppix# mkdir /mnt/tmp
root@Microknoppix:/home/knoppix# cryptsetup luksOpen /dev/sda2 LinuxKrypt
Geben Sie die Passphrase für »/dev/sda2« ein: 
root@Microknoppix:/home/knoppix# mount /dev/mapper/
control          MeinPlatte-home  MeinPlatte-swap  
LinuxKrypt       MeinPlatte-root  MeinPlatte-tmp   
root@Microknoppix:/home/knoppix# mount /dev/mapper/MeinPlatte-root /mnt
root@Microknoppix:/home/knoppix# mount /dev/mapper/MeinPlatte-home /mnt/home/
root@Microknoppix:/home/knoppix# mount /dev/mapper/MeinPlatte-tmp /mnt/tmp/
root@Microknoppix:/home/knoppix# chroot /mnt
:/ # journalctl --no-pager | egrep "cryptsetup|luks"
No journal files were found.
:/ # dracut -f
dracut: Cannot find module directory /lib/modules/4.12.7-64/
dracut: and --no-kernel was not specified
:/ #
 

abgdf

Guru
Schweineschwarte schrieb:
Code:
knoppix@Microknoppix:~$ su
root@Microknoppix:/home/knoppix# mkdir /mnt/home
root@Microknoppix:/home/knoppix# mkdir /mnt/tmp
root@Microknoppix:/home/knoppix# cryptsetup luksOpen /dev/sda2 LinuxKrypt
Geben Sie die Passphrase für »/dev/sda2« ein: 
root@Microknoppix:/home/knoppix# mount /dev/mapper/
control          MeinPlatte-home  MeinPlatte-swap  
LinuxKrypt       MeinPlatte-root  MeinPlatte-tmp   
root@Microknoppix:/home/knoppix# mount /dev/mapper/MeinPlatte-root /mnt
root@Microknoppix:/home/knoppix# mount /dev/mapper/MeinPlatte-home /mnt/home/
root@Microknoppix:/home/knoppix# mount /dev/mapper/MeinPlatte-tmp /mnt/tmp/
Bis dahin sieht das doch schonmal gut aus. Kannst Du denn jetzt darauf zugreifen? Oder nur von Knoppix?
 
Ich kann nur über Live-CDs/DVDs zugreifen, außer wenn ich openSUSE neu installiere, ohne Aktualisierungen (dann auch über openSUSE). Nach der Aktualisierung von udev bzw. systemd geht es mit openSUSE nicht mehr.
Ich kann euch nachher noch einmal die entsprechenden Versionen nennen.
 

spoensche

Moderator
Teammitglied
Gehe noch mal wie oben beschrieben in die Chroot umgebung und führe den dracut Befehl wie folgt aus:

Code:
dracut -k lib/modules/4.12.7-64/ -f
 

josef-wien

Ultimate Guru
Nur so ins Blaue hineingefragt: Passen die Kernel (und die initrd) auf der Boot-Partition zu den Modul-Verzeichnissen auf der Systempartition? Ist die Boot-Partition sowohl bei der Erstinstallation als auch bei der Systemaktualisierung (die ja erst das Problem verursacht) korrekt eingehängt?

P. S. In der chroot-Umgebung ist die Boot-Partition nicht eingehängt, somit würde eine neue initrd am falschen Ort gespeichert werden.
 
Ich habe eben openSUSE 15.0 noch einmal neu installiert, um die Paketversionen nennen zu können, aber nun funktioniert alles nach der Aktualisierung... Und jetzt bin ich schon fast etwas brüskiert, aber ich freue mich dennoch, dass es wieder läuft :)
Ich danke euch für eure Hilfe, auch wenn man wohl einfach etwas hätte warten sollen :eek:ps:

Direkt nach der Installation und vor dem Update sieht es wie folgt aus:
Partitionierung:
Code:
blkid -o list
device                    fs_type    label       mount point                   UUID
-------------------------------------------------------------------------------------------------------------------
/dev/sda1                 ext4                   /boot                         6009e466-7c59-433d-9c40-351d116704bd
/dev/sda2                 crypto_LUKS            (in use)                      4217b44c-fccb-4dee-b9dc-ce9999773ce1
/dev/sr0                  iso9660    openSUSE-Leap-15.0-DVD-x86_64267 (not mounted) 2018-05-16-17-45-22-53
/dev/mapper/cr-auto-1     LVM2_member            (in use)                      p8pUTI-dpQn-eLyI-sODS-ilt0-6rxi-J09ZXE
/dev/mapper/MeinPlatte-swap
                          swap                   [SWAP]                        6debbfed-7fad-4573-9ac5-99758cfd4659
/dev/mapper/MeinPlatte-root
                          ext4                   /                             58203012-50dd-4de5-9469-702ded50739f
/dev/mapper/MeinPlatte-home
                          ext4                   /home                         ad8b36ff-7200-498a-b76a-2d5863994f1f
/dev/mapper/MeinPlatte-tmp
                          ext4                   /tmp                          d6ba7063-0d8e-436b-af3a-2f7898477cbc

Pakete (i) und die Aktualisierungen (v) welche nun funktionieren:
Code:
zypper se -s --match-exact udev libudev1 bluez-qt-udev dracut systemd-sysvinit systemd
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...

S | Name             | Typ        | Version            | Arch   | Repository               
--+------------------+------------+--------------------+--------+--------------------------
i | bluez-qt-udev    | Paket      | 5.45.0-lp150.1.1   | x86_64 | openSUSE-Leap-15.0-Oss   
i | bluez-qt-udev    | Paket      | 5.45.0-lp150.1.1   | x86_64 | openSUSE-Leap-15.0-1     
v | dracut           | Paket      | 044.1-lp150.14.3.1 | x86_64 | openSUSE-Leap-15.0-Update
i | dracut           | Paket      | 044.1-lp150.13.6   | x86_64 | openSUSE-Leap-15.0-Oss   
i | dracut           | Paket      | 044.1-lp150.13.6   | x86_64 | openSUSE-Leap-15.0-1     
  | dracut           | Quellpaket | 044.1-lp150.14.3.1 | noarch | openSUSE-Leap-15.0-Update
v | libudev1         | Paket      | 234-lp150.20.6.1   | x86_64 | openSUSE-Leap-15.0-Update
v | libudev1         | Paket      | 234-lp150.20.3.1   | x86_64 | openSUSE-Leap-15.0-Update
i | libudev1         | Paket      | 234-lp150.19.1     | x86_64 | openSUSE-Leap-15.0-Oss   
i | libudev1         | Paket      | 234-lp150.19.1     | x86_64 | openSUSE-Leap-15.0-1     
v | systemd          | Paket      | 234-lp150.20.6.1   | x86_64 | openSUSE-Leap-15.0-Update
v | systemd          | Paket      | 234-lp150.20.3.1   | x86_64 | openSUSE-Leap-15.0-Update
i | systemd          | Paket      | 234-lp150.19.1     | x86_64 | openSUSE-Leap-15.0-Oss   
i | systemd          | Paket      | 234-lp150.19.1     | x86_64 | openSUSE-Leap-15.0-1     
  | systemd          | Quellpaket | 234-lp150.20.6.1   | noarch | openSUSE-Leap-15.0-Update
  | systemd          | Quellpaket | 234-lp150.20.3.1   | noarch | openSUSE-Leap-15.0-Update
v | systemd-sysvinit | Paket      | 234-lp150.20.6.1   | x86_64 | openSUSE-Leap-15.0-Update
v | systemd-sysvinit | Paket      | 234-lp150.20.3.1   | x86_64 | openSUSE-Leap-15.0-Update
i | systemd-sysvinit | Paket      | 234-lp150.19.1     | x86_64 | openSUSE-Leap-15.0-Oss   
i | systemd-sysvinit | Paket      | 234-lp150.19.1     | x86_64 | openSUSE-Leap-15.0-1     
v | udev             | Paket      | 234-lp150.20.6.1   | x86_64 | openSUSE-Leap-15.0-Update
v | udev             | Paket      | 234-lp150.20.3.1   | x86_64 | openSUSE-Leap-15.0-Update
i | udev             | Paket      | 234-lp150.19.1     | x86_64 | openSUSE-Leap-15.0-Oss   
i | udev             | Paket      | 234-lp150.19.1     | x86_64 | openSUSE-Leap-15.0-1
 
Ich hatte es ja schon einmal neu installiert, aber da waren wohl die Aktualisierungspakete noch fehlerhaft.
Aber nun funktioniert ja alles :thumbs:
 

spoensche

Moderator
Teammitglied
Neuinstallation ist keine Lösung, man verschiebt das Problem auf einen späteren Zeitpunkt.

Unter Linux hat man die Möglichkeit zum reparieren und Logmeldungen sagen auch, wo man gucken muss.

Bei M$ ist Neuinstallation eine Lösung und das M$ für seine Cloud Linux als AzureOS einsetzen will, sagt doch alles. Ihr Betriebsystem taugt nix.
 
Jetzt habe ich meinen Hauptrechner von openSUSE 42.3 auf openSUSE 15.0 aktualisiert, welcher ebenfalls verschlüsselt ist, nur zusätzlich noch ein Soft-RAID-1 (Spiegelung) besitzt.
Nun habe ich jedoch wieder das gleiche Problem. Auch hier wird nach der Aktualisierung ebenfalls nicht das Kennwort erkannt. :zensur: :irre: (dieses Mal habe ich aber alles was zur Verfügung stand aktualisiert)
Ich habe nun das System wieder unter Knoppix 8.1 gestartet und die Partitionen entsprechend eingebunden:
Code:
blkid -o list
device     fs_type label    mount point    UUID
-------------------------------------------------------------------------------
/dev/cloop0
           iso9660 KNOPPIX_FS /KNOPPIX     2017-09-18-02-30-40-81
/dev/cloop1
           iso9660 KNOPPIX_ADDONS1 /KNOPPIX1 2017-09-13-18-09-11-00
/dev/zram0 swap             [SWAP]         10461dc6-b1f9-491f-bf7b-9e341da8260a
/dev/sda1  linux_raid_member any:DasRAID1-boot (in use) 2786a51b-7a91-b691-ffd9-605631585bfd
/dev/sda2  linux_raid_member any:DasRAID1-Linux (in use) 4f2088c5-fcba-7831-0956-9aa1a41f9d18
/dev/sda3  linux_raid_member any:DasRAID1-Krypt (in use) f31a3b5f-2080-f902-5abd-783237ac5c6d
/dev/sdb1  linux_raid_member any:DasRAID1-boot (in use) 2786a51b-7a91-b691-ffd9-605631585bfd
/dev/sdb2  linux_raid_member any:DasRAID1-Linux (in use) 4f2088c5-fcba-7831-0956-9aa1a41f9d18
/dev/sdb3  linux_raid_member any:DasRAID1-Krypt (in use) f31a3b5f-2080-f902-5abd-783237ac5c6d
/dev/sr0   iso9660 KNOPPIX_8 /mnt-system   2017-09-18-01-34-11-00
/dev/md127 ext4             /mnt/boot      64d35909-f452-4b78-8c4d-a172f90e296f
/dev/md125 crypto_LUKS      (in use)       8de5e14e-2705-46fb-8285-bdb02e4fef88
/dev/mapper/Linux
           LVM2_member      (in use)       ha1aLk-w5uW-rlyT-gc1n-auNV-aT8P-t0oc2a
/dev/mapper/DiePlatte-home
           ext4             /mnt/home      c31fa81f-283c-4aa0-a9fa-26695f8ac245
/dev/mapper/DiePlatte-root
           ext4             /mnt           d24aae76-cba2-4f16-a93b-381437f48544
/dev/mapper/DiePlatte-swap
           swap             (not mounted)  a3bd4756-0445-46ae-a3ba-55ef231b58b0
/dev/mapper/DiePlatte-tmp
           ext4             /mnt/tmp       9ecf8fa7-22cb-4cf8-9970-c3127b79b68c
Anschließend habe ich
Code:
dracut -k lib/modules/4.12.7-64/ -f
ausgeführt, allerdings, funktionierte dies nicht. Ebenfalls mit der Meldung
Code:
dracut: Cannot find module directory /lib/modules/4.12.7-64/
dracut: and --no-kernel was not specified
Im Ordner lib/modules gab es jedoch ein Verzeichnis namens 4.12.14-lp150.12.16-default, welches ich verwendet habe und mit dem dracut auch scheinbar zurecht kam. Ein Neustart brauchte jedenfalls keine Verbesserung. Scheinbar eher das Gegenteil. Als ich danach ein weiteres Mal Knoppix gestartet und alles eingebunden hatte wollte ich
Code:
systemctl --no-pager | egrep "cryptsetup|luks"
ausführen, doch dieses Mal kam die Fehlermeldung
Code:
:/ # systemctl --no-pager | egrep "cryptsetup|luks"
Failed to connect to bus: No such file or directory
:/

Beim letzten Versuch mich beim Booten anzumelden hatte ich mal Esc gedrückt, um zum Terminal zu gelangen, und dort stand nach drei fehlgeschlagenen Versuchen die Meldung:
Code:
[FAILED] Failed to start Cryptography Setup for cr-auto-1.
See 'systemctl status "systemd-cryptsetup@cr\\x2dauto\\x2d1.service"' for details.
[DEPEND] Dependency failed for Encrypted Volumes.
Allerdings kann ich nach dem vollführten dracut - wie beschrieben - nicht mehr auf systemctl zugreifen :/
Wenn also noch jemand von euch Rat hat wie ich das lösen kann, wäre ich sehr dankbar. :)
 
Ich glaube ich habe diese Installation nun zerschossen ^^
Ich dachte ich mache mal ein Downgrade der entsprechenden Pakete:
Knoppix starten -> entschlüsseln -> die Volumes einbinden -> DNS verknüpfen* -> chroot
und dann folgenden Befehl:
Code:
zypper --non-interactive in -f libsystemd0=234-lp150.19.1 systemd=234-lp150.19.1 systemd-sysvinit=234-lp150.19.1 libudev1=234-lp150.19.1 udev=234-lp150.19.1

Aber das war scheinbar keine so gute Idee. Jedenfalls kommt jetzt gar keine Kennwortabfrage mehr. :/
Bevor die Arbeit nun überhand nimmt mache ich noch mal eine Neuinstallation und wenn nach einer Aktualisierung der Pakete es wieder nicht geht, dann können wir - wenn ihr auch wollt - wieder an einer frischen Installation weiterarbeiten.
Ich glaube im Moment habe ich zu viel kaputt gemacht ^^

* https://superuser.com/questions/1329646/why-do-i-have-to-specify-dns-when-using-chroot
 
So, ich hatte nun openSUSE 15.0 noch einmal neu installiert und nur udev, libudev1, systemd und systemd-sysvinit aktualisiert und es funktionierte danach noch alles. Anschließend habe ich ausschließlich dracut aktualisiert und es ging nicht mehr... Ich werde mal den Paketersteller kontaktieren.

p.s.: Ich habe den Beitragstitel entsprechend angepasst.
 
Der Paketersteller meinte:
"Wenn mit den Experten dort eine eindeutige Fehlereingrenzung gelingt,
die der Benutzer nicht selbst beheben kann, könnte das über Bugzilla an
den Entwickler weitergeleitet werden."

Ich weiß nun nicht wie genau der Fehler eingegrenzt sein muss, aber scheinbar reicht die Benennung von dracut+Version nicht. :/
Ich wäre euch also sehr verbunden, wenn ihr mir bei der Fehlereingrenzung helfen könntet, bzw. weiter helft um das Problem vielleicht ganz zu lösen :)
Danke!
 

spoensche

Moderator
Teammitglied
Verwende mal mkinitrd.
Bevor du in die chroot Umgebung wechselst musst du noch
Code:
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys

Danach in die chroot Umgebung wechseln und
Code:
mkinitrd

ausführen.

Sieh dir auch mal https://forums.opensuse.org/showthread.php/527788-No-boot-after-update-of-encrypted-system an.
 
Das brachte leider keine Verbesserung. Das Kennwort wird weiterhin nicht angenommen und nach der dritten Eingabe erfolgt weiterhin die Meldung:
Code:
[FAILED] Failed to start Cryptography Setup for cr-auto-1.
See 'systemctl status "systemd-cryptsetup@cr\\x2dauto\\x2d1.service"' for details.
[DEPEND] Dependency failed for Encrypted Volumes.
Auf der Gitlab-Seite von cryptsetup meinen sie, dass man sich bei dieser Meldung an den Distributionsanbieter wenden soll:
https://gitlab.com/cryptsetup/cryptsetup/issues/205

Bei mkinitrd kamen ein paar Meldungen über fehlende Firmware. Ich weiß aber nicht, ob das nun etwas mit diesem Problem zu tun hat.
Code:
knoppix@Microknoppix:~$ su
root@Microknoppix:/home/knoppix# mkdir /mnt/home
root@Microknoppix:/home/knoppix# mkdir /mnt/tmp
root@Microknoppix:/home/knoppix# mkdir /mnt/boot
root@Microknoppix:/home/knoppix# mkdir /mnt/dev
root@Microknoppix:/home/knoppix# mkdir /mnt/proc
root@Microknoppix:/home/knoppix# mkdir /mnt/sys
root@Microknoppix:/home/knoppix# cryptsetup luksOpen /dev/md
md/    md125  md126  md127  
root@Microknoppix:/home/knoppix# cryptsetup luksOpen /dev/md126 Linux
Geben Sie die Passphrase für »/dev/md126« ein: 
root@Microknoppix:/home/knoppix# mount /dev/mapper/DiePlatte-root /mnt/
root@Microknoppix:/home/knoppix# mount /dev/mapper/DiePlatte-home /mnt/home/
root@Microknoppix:/home/knoppix# mount /dev/mapper/DiePlatte-tmp /mnt/tmp/
root@Microknoppix:/home/knoppix# mount /dev/md127 /mnt/boot/
root@Microknoppix:/home/knoppix# mount --bind /dev /mnt/dev/
root@Microknoppix:/home/knoppix# mount --bind /proc /mnt/proc
root@Microknoppix:/home/knoppix# mount --bind /sys /mnt/sys
root@Microknoppix:/home/knoppix# chroot /mnt
Microknoppix:/ # mkinitrd
Creating initrd: /boot/initrd-4.12.14-lp150.11-default
dracut: Executing: /usr/bin/dracut --logfile /var/log/YaST2/mkinitrd.log --force /boot/initrd-4.12.14-lp150.11-default 4.12.14-lp150.11-default
dracut: *** Including module: bash ***
dracut: *** Including module: systemd ***
dracut: *** Including module: warpclock ***
dracut: *** Including module: systemd-initrd ***
dracut: *** Including module: i18n ***
dracut: Could not find FONT_MAP none!
dracut: *** Including module: drm ***
dracut: *** Including module: plymouth ***
dracut: *** Including module: crypt ***
dracut: Possible missing firmware "cnn55xx_se.fw" for kernel module "n5pf.ko"
dracut: *** Including module: dm ***
dracut: Skipping udev rule: 64-device-mapper.rules
dracut: Skipping udev rule: 60-persistent-storage-dm.rules
dracut: Skipping udev rule: 55-dm.rules
dracut: *** Including module: kernel-modules ***
dracut: Possible missing firmware "aic94xx-seq.fw" for kernel module "aic94xx.ko"
dracut: Possible missing firmware "wd719x-risc.bin" for kernel module "wd719x.ko"
dracut: Possible missing firmware "wd719x-wcs.bin" for kernel module "wd719x.ko"
dracut: Possible missing firmware "sd8688.bin" for kernel module "libertas_sdio.ko"
dracut: Possible missing firmware "sd8688_helper.bin" for kernel module "libertas_sdio.ko"
dracut: Possible missing firmware "sd8686.bin" for kernel module "libertas_sdio.ko"
dracut: Possible missing firmware "sd8686_helper.bin" for kernel module "libertas_sdio.ko"
dracut: Possible missing firmware "sd8385.bin" for kernel module "libertas_sdio.ko"
dracut: Possible missing firmware "sd8385_helper.bin" for kernel module "libertas_sdio.ko"
dracut: *** Including module: lvm ***
dracut: Skipping udev rule: 64-device-mapper.rules
dracut: Skipping udev rule: 56-lvm.rules
dracut: Skipping udev rule: 60-persistent-storage-lvm.rules
dracut: *** Including module: mdraid ***
dracut: Skipping udev rule: 64-md-raid.rules
dracut: *** Including module: rootfs-block ***
dracut: *** Including module: terminfo ***
dracut: *** Including module: udev-rules ***
dracut: Skipping udev rule: 40-redhat.rules
dracut: Skipping udev rule: 50-firmware.rules
dracut: Skipping udev rule: 50-udev.rules
dracut: Skipping udev rule: 91-permissions.rules
dracut: Skipping udev rule: 80-drivers-modprobe.rules
dracut: *** Including module: dracut-systemd ***
dracut: *** Including module: haveged ***
dracut: *** Including module: ostree ***
dracut: *** Including module: usrmount ***
dracut: *** Including module: base ***
dracut: *** Including module: fs-lib ***
dracut: *** Including module: shutdown ***
dracut: *** Including module: suse ***
dracut: *** Including modules done ***
dracut: *** Installing kernel module dependencies and firmware ***
dracut: *** Installing kernel module dependencies and firmware done ***
dracut: *** Resolving executable dependencies ***
dracut: *** Resolving executable dependencies done***
dracut: *** Hardlinking files ***
dracut: *** Hardlinking files done ***
dracut: *** Stripping files ***
dracut: *** Stripping files done ***
dracut: *** Generating early-microcode cpio image ***
dracut: *** Constructing AuthenticAMD.bin ****
dracut: *** Store current command line parameters ***
dracut: Stored kernel commandline:
dracut:  rd.luks.uuid=luks-8de5e14e-2705-46fb-8285-bdb02e4fef88
dracut:  rd.lvm.lv=DiePlatte/root 
dracut:  rd.md.uuid=2786a51b:7a91b691:ffd96056:31585bfd  rd.md.uuid=4f2088c5:fcba7831:09569aa1:a41f9d18 
dracut:  root=/dev/mapper/DiePlatte-root rootfstype=ext4 rootflags=rw,relatime,data=ordered
dracut: *** Creating image file '/boot/initrd-4.12.14-lp150.11-default' ***
dracut: *** Creating initramfs image file '/boot/initrd-4.12.14-lp150.11-default' done ***
Microknoppix:/ #
 

josef-wien

Ultimate Guru
Schweineschwarte schrieb:
--logfile /var/log/YaST2/mkinitrd.log
Meine Erinnerung an openSUSE meint, daß diese Datei immer ergänzt wird. Möglicherweise findest Du einen Unterschied zu der früheren Eintragung anläßlich der funktionsfähigen initrd-Erstellung mit dem alten dracut-Paket.
 
@josef-wien:
Deinen Vorschlag probiere ich die kommenden Tage aus. Jetzt muss ich gleich ins Bett ^^

@spoensche:
Ich habe jetzt noch mal die Lösung von deinem Verweis ausprobiert
Die bisherige Eintragung in /etc/crypttab auf dem Hauptrechner lautet:
Code:
cr-auto-1  /dev/md/DasRAID1-Linux

Die blkid auf dem Hautprechner lautet:
Code:
Microknoppix:/ # blkid
/dev/cloop0: UUID="2017-09-18-02-30-40-81" LABEL="KNOPPIX_FS" TYPE="iso9660"
/dev/cloop1: UUID="2017-09-13-18-09-11-00" LABEL="KNOPPIX_ADDONS1" TYPE="iso9660"
/dev/zram0: UUID="9391f0f9-8d75-4ff3-a7e3-7a3d88eac08b" TYPE="swap"
/dev/sda1: UUID="2786a51b-7a91-b691-ffd9-605631585bfd" UUID_SUB="c2177da6-bb50-96cf-e3f4-43fe18fd74de" LABEL="any:DasRAID1-boot" TYPE="linux_raid_member" PARTUUID="00018a8a-01"
/dev/sda2: UUID="4f2088c5-fcba-7831-0956-9aa1a41f9d18" UUID_SUB="4100b3ef-50a1-788d-9789-b662c13ad53b" LABEL="any:DasRAID1-Linux" TYPE="linux_raid_member" PARTUUID="00018a8a-02"
/dev/sda3: UUID="f31a3b5f-2080-f902-5abd-783237ac5c6d" UUID_SUB="f71676a1-d1b0-e2a6-92b1-c6a0b95fd15b" LABEL="any:DasRAID1-Krypt" TYPE="linux_raid_member" PARTUUID="00018a8a-03"
/dev/sdb1: UUID="2786a51b-7a91-b691-ffd9-605631585bfd" UUID_SUB="2c4bd098-e0c6-78c6-c812-7d39ddafb023" LABEL="any:DasRAID1-boot" TYPE="linux_raid_member" PARTUUID="00018a8a-01"
/dev/sdb2: UUID="4f2088c5-fcba-7831-0956-9aa1a41f9d18" UUID_SUB="4a3ba0a9-7b36-15df-cee6-60a94b22f61d" LABEL="any:DasRAID1-Linux" TYPE="linux_raid_member" PARTUUID="00018a8a-02"
/dev/sdb3: UUID="f31a3b5f-2080-f902-5abd-783237ac5c6d" UUID_SUB="ba2c34ab-2771-b3cd-9777-5a854ebe59eb" LABEL="any:DasRAID1-Krypt" TYPE="linux_raid_member" PARTUUID="00018a8a-03"
/dev/sr0: UUID="2017-09-18-01-34-11-00" LABEL="KNOPPIX_8" TYPE="iso9660" PTUUID="4f11e983" PTTYPE="dos"
/dev/md127: UUID="063caaf0-9bf0-4afd-b0de-b16eec5cd381" TYPE="ext4"
/dev/md126: UUID="8de5e14e-2705-46fb-8285-bdb02e4fef88" TYPE="crypto_LUKS"
/dev/mapper/cr-auto-1: UUID="ha1aLk-w5uW-rlyT-gc1n-auNV-aT8P-t0oc2a" TYPE="LVM2_member"
/dev/mapper/DiePlatte-home: UUID="c31fa81f-283c-4aa0-a9fa-26695f8ac245" TYPE="ext4"
/dev/mapper/DiePlatte-root: UUID="5db486ff-0557-44ed-976c-b6672df7e0b4" TYPE="ext4"
/dev/mapper/DiePlatte-swap: UUID="cc58d620-3e6f-4a89-a85c-f87d99452ec9" TYPE="swap"
/dev/mapper/DiePlatte-tmp: UUID="3be12925-7ce4-4d38-b23e-e1f6b84557b4" TYPE="ext4"

Entsprechend habe ich die crypttab geändert in:
Code:
cr-auto-1 UUID="4f2088c5-fcba-7831-0956-9aa1a41f9d18"
(Hier möchte ich noch anmerken, dass ich mir nicht ganz sicher über die UUID war, da ich überlegt hatte ob nicht auch das crypto_LUKS oder LVM2_member infrage kämen. Ich hatte die beiden aber auch ausprobiert und es passierte das Gleiche wie bei der UUID von DasRAID1-Linux.)
Anschließend habe ich mkinitrd ausgeführt, mich abgemeldet, alle Verzeichnisse ausgeworfen und neu gestartet. Danach konnte ich jedoch kein Kennwort mehr eingeben. Scheinbar findet er dann die Partition nicht. :???: Siehe hier:


Wenn er die Partition über das Label findet, aber das Kennwort nicht annehmen will, dann sieht es wie hier aus (beim Druck auf Esc sichtbar):


Bei dieser Gelegenheit habe ich auch gleich noch einmal ein paar Fotos gemacht, wie es aussieht, wenn die Eingaben fehlschlagen.
Nach 3x Eingabe:


Und mir ist aufgefallen: Wenn eine gewisse Zeit verstreichen lässt kommen folgende Meldungen:
 

spoensche

Moderator
Teammitglied
Das klingt eher nach https://github.com/systemd/systemd/issues/6381.

Welche systemd Version ist den installiert
Das kannst du in der chroot Umgebung mit
Code:
rpm -qa | grep systemd

oder

mit
Code:
zypper info systemd

herausfinden.

Weisst du evtl. noch welche systemd Version vorher installiert war?
 
Oben