OS 42.2 LVM Encrypted startet nicht mehr

funedv＠gmx.de

20 Jul 2017 20 Jul '17

12:30

Hallo Liste, mein System ist OpenSuse 42.2 mit LVM + encrypted, so wie Yast vorgeschlagen hat, alle Partitionen mit ext4 und auf einer SSD. Das System habe ich Anfang des Jahres eingerichtet, und es funktionierte bis vor einer Woche mit allen Updates ohne Probleme, bis es nicht mehr startete. Der Fehler sah so aus: Nach der Standard-Grub-Auswahl erschien nicht wie üblich sofort die Passwortabfrage, sondern das System landete nach mehreren Minuten auf der Konsole, und man konnte eine Datei rdsosreport.txt einsehen. Aus dieser bin ich nicht recht schlau geworden; was ich entnehmen konnte, ist, daß es einen Timeout gab, weil die Entschlüsselung des LVMs nicht stattgefunden hat. Mit dem Rettungssystem konnte ich jedoch einwandfrei auf das verschlüsselte LVM zugreifen und meine Dateien in den darin enthalteten Partitionen einsehen. rdsosreport.txt zeigt einen der letzten Bootversuche mit SuperGrub, welcher auch nicht gelang. Hier der Report: https://pastebin.com/MGGTE0xg Ausgabe smartctl: smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.4.74-18.20-default] (SUSE RPM) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org === START OF SMART DATA SECTION === SMART/Health Information (NVMe Log 0x02, NSID 0x1) Critical Warning: 0x00 Temperature: 43 Celsius Available Spare: 100% Available Spare Threshold: 10% Percentage Used: 0% Data Units Read: 12,458,085 [6.37 TB] Data Units Written: 2,682,547 [1.37 TB] Host Read Commands: 29,148,565 Host Write Commands: 12,588,279 Controller Busy Time: 136 Power Cycles: 249 Power On Hours: 319 Unsafe Shutdowns: 19 Media and Data Integrity Errors: 0 Error Information Log Entries: 0 Warning Comp. Temperature Time: 0 Critical Comp. Temperature Time: 0 Temperature Sensor 1: 43 Celsius Temperature Sensor 2: 61 Celsius Mit einem aktuellen Backup "im Rücken" habe ich das System auf dem gleichen Datenträger neu aufgesetzt, wie vorher mit LVM + encrypted mit ext4. Installation ok, Neustart ok, nach den anstehenden Updates ein weiterer Neustart - gleiches Problem: Nach Grub-Auswahl keine Passwort-Abfrage, sondern nach einigen Minuten die Konsole. Bis dahin habe ich nur mit Yast eine Standard-Installation mit KDE durchgeführt, kein Restore oder weitere Programme installiert. Zu guter Letzt habe ich das System erneut installiert, jedoch ohne LVM und unverschlüsselt. Seitdem keine Probleme. Ich würde definitiv ein verschlüsseltes System bevorzugen, will es aber ohne griffige Hinweise nicht erneut probieren. Weiß jemand eine Möglichkeit, ein solches auf der Konsole gestrandete System dennoch flott zu kriegen? Gibt es noch andere Ideen herauszukriegen, wieso, warum, weshalb - oder gibt es gar eine Abhilfe? Viele Grüße, Klaus

Attachments:

signature.asc (application/pgp-signature — 819 bytes)

Show replies by date

Manfred Kreisl

20 Jul 20 Jul

13:21

Am 20.07.2017 um 14:30 schrieb funedv@gmx.de:

...

Hallo Liste,

mein System ist OpenSuse 42.2 mit LVM + encrypted, so wie Yast vorgeschlagen hat, alle Partitionen mit ext4 und auf einer SSD. Das System habe ich Anfang des Jahres eingerichtet, und es funktionierte bis vor einer Woche mit allen Updates ohne Probleme, bis es nicht mehr startete.

Der Fehler sah so aus: Nach der Standard-Grub-Auswahl erschien nicht wie üblich sofort die Passwortabfrage, sondern das System landete nach mehreren Minuten auf der Konsole, und man konnte eine Datei rdsosreport.txt einsehen. Aus dieser bin ich nicht recht schlau geworden; was ich entnehmen konnte, ist, daß es einen Timeout gab, weil die Entschlüsselung des LVMs nicht stattgefunden hat. Mit dem Rettungssystem konnte ich jedoch einwandfrei auf das verschlüsselte LVM zugreifen und meine Dateien in den darin enthalteten Partitionen einsehen.

