Achtung: Probleme mit e2fsprogs 1.40.1

[blob]

Vorsicht beim Gebrauch der neuen Version von e2fsprogs von vorgestern.

Nach dem Übersetzen usw. startet der Rechner nicht mehr, weil libblkid fehlt. Ganz schlecht ist das für Leute (wie mich), die ext4dev benutzen, wo es noch kein live-CD mit den Modulen ext4dev und jbd2 gibt mit dem man ins System chrooten und Reparaturen machen kann. Das ist mir gestern passiert, und es hat Stunden gedauert, bis ich reinkam und die alte Version von e2fsprogs wieder aufsetzen konnte

Dabei habe ich auch gelernt, daß es nützlich ist, nach dem backup auf eine andere Festplatte, dorthin zu chrooten und #lilo zu installieren. Ich mache zwar oft Total-Backup, aber weil lilo fehlte, das hat mir nichts genützt um die andere Festplatte (als master /dev/hda) anzustöpseln, zu starten, und dann in meine normale Installierung (dazu als slave /dev/hdb) zu chrooten

Und nochmal den Tip, die Partitions-Tabelle auf einen Zettel abschreiben und aufheben (insbesondere e2fsprogs hat viele Fehlfunktionen)

 

[blob]

Inzwischen wurde eine andere Version e2fsprogs 1.40.2 veröffentlicht, aber die genannten Probleme blieben.

Ich habe das aber inzwischen hingepfriemelt und ein Paket gemacht, das sowohl die fehlenden Bibliotheken übersetzt, als auch mit ext4dev startet und alle Funktionen funktionieren, wer diese Funktionen ebenfalls braucht oder benutzen will: <mein-site>/tgz

Bei der Gelegenheit noch folgendes Kurz-Info zu anderen Programmen: 1) Bei Kernel 2.6.22 tritt das Problem auf, daß der Curser vom keyboard oft nicht blinkt / verschwindet, das ist besonders beim Editor vom #mc sehr lästig. Bei 2.6.22-git6 ist das Problem behoben. 2) Seit vorgestern teste ich MySQL 6.0 alpha, zumindest bisher keine Probleme, läuft einwandtfrei, kann man sogar austauschen (mit #rpm -Uhv --replacepkgs --replacefiles --nodeps MySQL*.rpm) währenddem Server / Forum läuft

 

[blob]

Probleme mit e2fsprogs halten an

Die Probleme mit e2fsprogs, für welche in kurzer Zeit 3 Versionen gebracht wurden, halten an. Trotz eigener Korrekturen habe ich gestern mein Dateisystem ziemlich ruiniert. Ich glaube, es ist besser, weiter die Version 1.39-tyt3 zu benutzen, die sich monatelang bewährt hat ...

 

[blob]

Probleme mit btrfs

Probleme gibt es nun auch mit btrfs. Wenn man (wie auch bei mir) dies für wichtige Daten verwendet, ist es besser sie momentan zu retten.

Ab Kernel 2.6.23 werden Funktionen für swap geändert (dazu changelog zu 2.6.22-git14). Beim Übersetzen der externen Module für btrfs mit der letzten Vorversion für den künftigen Kernel treten nunmehr Fehlermeldungen bzgl. der Zusammenarbeit mit der geänderten Kernel-Funktion kmem_cache_create auf.


Nachtrag: ndiskwrapper übersetzt ebenfalls nicht mehr wegen diesen Änderungen. Unten die Antwort der Kernel-Fritzen. Kommentar dazu: es ist jedenfalls eine Änderung am Kernel - ganeuer gesagt an og Funktion - die anscheinend mehrere fundamentale externe Programme beeinträchtigt, und das Problem ist erst seit gestern (ist also neu in den Hauptstamm der Kernel-Entwicklung eingetreten), hoffentlich reparieren die das also Ich bin der Meinung, der Kernel muß insoweit compatibel bleiben, daß was früher funktionierte, auch weiter funktioniert; andernfalls kann man künftig nicht einmal mehr mit anderen Headers übersetzte glibc und Programme verwenden ...

On Sat, Jul 21, 2007 at 02:50:01AM -0300, werner wrote:
> Of the kernel 2.6.22-git15 of this night,  kmem_cache_create is not
> compatible and causes compiling errors of some fundamental programs.
> Before, this error didnt occur.
> 
Slab destructors haven't been supported in the kernel for ages, anything
that's relying on them to work out-of-tree is fundamentally broken.

> At least this happened on compiling the externel modules for btrfs and
> ndiskwrapper.    Principally the compatibility of the Kernel with older
> and new versions of the file systems have to be observed very good, for
> the reliability to can read dates.
> 
> Thus this should be checked, and corrected
> 
Indeed it should. You can correct this by removing the extraneous NULL
parameter for the slab dtor from the kmem_cache_create() callsite in the
out-of-tree code. All of the in-tree users were already converted.

 

[marneus]

Wenn ich die Antwort richtig deute - ich habe nämlich keine Ahnung mit was für Versionen Du da überhaupt rumfrickelst (ich lese was von "last night"...) - dann scheinst Du irgendeine Version zu nutzen, die seit Ewigkeiten outdated ist.

 

[blob]

Nein, im Gegenteil ist das die Vorbereitung auf den kommenden Kernel 2.6.23. Hier finden schon mengenmäßig erhebliche Veränderungen statt - ungefähr 15% des Kernels wird neu geschrieben - und funktionieren dann verschiedene Sachen von früher nicht mehr - falls das nicht im Kernel noch geändert wird ! (darunter u.a. ndiskwrapper, was für viele Geräte Windows-Driver verwendbar macht, sowie das Filesystem btrfs - und das sind nur diejenigen Sachen die ich zufällig bemerkt habe, wohl auch noch viel Anderes) Es ist m.E. wichtig, das möglichst schnell zu ändern und so den Kernel mit alten Dateisystemen usw. kompatibel zu halten - was ja einer der erklärten Zwecke offener Dateien (im Gegensatz zu gewerblichen) ist ... Mit den gegenwärtigen Änderungen maß man gefaßt sein, daß ab Kernel 2.6.23 Verschiedenes nicht mehr funktioniert. Ich vermute daß diese Nacht die erste -rc -Version zu 2.6.23 kommt, da schon git16 erreicht ist

 

[blob]

Inzwischen ist schon wieder mein Filesystem kaputt gegangen.

Es kamen Fehlermeldungen daß diverse inode zu groß wurden. In den zugehörigen Ordnern begannen dann Dateien zu fehlen und andere Probleme.

Reparaturversuche mit e2fsck gaben ihm dann den Rest. Viele Dateien und links fehlen jetzt.

Das liegt weniger am ext4dev als an bereits bestehenden Mängeln des ext2/3 Filesystemes ohne daß diese Mängel anscheinend bei ext4 behoben werden. Hier müßte eingebaut werden, daß solche inode automatisch vergrößert werden. Ferner am e2fsck was oft mehr Schaden anrichtet als repariert ... Bei seiner Anwendung ist offenbar größte Vorsicht geboten, am besten vorher einen kpl. backup machen !!! ext2/3/4 müßte durch was Besseres ersetzt werden ...

In Kürze schalte ich wieder ab, kopiere einen backup zurück, rette neuere downgeladene Dateien usw., formatiere neu mit mke2fs -I 256 ... Scheinbar ist das bei großen Dateisystemen allgemein empfehlenswert ... !