Lug-dd August 2024

lug-dd@mailman.schlittermann.de

11 participants
8 discussions

Heute Treffen im Nerdpol?!
by Andreas Roth 29 Aug '24

29 Aug '24

Hallo zusammen, Heute treffen wir uns wieder im Nerdpol, richtig?! Falls es das Wetter zulässt, können wir ja auf der Terrasse starten. Besten Gruss, Andreas

2 1

Treff morgen, aber wo?
by Konrad Rosenbaum 27 Aug '24

27 Aug '24

Hi, morgen ist wieder LUG Treff. Wo geht's hin? Gag18, Nerdpol, Torwirtschaft, noch was ganz anderes? Konrad

1 0

Morgen im Nerdpol
by Christian Perle 14 Aug '24

14 Aug '24

Hallo Liste, morgen treffen wir uns im Nerdpol, Bautzner Str. 53. Vielleicht gibt es ja eine Temperaturverwandschaft mit dem Nordpol :) Gruesse, Christian -- Christian Perle chris AT linuxinfotag.de 010111 http://chris.silmor.de/ 101010 LinuxGuitarKitesBicyclesBeerPizzaRaytracing

3 2

Frage zur Doku von IT-Projekten
by N. Schwirz 11 Aug '24

11 Aug '24

Hallo, nach längerer Zeit auch von mir wieder mal eine Mail auf dieser Mailingliste. Sobald man ein paar mehr Rechner zu administrieren hat (oder Computer regelmäßig neu einrichten muss) ist ein SCM-Tool wie Ansible oder Nix(-OS) ziemlich praktisch. Wie dokumentiert ihr jedoch eure IT wenn der Quellcode (bzw. die Konfig) selbst nicht Dokumentation genug ist? Viele Grüße Norman

1 0

composer Probleme mit Versionen
by ronny＠seffner.de 05 Aug '24

05 Aug '24