rdsosreport.txt zeigt einen der letzten Bootversuche mit SuperGrub, welcher auch nicht gelang. Hier der Report: https://pastebin.com/MGGTE0xg

Ausgabe smartctl: smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.4.74-18.20-default] (SUSE RPM) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF SMART DATA SECTION === SMART/Health Information (NVMe Log 0x02, NSID 0x1) Critical Warning: 0x00 Temperature: 43 Celsius Available Spare: 100% Available Spare Threshold: 10% Percentage Used: 0% Data Units Read: 12,458,085 [6.37 TB] Data Units Written: 2,682,547 [1.37 TB] Host Read Commands: 29,148,565 Host Write Commands: 12,588,279 Controller Busy Time: 136 Power Cycles: 249 Power On Hours: 319 Unsafe Shutdowns: 19 Media and Data Integrity Errors: 0 Error Information Log Entries: 0 Warning Comp. Temperature Time: 0 Critical Comp. Temperature Time: 0 Temperature Sensor 1: 43 Celsius Temperature Sensor 2: 61 Celsius

Mit einem aktuellen Backup "im Rücken" habe ich das System auf dem gleichen Datenträger neu aufgesetzt, wie vorher mit LVM + encrypted mit ext4. Installation ok, Neustart ok, nach den anstehenden Updates ein weiterer Neustart - gleiches Problem: Nach Grub-Auswahl keine Passwort-Abfrage, sondern nach einigen Minuten die Konsole. Bis dahin habe ich nur mit Yast eine Standard-Installation mit KDE durchgeführt, kein Restore oder weitere Programme installiert.

Zu guter Letzt habe ich das System erneut installiert, jedoch ohne LVM und unverschlüsselt. Seitdem keine Probleme. Ich würde definitiv ein verschlüsseltes System bevorzugen, will es aber ohne griffige Hinweise nicht erneut probieren.

Weiß jemand eine Möglichkeit, ein solches auf der Konsole gestrandete System dennoch flott zu kriegen? Da muss ich mangels diesbezüglicher Erfahrung passen. Ich persönlich würde ein solches System niemals verwenden, sind mir viel zu viele Unwägbarkeiten, wie Du gerade selbst am eigenen Leibe erfahren musstest

Gibt es noch andere Ideen herauszukriegen, wieso, warum, weshalb - oder gibt es gar eine Abhilfe? Es ist ja offensichtlich, dass irgendein Update dafür verantwortlich ist. Da gilt es zuallererst herauszufinden, welche Updates denn installiert wurden. Und dann versuchen herauszufinden, welches denn dafür verantwortlich sein könnte (kernel, lvm, luks dürfte wohl interessant sein, ebenfalls überprüfen ob eine initrd ordnungsgemäß erstellt worden ist).

Und natürlich könnte ein Bugreport recht nützlich sein Gruß Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

funedv＠gmx.de

14:14

Am 20.07.2017 um 15:21 schrieb Manfred Kreisl:

...

Am 20.07.2017 um 14:30 schrieb funedv@gmx.de:

...
Hallo Liste,

mein System ist OpenSuse 42.2 mit LVM + encrypted, so wie Yast vorgeschlagen hat, alle Partitionen mit ext4 und auf einer SSD. Das System habe ich Anfang des Jahres eingerichtet, und es funktionierte bis vor einer Woche mit allen Updates ohne Probleme, bis es nicht mehr startete.

Der Fehler sah so aus: Nach der Standard-Grub-Auswahl erschien nicht wie üblich sofort die Passwortabfrage, sondern das System landete nach mehreren Minuten auf der Konsole, und man konnte eine Datei [...]

...

...
rdsosreport.txt zeigt einen der letzten Bootversuche mit SuperGrub, welcher auch nicht gelang. Hier der Report: https://pastebin.com/MGGTE0xg

Ausgabe smartctl: smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.4.74-18.20-default] (SUSE RPM) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org [...]

...

...
Mit einem aktuellen Backup "im Rücken" habe ich das System auf dem gleichen Datenträger neu aufgesetzt, wie vorher mit LVM + encrypted mit ext4. Installation ok, Neustart ok, nach den anstehenden Updates ein weiterer Neustart - gleiches Problem: Nach Grub-Auswahl keine Passwort-Abfrage, sondern nach einigen Minuten die Konsole. Bis dahin habe ich nur mit Yast eine Standard-Installation mit KDE durchgeführt, kein Restore oder weitere Programme installiert.

