expertenaustausch > linux.debian.user.german

H.-Stefan Neumeyer (09.01.2019, 19:50)
Hallo an alle Mitleser,

allen noch ein gesundes und erfolgreiches Jahr 2019.

Das Problem lag im alten Jahr schon mal bei mir. Ich hatte es
abgegeben, weil ich es nicht lösen konnte. Andere aber offenbar auch
nicht, denn nun habe ich es wieder hier:

Mehrere USB-Datenträger (Sticks, Festplatten), sowie eine IEEE.1394-
Platte wurden einst mit SuSE 11- oder 12.irgendwas mit Bordmitteln,
also vermutlich Yast, verschlüsselt. Sie sind dann ein paar Jahre lang
problemlos unter SuSE benutzt worden, bis dieser Rechner im letzten
Oktober aus technischen Gründen EoL war.
Der Inhalt soll nun auf unverschlüsselte Datenträger umkopiert werden.
Eine SuSE gibt es dafür nicht mehr.

Versuche ich diese Sticks/Platten an einem meiner Rechner (Debian Sid
oder testing mit Xfce, old-stable mit KDE4) zu öffnen, dann ploppt
sofort ein Fenster auf, mit der Mitteilung, daß noch Daten geschrieben
werden.

<https://www.bilder-upload.eu/bild-9123a4-1547049596.png.html>

Das bleibt bis zum Sankt Nimmerleinstag stehen. Beenden, oder den
Datenträger wieder auswerfen, bringt das zweites Fenster (links unten),
daß der Datenträger belegt ist.
Ich benutze selbst mehrere verschlüsselte USB-Festplatten, ohne daß ich
damit irgendwelche Probleme hätte. Ich denke mal, daß mein Setup so
weit i.O. ist.

Nun suche ich eine Idee, wie ich an an den Inhalt dieser zickenden
Datenträger kommen kann. Bevorzugt, ohne daß ich mir einen Rechner mit
SuSE suchen, oder gar selbst aufsetzen muß.
Alexander Dahl (09.01.2019, 21:10)
Hallo Stefan,

On Wed, Jan 09, 2019 at 06:49:28PM +0100, H.-Stefan Neumeyer wrote:
> Nun suche ich eine Idee, wie ich an an den Inhalt dieser zickenden
> Datenträger kommen kann. Bevorzugt, ohne daß ich mir einen Rechner mit
> SuSE suchen, oder gar selbst aufsetzen muß.


Details zu den Partitionstabellen der Datenträger wären interessant.
Also einmal bitte:

fdisk -l /dev/sdx

Und dann noch besser:

blkid /dev/sdx*

sdx natürlich durch das entsprechend korrekte Device ersetzen. Mit dem
Output lässt sich dann vielleicht besser einschätzen womit oder wie
die Datenträger verschlüsselt sind.

Grüße
Alex
Martin Steigerwald (10.01.2019, 00:20)
Hi.

Alexander Dahl - 09.01.19, 20:08:
> On Wed, Jan 09, 2019 at 06:49:28PM +0100, H.-Stefan Neumeyer wrote:
> Details zu den Partitionstabellen der Datenträger wären interessant.
> Also einmal bitte:
> fdisk -l /dev/sdx
> Und dann noch besser:
> blkid /dev/sdx*
> sdx natürlich durch das entsprechend korrekte Device ersetzen. Mit dem
> Output lässt sich dann vielleicht besser einschätzen womit oder wie
> die Datenträger verschlüsselt sind.


Mich würde 'lsblk -o NAME,PARTTYPE,SIZE,FSTYPE' (extra so, damit keine
eindeutigen UUIDs in der Ausgabe drin sind) interessieren sowie 'file -
sk' auf die Partition mit den verschlüsselten Daten (Debian-Paket 'file',
falls nicht installiert).

Ciao,
H.-Stefan Neumeyer (11.01.2019, 10:50)
Am Mittwoch, den 09.01.2019, 23:18 +0100 schrieb Martin Steigerwald:

Moin Martin,
Moin Alexander

root@apd-unstable03:/home/stefan# lsblk -o NAME,PARTTYPE,SIZE,FSTYPE
NAME PARTTYPE SIZE FSTYPE
sda 931,5G
??sda1 0x83 243M xfs
??sda2 0x5 1K
??sda5 0x83 931,3G
crypto_LUKS
??sda5_crypt 931,3G
LVM2_member
??apd--unstable03--vg-root 28G xfs
??apd--unstable03--vg-swap_1 7,7G swap
??apd--unstable03--vg-home 895,7G xfs
sdb 596,2G
??sdb1 0x83 596,2G
crypto_LUKS
??luks-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 596,2G ext3

Die UIID der Partition habe auf /dev/sdb1 habe ich unkenntlich gemacht.

root@apd-unstable03:/home/stefan# file -sk /dev/sdb1
/dev/sdb1: LUKS encrypted file, ver 1 [aes, xts-plain64, sha256] UUID:
45b3b70a-ffd2-4ddf-93c2-5c4bb5845052\012- LUKS encrypted file, ver 1
[aes, xts-plain64, sha256] UUID: 45b3b70a-ffd2-4ddf-93c2-
5c4bb5845052\012- data
Uwe Kerstan (11.01.2019, 14:40)
* H.-Stefan Neumeyer [11-01-2019 09:48]:

> sdb 596,2G
> ??sdb1 0x83 596,2G
> crypto_LUKS
> ??luks-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 596,2G ext3 Direkt auf der Konsole öffnen geht nicht?


# cryptsetup -v open --type luks /dev/sdb1 huhu
# mount -v /dev/mapper/huhu /mnt
H.-Stefan Neumeyer (14.01.2019, 20:10)
Am Freitag, den 11.01.2019, 13:39 +0100 schrieb Uwe Kerstan:

Hallo Uwe
> Direkt auf der Konsole öffnen geht nicht?
> # cryptsetup -v open --type luks /dev/sdb1 huhu

Bis her her ja.
Bei zwei der drei Festplatten (alles Samsung Spinpoint von 2009/10)
kommt nach kurzer Zeit ein "Hard Disk Health Warning" mit Bezug auf
ziemlich viele "Currently unreadable (pending) sectors".
Zusammenhang? Möglich, denke ich.

> # mount -v /dev/mapper/huhu /mnt

Das funktioniert nich' mehr. Der Rechner, bzw. die Konsole, hängt sich
auf.

Ich werde die Platten und Sticks in den nächsten Tage so zurückgeben wie
sie sind. Da am Wochenende der Versuch SuSE 15 auf eine Reserve-SSD zu
installieren wieder nur eine nicht bootende Installation ergeben hat,
kann (mag) ich nicht mehr weitermachen.
Ulf Volmer (14.01.2019, 20:50)
On 14.01.19 19:07, H.-Stefan Neumeyer wrote:
> Am Freitag, den 11.01.2019, 13:39 +0100 schrieb Uwe Kerstan:


>> Direkt auf der Konsole öffnen geht nicht?
>> # cryptsetup -v open --type luks /dev/sdb1 huhu

> Bis her her ja.


Dann ist zumindest der LUKS- Header intakt.

> Bei zwei der drei Festplatten (alles Samsung Spinpoint von 2009/10)
> kommt nach kurzer Zeit ein "Hard Disk Health Warning" mit Bezug auf
> ziemlich viele "Currently unreadable (pending) sectors".
> Zusammenhang? Möglich, denke ich.


Das klingt nicht gut. Details würde man mit 'smartctl -a /dev/sdb'
bekommen. Aber wenn das wie beschrieben nicht Dein Gerät ist, würde ich
das im Zweifel dem Besitzer überlassen.

>> # mount -v /dev/mapper/huhu /mnt

> Das funktioniert nich' mehr. Der Rechner, bzw. die Konsole, hängt sich
> auf.


Ein 'file -sL /dev/mapper/huhu' würde ggf. verraten, ob dahinter ein
valides Filesystem ist. Aber siehe oben. Wenn man da ernsthaft
Rettungsversuche machen wollte, würde ich vorher mit dd_rescue ein Image
von ziehen wollen.

Viele Grüße
Ulf
H.-Stefan Neumeyer (14.01.2019, 21:30)
Am Montag, den 14.01.2019, 19:53 +0100 schrieb Christoph Schmees:

Hallo Christoph
> mit meiner ersten "Linux auf SSD" Installation habe ich in kürzester
> Zeit die SSD geschrottet - zu viele Schreibvorgänge. Leider ist es
> immer noch so, dass Linux unzureichend berücksichtigt, wenn es auf
> eine SSD installiert wird. Da ist immer noch Nacharbeit per Hand
> notwendig, wenn man der SSD ein langes Leben ermöglichen will.
> <https://duckduckgo.com/?q=linux+ssd&t=lm&ia=web>
> Lass' dich nicht vom Begriff "Optimierung" irre leiten: Es geht um
> ganz basale, teils lebensnotwendige Einstellungen.

Meine erste SSD, eine Kingston 120GB, damals glaube ich noch an die 600
Mark-Euro teuer, hat als Systemplatte in einem ThinkPad T400, später
einem T430s, bei täglicher Nutzung von Ende 2009 bis in Oktober 2018
durchgehalten. Würde es wohl auch noch weiter tun, wenn ich nicht auf
eine völlig neue Generation Rechner (mit NMVe-SSD) umgestellt hätte.

Media Wearout Indicator: Der normalisierte Wert war am Anfang 100, als
der Rechner außer Betrieb ging stand der Wert bei 96. Die SSD hielt sich
also noch für nahezu neuwertig.
Und bei dieser Sorte Platten mußte man noch einiges, wie Spare Area oder
Trimm, vorplanen und selbst erledigen.
H.-Stefan Neumeyer (14.01.2019, 21:40)
Am Montag, den 14.01.2019, 19:46 +0100 schrieb Ulf Volmer:

Hallo Ulf
> Das klingt nicht gut. Details würde man mit 'smartctl -a /dev/sdb'
> bekommen. Aber wenn das wie beschrieben nicht Dein Gerät ist, würde
> ich
> das im Zweifel dem Besitzer überlassen. Ja, ist nicht mehr mein Kanne Bier.


Der SuSE-Rechner dort ist im Oktober übrigens schon wegen nicht
erkannter Festplattenproblemen außer Betrieb gegangen. Sowas wie den
smart-notifier und Warnungen per Mail vom smartd gibt es bei einer SuSE-
Installation nicht so ohne weiteres.
Ulf Volmer (14.01.2019, 22:10)
On 14.01.19 20:36, H.-Stefan Neumeyer wrote:

> Der SuSE-Rechner dort ist im Oktober übrigens schon wegen nicht
> erkannter Festplattenproblemen außer Betrieb gegangen. Sowas wie den
> smart-notifier und Warnungen per Mail vom smartd gibt es bei einer SuSE-
> Installation nicht so ohne weiteres.


Es will bei Suse halt installiert und konfiguriert werden.
Aber das fällt bei Debian ja auch nicht einfach so vom Himmel.

Es gibt genügend Installationen, wo die smartmontools schlicht nichts
nutzen, weil VMs oder HW- RAID, das sich selber drum kümmert.

Viele Grüße
Ulf
Ähnliche Themen