Hallo Gruppe, ich komme absolut nicht mit den composer Versionierungen/Einschränkungen zurecht. Da ich das "Werkzeug" eigentlich nie nutze, hoffe ich hier auf schnelle Hilfe, statt mich da jetzt tief einzulesen. Installiert wurde einst mautic 4.4.? via composer - und auch immer fleissig bis 4.4.11 aktualisiert. Dazu gab es ein composer.json welches u.a. Folgendes enthielt (wenn mehr benötigt wird, gern fragen): "require": { "composer/installers": "^1.11", "mautic/core-composer-scaffold": "4.x-dev", "mautic/core-lib": "4.4.11", "mautic/core-project-message": "4.x-dev", "mautic/grapes-js-builder-bundle": "4.4.11", ... "minimum-stability": "dev", "prefer-stable": true, ... Der Update-Leitfaden meint, ein aktuelles composer.json zu laden und "composer update" auszuführen (was bisher auch immer gut funktioniert hat). Die neue composer.json enthält aber (das "x-dev" verschwindet zu Gunsten einer Versionsnummer): "require": { "composer/installers": "^1.11", "mautic/core-composer-scaffold": "4.4.12", "mautic/core-lib": "4.4.13", "mautic/core-project-message": "4.4.12", "mautic/grapes-js-builder-bundle": "4.4.12", ... "minimum-stability": "dev", "prefer-stable": true, ... Das "composer update" schlägt nun fehl mit: Problem 1 - Root composer.json requires mautic/core-composer-scaffold 4.4.12, found mautic/core-composer-scaffold[dev-RCheesley-patch-1, 3.x-dev, 4.x-dev] but it does not match the constraint. Problem 2 - Root composer.json requires mautic/core-project-message 4.4.12, found mautic/core-project-message[3.x-dev, 4.x-dev] but it does not match the constraint. Ich habe schon "composer require $PAKET:4.4.12" erfolglos probiert. Auch den composer cache habe ich gelöscht. Ferner habe ich die beiden Pakete aus vendor und die composer.lock mal testweise gelöscht. Wie kann man denn "erzwingen", dass da jetzt die 4.4.12 einzusetzen wäre statt der 4.x-dev? Richtig blöd wird es mit der Migration auf Version 5, da hält der composer immer noch an den 4.x-dev fest ;-( Mit freundlichen Grüßen / Kind regards Ronny Seffner

2 1

Korrupte Dateien in ext4 auf RAID5
by Max Pietzsch 05 Aug '24

05 Aug '24

Hallo in die Runde, ich wende mich an euch in der Hoffnung, dass vllt. jemand Zeit und Muße hat und mir einen Tipp geben kann, doch noch etwas von meinen Daten zu retten. Vorab: es ist vollkommen meine Schuld, RAID ist kein Backup, ich habe kein Backup, weil ich es einfach immer wieder aufgeschoben habe ... das war einfach komplett dumm. Kann man nicht anders beschreiben. Aber von vorn, in Stichpunkten, damit es nicht ewig lang wird: - ich betreibe ein RAID5 mit einem Debian-Rechner als Software-RAID, ext4 Dateisystem - Speicher war komplett voll (0 Byte frei), daher habe ich eine neue Platte eingebunden (dazu die Partitionierung von bestehender Platte sdg auf neue Platte sdd geklont, per sgdisk, am Ende auch neue UUID generiert per "sgdisk -G /dev/sdd") - nach dem Rebuild sah ich, das eine Platte als "removed" markiert war, der Zustand des RAIDs war "clean, degraded" - die SMART-Werte der Platte sahen allerdings ganz okay aus, also habe ich die Platte wieder hinzugefügt ("mdadm /dev/md0 --re-add /dev/sdg1") - danach sah alles erstmal soweit gut aus (hier habe ich aber auch nicht versucht auf meine Daten zuzugreifen, kann also nichts genaues sagen) - vor dem resizen der ext4-Partition wollte ich einen fsck ausführen, wie es im Netz empfohlen wird, also "fsck.ext4 -f /dev/md0" ausgeführt - dabei bekam ich einen erkannten Fehler angezeigt, der sich wie folgt las (Beispiel aus einem Forum): Inode 96108844 has an invalid extent node (blk 1537738982, lblk 0) Clear<y> - das habe ich bejaht, dann passierte in dem Prozess gefühlt 3-5 Minuten nichts, dann brach dieser durch einen OOM Fehler ab - an der Stelle wurde es mir zu heiß und ich wollte erstmal auf die bereits bestellte Backup-Platte warten, da ich mir das Thema jetzt eh mal vornehmen wollte - ca. 15-20 Minuten später wollte ich per SMB auf Daten auf dem RAID zugereifen und bemerkte dass viele Directories komplett leer sind und viele Dateien korrupt, Bilder nur noch zu einem Drittel oder gar nicht mehr gelesen werden können etc. - im dmesg gab es daraufhin immer mal wieder drei verschiedene Arten von Fehlern zu lesen: [Sun Aug 4 15:15:18 2024] EXT4-fs error (device md0): htree_dirblock_to_tree:915: inode #158122016: block 1425161073: comm smbd: bad entry in directory: rec_len % 4 != 0 - offset=0, inode=2347148723, rec_len=23058, name_len=57, size=4096 [Sun Aug 4 15:15:20 2024] EXT4-fs error (device md0): ext4_ext_find_extent:889: inode #159777629: comm smbd: pblk 1278268966 bad header/extent: invalid magic - magic 31d1, entries 10605, max 17309(0), depth 59656(0) [Sun Aug 4 15:25:09 2024] EXT4-fs error (device md0): htree_dirblock_to_tree:915: inode #23117843: block 290551738: comm smbd: bad entry in directory: directory entry overrun - offset=0, inode=2642206138, rec_len=62956, name_len=71, size=4096 Ich habe /dev/md0 erstmal geunmounted und den Samba-Dienst gestoppt, mittlerweile den Rechner heruntergefahren. Ich warte jetzt auf die bestellten Backup-Platten. Um in der Zwischenzeit nicht ganz verrückt zu werden, versuche ich mir gerade alle Möglichkeiten zusammenzusuchen. Erster Schritt sollte ein kompletter dd Dump auf eine Backupplatte sein. Den Dump wollte ich dann als Loopback mounten und schauen, was testdisk und photorec sagen, ob da überhaupt noch irgendwas zu holen ist. Falls ja, auf die zweite neue Platte die Wiederherstellung von Dateien als Ziel laufen lassen. Auf dem Dump hätte ich dann auch einen erneuten fsck (diesmal mit e2fsck) versucht, diesmal dann mit einem Verzeichnis als Zwischenspeicher für die gefundenen Konflikte (siehe: https://serverfault.com/a/9233 ). Ein Bekannter gab mir nun aber den Hinweis, selbst das Ziehen eines Images erstmal sein zu lassen, da der RAID-Algorithmus auch beim lesenden Zugriff versuchen könnte, Daten zu verändern. Das wäre natürlich der absolute GAU. Seht ihr hier Chancen, dass man das ext4 System wieder hinbekommt und auf die Daten wieder korrekt zugreifen kann? Oder ist mit so einem abgebrochenen Check vermutlich schon zu viel zerstört? Habt ihr noch andere Ideen für Tools oder Möglichkeiten, was man tun könnte? Ich bedanke mich herzlich im Voraus bei euch! Beste Grüße Max

1 0

Korrupte Dateien in ext4 auf RAID5
by Max Pietzsch 05 Aug '24

05 Aug '24

1 0

Ist die Festplatte gleich für die Mülltonne?
by Luca Bertoncello 05 Aug '24

05 Aug '24

Moin Leute! Letzte Woche gab es ein kleines Problem bei mir zu Hause und ein Vollidiot (ich kenne kein Wort, was noch besser den Kerl definieren kann), hat mit Gewalt meine ganze Technik ausgeschaltet. Da ich im Urlaub war, konnte ich leider auch nichts dagegen tun... Egal, Fakt ist, dass seitdem (ich bin heute wieder zu Hause), meldet sich SMART so: SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Interrupted (host reset) 90% 7053 - # 2 Extended offline Interrupted (host reset) 90% 7030 - # 3 Short offline Interrupted (host reset) 90% 7029 - ... Und in dmesg sehe ich folgendes (jeden Tag, bei der Zeit, wann die Prüfung gemacht wird): [So Aug 4 02:10:49 2024] ata1.00: exception Emask 0x0 SAct 0x1f80000 SErr 0x0 action 0x6 frozen [So Aug 4 02:10:49 2024] ata1.00: failed command: WRITE FPDMA QUEUED [So Aug 4 02:10:49 2024] ata1.00: cmd 61/18:98:80:cd:10/00:00:07:00:00/40 tag 19 ncq dma 12288 out res 40/00:01:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) [So Aug 4 02:10:49 2024] ata1.00: status: { DRDY } [So Aug 4 02:10:49 2024] ata1.00: failed command: WRITE FPDMA QUEUED [So Aug 4 02:10:49 2024] ata1.00: cmd 61/08:a0:b8:cd:10/00:00:07:00:00/40 tag 20 ncq dma 4096 out res 40/00:01:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) [So Aug 4 02:10:49 2024] ata1.00: status: { DRDY } [So Aug 4 02:10:49 2024] ata1.00: failed command: WRITE FPDMA QUEUED [So Aug 4 02:10:49 2024] ata1.00: cmd 61/08:a8:e8:cd:10/00:00:07:00:00/40 tag 21 ncq dma 4096 out res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [So Aug 4 02:10:49 2024] ata1.00: status: { DRDY } [So Aug 4 02:10:49 2024] ata1.00: failed command: WRITE FPDMA QUEUED [So Aug 4 02:10:49 2024] ata1.00: cmd 61/08:b0:18:ce:10/00:00:07:00:00/40 tag 22 ncq dma 4096 out res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [So Aug 4 02:10:49 2024] ata1.00: status: { DRDY } [So Aug 4 02:10:49 2024] ata1.00: failed command: WRITE FPDMA QUEUED [So Aug 4 02:10:49 2024] ata1.00: cmd 61/08:b8:38:ce:10/00:00:07:00:00/40 tag 23 ncq dma 4096 out res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [So Aug 4 02:10:49 2024] ata1.00: status: { DRDY } [So Aug 4 02:10:49 2024] ata1.00: failed command: WRITE FPDMA QUEUED [So Aug 4 02:10:49 2024] ata1.00: cmd 61/08:c0:58:ce:10/00:00:07:00:00/40 tag 24 ncq dma 4096 out res 40/00:01:06:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) [So Aug 4 02:10:49 2024] ata1.00: status: { DRDY } [So Aug 4 02:10:49 2024] ata1: hard resetting link [So Aug 4 02:10:50 2024] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [So Aug 4 02:10:50 2024] ata1.00: configured for UDMA/133 [So Aug 4 02:10:50 2024] ata1: EH complete Nun würde ich mich auf eure Meinung freuen... Ist die Festplatte gleich "mülltonnenbereit" oder ist was, das per Software zu reparieren ist? Ich tendiere das erste, freue mich aber auf eure Meinung. Viele Grüße Luca Bertoncello (lucabert(a)lucabert.de)

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Lug-dd August 2024