Zu guter Letzt habe ich das System erneut installiert, jedoch ohne LVM und unverschlüsselt. Seitdem keine Probleme. Ich würde definitiv ein verschlüsseltes System bevorzugen, will es aber ohne griffige Hinweise nicht erneut probieren.

Weiß jemand eine Möglichkeit, ein solches auf der Konsole gestrandete System dennoch flott zu kriegen? Da muss ich mangels diesbezüglicher Erfahrung passen. Ich persönlich würde ein solches System niemals verwenden, sind mir viel zu viele Unwägbarkeiten, wie Du gerade selbst am eigenen Leibe erfahren musstest

Gibt es noch andere Ideen herauszukriegen, wieso, warum, weshalb - oder gibt es gar eine Abhilfe? Es ist ja offensichtlich, dass irgendein Update dafür verantwortlich ist. Da gilt es zuallererst herauszufinden, welche Updates denn installiert wurden. Und dann versuchen herauszufinden, welches denn dafür verantwortlich sein könnte (kernel, lvm, luks dürfte wohl interessant sein, ebenfalls überprüfen ob eine initrd ordnungsgemäß erstellt worden ist).

Und natürlich könnte ein Bugreport recht nützlich sein

Gruß Manfred

Hallo, das System startete am 14.7. abends nicht mehr. Es wurde fast an jedem Tag oft sogar mehrfach benutzt. In /var/log/zypp/history findet sich Folgendes (jeweils die letzten Einträge): #### # 2017-07-08 17:55:53 kernel-default-4.4.74-18.20.1.x86_64.rpm installed ok # Additional rpm output: # Creating initrd: /boot/initrd-4.4.74-18.20-default # dracut: Executing: /usr/bin/dracut --logfile /var/log/YaST2/mkinitrd.log --force /boot/initrd-4.4.74-18.20-default 4.4.74-18.20-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: *** 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: *** 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: resume *** # dracut: *** Including module: rootfs-block *** # dracut: *** Including module: suse-btrfs *** # 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: 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 GenuineIntel.bin **** # dracut: *** Store current command line parameters *** # dracut: Stored kernel commandline: # dracut: rd.luks.uuid=luks-3a9a3abe-2839-4996-8583-ecf994454941 # dracut: rd.lvm.lv=system/swap # rd.lvm.lv=system/root # dracut: resume=/dev/mapper/system-swap # dracut: root=/dev/mapper/system-root rootfstype=ext4 rootflags=rw,relatime,data=ordered # dracut: *** Creating image file '/boot/initrd-4.4.74-18.20-default' *** # dracut: *** Creating initramfs image file '/boot/initrd-4.4.74-18.20-default' done *** #### cryptsetup: #### 2017-06-06 17:16:41|install|cryptsetup|1.6.4-5.3.1|x86_64||repo-update|d88fbb29536e2b8405dab68ccc48a6522674c1127e5ed28be46d2844522067ed| #### luks: #### 2017-05-08 10:02:52|install|kernel-default|4.4.62-18.6.1|x86_64||repo-update|6880064cf7500f5c03f802d560c30c3ed62bb1f0e3206ac 2808c75d4b2e125bf| 2017-05-08 10:02:53|install|libLLVM|3.8.0-2.3.1|x86_64||repo-update|6d512f8d5746d7430986817e4c705a0b37b927ef5f5a42bd60623456ec854905| 2017-05-08 10:02:54|install|libLLVM-32bit|3.8.0-2.3.1|x86_64||repo-update|d911ff10029ec379ccfe4fd737ed6826d4826212075bcb64e571eb7889e67655| #### Sieht für mich ok aus, hat ja längere Zeit funktioniert. Ich schreibe auch gerne einen Bugreport, nur fehlt mir momentan noch eine zündende Idee, was ich Griffiges rein schreiben soll. Gibt denn rdsosreport.txt was her? Viele Grüße, Klaus

jpr.liste01＠jpberlin.de

14:32

Am Thu, 20 Jul 2017 14:30:40 +0200 schrieb funedv@gmx.de: Hallo Klaus! In leicht anderer Konstellation (kein LVM) hatte ich den gleichen Fehler wie Du. Bis jetzt habe ich folgendes herausgefunden: Der Fehler tritt auch ohne LVM und ausschließlich bei verschlüsselten Patitions auf (NVMe)-SSDs auf. Unverschlüsselte Partitions auf (NVMe)-SSDs und verschlüsselte Partitions auf HDDs sind nicht betroffen.

...

Weiß jemand eine Möglichkeit, ein solches auf der Konsole gestrandete System dennoch flott zu kriegen? Die Ursache muß in dem Security-Update von systemd und/ oder udev (228-25.6.1) vom 4.7. liegen. Nach einem Downgrade folgender Pakete auf 228-13.1 ist vorläufig alles wieder i.o.: systemd, systemd-sysvinit, udev, libudev1, libudev1-32bit

Es scheint so, als ob etwas bei der Identifizierung der Partition über die UUID schief geht, so daß diese weder entschlüsselt noch eingehangen werden können. Wenn es funktioniert (228-13.1) hinterläßt das Entschlüsseln und Einhängen der Partition folgenden LOG-Eintrag: Jul 17 19:47:25 bootes systemd-cryptsetup[2203]: Set cipher aes, mode xts-plain64, key size 256 bits for device /dev/disk/by-id/nvme-20000000001000000e4d25c74479c4d01-part6. Mit dem fehlerhaften Update (228-25.6.1) sieht der LOG-Eintrag für dieselbe Partition so aus: Jul 17 19:37:37 bootes systemd[1]: dev-disk-by\x2did-nvme\x2d20000000001000000e4d25c74479c4d01\x2dpart6.device: Job dev-disk-by\x2did-nvme\x2d20000000001000000e4d25c74479c4d01\x2dpart6.dev Jul 17 19:37:37 bootes systemd[1]: Timed out waiting for device dev-disk-by\x2did-nvme\x2d20000000001000000e4d25c74479c4d01\x2dpart6.device. Jul 17 19:37:37 bootes systemd[1]: Dependency failed for Cryptography Setup for cr_opt. Jul 17 19:37:37 bootes systemd[1]: Dependency failed for Encrypted Volumes. Jul 17 19:37:37 bootes systemd[1]: cryptsetup.target: Job cryptsetup.target/start failed with result 'dependency'. Jul 17 19:37:37 bootes systemd[1]: Dependency failed for dev-mapper-cr_opt.device. usw.

...

Gibt es noch andere Ideen herauszukriegen, wieso, warum, weshalb - oder gibt es gar eine Abhilfe? Vielleicht schaffe ich es übers Wochenende oder nächste Woche mal, verschiedene Dateien der beiden RPMs miteinander zu vergleichen. Deiner Frage nach einer echten Abhilfe kann ich mich aber nur anschließen, denn auf Dauer ist es sicher keine gute Idee, Sicherheits-Updates nicht einzuspielen.

Viele Grüße Matthias -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Christian

20:04

HI Matthias, Am 20.07.2017 um 16:32 schrieb jpr.liste01@jpberlin.de:

...

Der Fehler tritt auch ohne LVM und ausschließlich bei verschlüsselten Patitions auf (NVMe)-SSDs auf. Unverschlüsselte Partitions auf (NVMe)-SSDs und verschlüsselte Partitions auf HDDs sind nicht betroffen.

Die Ursache muß in dem Security-Update von systemd und/ oder udev (228-25.6.1) vom 4.7. liegen. Nach einem Downgrade folgender Pakete auf 228-13.1 ist vorläufig alles wieder i.o.: systemd, systemd-sysvinit, udev, libudev1, libudev1-32bit

Es scheint so, als ob etwas bei der Identifizierung der Partition über die UUID schief geht, so daß diese weder entschlüsselt noch eingehangen werden können.

hast Du diese Erkenntnisse auch mal als BUG hier: https://bugzilla.opensuse.org/index.cgi 'eingetütet' ? Falls nicht mach es bitte, damit das gefixt werden kann. Danke :) -- Christian ------------------------------------------------------------ https://join.worldcommunitygrid.org?recruiterId=177038 ------------------------------------------------------------ http://www.sc24.de - Sportbekleidung ------------------------------------------------------------ -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Matthias

21 Jul 21 Jul

21:43

Am Thu, 20 Jul 2017 22:04:24 +0200 schrieb Christian : Hallo Christian!

...

hast Du diese Erkenntnisse auch mal als BUG hier: https://bugzilla.opensuse.org/index.cgi

'eingetütet' ? Falls nicht mach es bitte, damit das gefixt werden kann. Danke :)

Das hatte ich noch nicht getan und habe mir auf Grund Deiner Mail die Seite mal angesehen. Zum Anmelden wollen die gleich den halben Lebenslauf haben. Soviel will ich in die Tüte nun doch nicht mit reinstecken ;-), zumal die die Daten auch an Novell u.a. weitergeben. Gibt es noch andere Wege für einen Bug-Report am besten ohne Anmeldung oder mit weniger oder optionalen Angaben? Viele Grüße Matthias -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Christian Boltz

22:09

Hallo Matthias, hallo zusammen, Am Freitag, 21. Juli 2017, 23:43:37 CEST schrieb Matthias:

...

Am Thu, 20 Jul 2017 22:04:24 +0200 schrieb Christian :

...
hast Du diese Erkenntnisse auch mal als BUG hier: https://bugzilla.opensuse.org/index.cgi

'eingetütet' ? Falls nicht mach es bitte, damit das gefixt werden kann. Danke :)

Das hatte ich noch nicht getan und habe mir auf Grund Deiner Mail die Seite mal angesehen. Zum Anmelden wollen die gleich den halben Lebenslauf haben. Soviel will ich in die Tüte nun doch nicht mit reinstecken ;-), zumal die die Daten auch an Novell u.a. weitergeben.

Ich will nicht wissen, wie viele Leute in einem Ort namens "." oder "-" leben ;-)

...

Gibt es noch andere Wege für einen Bug-Report am besten ohne Anmeldung oder mit weniger oder optionalen Angaben?

Ohne Anmeldung geht nicht (wäre auch unpraktisch, wenn z. B. Rückfragen auftauchen). Es gibt aber ein deutlich kürzeres Anmeldeformular, zu erreichen über den "Sign up"-Link im Wiki oder direkt hier: https://secure-www.novell.com/selfreg/jsp/createOpenSuseAccount.jsp?login=Si... Gruß Christian Boltz -- programmers' biggest strength is that they're lazy bastards. [Claudio Freire in opensuse-factory] -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Matthias

24 Jul 24 Jul

18:05

Am Sat, 22 Jul 2017 00:09:09 +0200 schrieb Christian Boltz : Hallo Christian!

...

Ohne Anmeldung geht nicht (wäre auch unpraktisch, wenn z. B. Rückfragen auftauchen). Es gibt aber ein deutlich kürzeres Anmeldeformular, zu erreichen über den "Sign up"-Link im Wiki oder direkt hier: https://secure-www.novell.com/selfreg/jsp/createOpenSuseAccount.jsp?login=Si... Danke für den Tipp. Das sieht schon besser aus, auch wenn die Bauchschmerzen mit Novell (Ami-Firma) bleiben; na ja ...

So habe ich nun meinen ersten Bug-Report unter der Nr.1050299 eingereicht und hoffentlich alles richtig gemacht. Vielleicht bewirkt es auch was. Viele Grüße Matthias -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

funedv＠gmx.de

25 Jul 25 Jul

07:10

Am 24.07.2017 um 20:05 schrieb Matthias:

...

Am Sat, 22 Jul 2017 00:09:09 +0200 schrieb Christian Boltz :

Hallo Christian!

...
Ohne Anmeldung geht nicht (wäre auch unpraktisch, wenn z. B. Rückfragen auftauchen). Es gibt aber ein deutlich kürzeres Anmeldeformular, zu erreichen über den "Sign up"-Link im Wiki oder direkt hier: https://secure-www.novell.com/selfreg/jsp/createOpenSuseAccount.jsp?login=Si... Danke für den Tipp. Das sieht schon besser aus, auch wenn die Bauchschmerzen mit Novell (Ami-Firma) bleiben; na ja ...

So habe ich nun meinen ersten Bug-Report unter der Nr.1050299 eingereicht und hoffentlich alles richtig gemacht. Vielleicht bewirkt es auch was.

Viele Grüße

Matthias

Hallo Matthias, vielen Dank für Deine Mühe. Ich werde den Bug verfolgen und hoffe auf ein Update, das den Fehler behebt. Immerhin weiß ich nun, warum es mich erwischt hat. Vielen Dank an alle Beteiligten und viele Grüße, Klaus

Michael Eschweiler

26 Jul 26 Jul

06:06

Hallo Listenleser, habe in den letzten Tagen die Liste nicht verfolgen können, daher kommt meine Rückmeldung erst jetzt:

...

Der Fehler sah so aus: Nach der Standard-Grub-Auswahl erschien nicht wie üblich sofort die Passwortabfrage, sondern das System landete nach mehreren Minuten auf der Konsole,

Ein ähnliches Phänomen hatte eine Bekannte von mir vor ein paar Tagen. D.h. nach einem Neustart konnte die verschlüsselte /home-Partition nicht mehr gemountet werden. Wie sich nach einigem Suchen herausstellte, konnte das System die Partition nicht mehr finden, da sie in /dev/disk/by-id nicht mehr unter der in der crypttab aufgeführten Id eingetragen war. Stattdessen fand sie sich dort unter mehreren anderen Bezeichnungen. Nachdem sie eine der neuen Bezeichnungen in die crypttab eingetragen hat, läuft das System wieder. Ehrlich gestanden finde ich ein solches Verhalten des Systems doch ziemlich irritierend. Bei der Installation einer neuen Version des System ist man ja auf allerlei Probleme gefasst - ich hatte bei der Umstellung von 13.2 auf 42.2 genau solch ein Problem mit einer externen SSD (vgl. Thread 'Erfahrungen mit Leap 42.2) -, aber das einen so etwas im laufenden Betrieb treffen kann... Ich war bis 13.2 davon ausgegangen eine Id ist eine Id ist eine Id, d.h. sie wird irgendwo in/an der Hardware ausgelesen und bleibt stabil. Aber da war ich auf dem Holzweg. Gruß, Michael Am 25.07.2017 um 01:10 schrieb funedv@gmx.de:

...

Am 24.07.2017 um 20:05 schrieb Matthias:

...
Am Sat, 22 Jul 2017 00:09:09 +0200 schrieb Christian Boltz :

Hallo Christian!

...
Ohne Anmeldung geht nicht (wäre auch unpraktisch, wenn z. B. Rückfragen auftauchen). Es gibt aber ein deutlich kürzeres Anmeldeformular, zu erreichen über den "Sign up"-Link im Wiki oder direkt hier: https://secure-www.novell.com/selfreg/jsp/createOpenSuseAccount.jsp?login=Si... Danke für den Tipp. Das sieht schon besser aus, auch wenn die Bauchschmerzen mit Novell (Ami-Firma) bleiben; na ja ...

So habe ich nun meinen ersten Bug-Report unter der Nr.1050299 eingereicht und hoffentlich alles richtig gemacht. Vielleicht bewirkt es auch was.

Viele Grüße

Matthias

Hallo Matthias,

vielen Dank für Deine Mühe. Ich werde den Bug verfolgen und hoffe auf ein Update, das den Fehler behebt. Immerhin weiß ich nun, warum es mich erwischt hat.

Vielen Dank an alle Beteiligten und viele Grüße, Klaus

-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

funedv＠gmx.de

10:34

Am 24.07.2017 um 20:05 schrieb Matthias:

...

Am Sat, 22 Jul 2017 00:09:09 +0200 schrieb Christian Boltz :

Hallo Christian!

...
Ohne Anmeldung geht nicht (wäre auch unpraktisch, wenn z. B. Rückfragen auftauchen). Es gibt aber ein deutlich kürzeres Anmeldeformular, zu erreichen über den "Sign up"-Link im Wiki oder direkt hier: https://secure-www.novell.com/selfreg/jsp/createOpenSuseAccount.jsp?login=Si... Danke für den Tipp. Das sieht schon besser aus, auch wenn die Bauchschmerzen mit Novell (Ami-Firma) bleiben; na ja ...

So habe ich nun meinen ersten Bug-Report unter der Nr.1050299 *** This bug has been marked as a duplicate of bug 1048679 ***

Hallo, s.o. die Bugnummer, unter der man weiter nachlesen kann, was gerade geschieht. Viele Grüße, Klaus

2473

Age (days ago)

2479

Last active (days ago)

List overview

Download

10 comments

7 participants

participants (7)

Christian
Christian Boltz
funedv＠gmx.de
jpr.liste01＠jpberlin.de
Manfred Kreisl
Matthias
Michael Eschweiler

OS 42.2 LVM Encrypted startet nicht mehr

tags

participants (7)