Zitat von Dennis Wronka

SLAB macht keinen Unterschied. Das ist dumm, aber scheinbar nicht mehr so wichtig. Mittlerweile bin ich wieder bei SLUB und glaube den Fehler nun aufgespuert zu haben. Das Problem scheint zu sein dass ich in einem virtuellen System arbeite. Wenn ich nun dem Kernel Support als KVM-Gast einbaue funktioniert ext4 (und somit wahrscheinlich auch ext3).
Da ich nun eine Festplatte habe die ich nach belieben misshandeln kann werde ich wahrscheinlich mal das aktuelle ISO-File auf eine CD brennen und mal eine Installation auf einem echten System, meinem PC, durchfuehren. Da sollte es ja dann keine Probleme geben.
Nun stellt sich natuerlich die Frage ob die LiveCD Support als KVM-Gast haben sollte oder nicht...

Ja, wer glaubt wird selig... Oder auch nicht. In meinem Fall wohl eher nicht, denn mein Glaube dass KVM Schuld ist war fehlgeleitet. Eine echte Test-Installation auf meinem PC hat das gleiche Problem gezeigt. Entsprechend vermute ich jetzt dass es irgendwie daran liegen dass muss ich von einer LiveCD baue, warum auch immer.
Zwei Moeglichkeiten hab ich mir heute angeschaut:

• Eine LiveCD ohne die Linux-Live-Scripts. Ist moeglich, aber auch groesser. Der Groessenunterschied laesst sich aber mittels ZISOFS in Grenzen halten.
  Erste Tests leiden noch daran dass das Filesystem readonly ist, aber das wird man sicher mit UnionFS umgehen koennen. Ausserdem muesste ich hier auch irgendwie selbst dafuer sorgen dass die CD waehrend dem Boot gefunden wird.
• Die Linux-Live-Scripts von AUFS auf UnionFS umstricken. AUFS wird scheinbar nicht mehr gepflegt. Man hat scheinbar, da UnionFS vor der Aufnahme in den Kernel steht, das Handtuch geworfen.
  Die Live-Scripts sind nun bereits umgestrickt und eine Test-CD kompiliert gerade vor sich hin. Der kritische Zeitpunkt ist auch schon nah, aktuell ist GLibC dran, bei ZLib, dem naechsten Paket, tritt der Fehler ueblicherweise auf.

Naja, mal schauen wie's weitergeht. Wenn nichts hilft werde ich erstmal wie gehabt mit meiner Liste weitermachen, dann eben fleissig auf ext2, oder moeglicherweise XFS oder JFS, die funktionieren ja...

Obwohl sich bereits eine unwerfende Anzahl an Usern (0) gemeldet haben bleibt auch der Aufruf weiter aktuell:

Zitat von Dennis Wronka

An dieser Stelle mal ein kleiner Aufruf zur Mithilfe. Ich braeuchte jemanden der ein FakeRAID (also z.B. ueber einen onboard-RAID-controller) im Einsatz hat, darauf aber noch unpartitionierten Platz (4GB reichen) hat.
Grund ist dass ich gerne mal testen wuerde ob die Installation darauf klappt (davon gehe ich aus) und ob EasyLFS anschliessend davon booten kann (was ich bislang nicht testen konnte).

Wenn jemand die noetigen Resourcen hat wuerde ich mich freuen wenn das jemand testen koennte.

Edit: GLibC ist grad fertig geworden und auch ZLib wurde erfolgreich installiert ohne das System in die Ecke zu treten. Bislang sieht's also gut aus. Naja, mal abwarten ob alles durchlaeuft.

Okay, es ist wieder Zeit fuer ein Update. Die Dateisysteme funktionieren nun alle, dank des Wechsels von AUFS zu UnionFS. Die LiveCD ist nun also wieder voll funktionstuechtig.

Hier wieder die zuvor erwaehnten Punkte mit Status:

• Eine neue LiveCD fuer die 64-Bit-Version

Dieser Punkt ist erledigt. Sowohl fuer 32- als auch fuer 64-Bit hab ich aktuelle LiveCDs.

• Test ob alle Pakete kompilieren

Dies ist nun ein paar Mal durchgelaufen. Alle Pakete kompilieren jetzt. Ist also erledigt.

• Test ob alle Libraries richtig abgelegt werden

Daran arbeite ich gerade. Es werden leider noch nicht alle Libraries richtig abgelegt. LVM legt die Device-Mapper-Libraries in /usr/lib ab und auch die XFS-Progs legen dort was hin. Hab grad die Scripts angepasst sodass dies nun behoben sein sollte. Mysterioeserweise bekomme ich dort auch eine libbfd, die eigentlich von den BinUtils kommt, aber scheinbar nicht die die dort liegt, denn die BinUtils scheinen korrekt in /usr/lib64 abzulegen. Da muss ich mal schauen wo diese Dateien herkommen. Ich vermute zur Zeit von GCC.

• Test von GCC mit Stack-Protection

Das werd ich heute mal mit der 32-Bit-Version testen. Wenn die 64-Bit-Version endlich alle Libraries korrekt ablegt auch damit.

• Test ob LVM/Software-RAID und verschluesselte Partitionen funktionieren

Ich hab eine Installation auf LVM mit dem 32-Bit-System durchgefuehrt. Es funktioniert, das LVM-Init-Script wirft aber einen unschoenen (wenn auch nicht kritischen) Fehler. Da muss noch dran gearbeitet werden. Genauso wie weitere Tests mit Software-RAID, verschluesselten Partitionen und eben auf 64-Bit. Letzteres wenn alle Libraries endlich richtig liegen.

• Kernel-Config

Spaeter...

• SELinux-Policy

Spaeter...

• LZMA-Kompression fuer SquashFS

Der Kernel wurde jetzt auch 2.6.30 aktualisiert. Ich hab noch nicht geschaut ob diese Version LZMA-Kompression unterstuetzt, denke aber eher nicht. Werde dies testen wenn es wieder Zeit ist eine neue LiveCD zu stricken, wahrscheinlich am Wochenende.

Hier nun also die aktuelle ToDo-Liste:

1. Test ob alle Libraries richtig abgelegt werden
2. Test von GCC mit Stack-Protection
3. Test ob alle Pakete mit SELinux kompilieren
4. Test ob alle Pakete mit SELinux und Stack-Protection kompilieren
5. Test ob LVM/Software-RAID und verschluesselte Partitionen funktionieren
6. Kernel-Config
7. SELinux-Policy
8. LZMA-Kompression fuer SquashFS

Ich hab jetzt noch 2 Punkte (Test ob alle Pakete mit SELinux kompilieren und Test ob alle Pakete mit SELinux und Stack-Protection kompilieren) hinzugefuegt, da ja auch dies ordentlich getestet werden will.

Ansonsten hab ich noch Kleinigkeiten hier und da in meinen Scripts die mit #test oder #check markiert sind an denen ich noch schrauben will. Diese Markierungen werden aber langsam auch weniger.

Meine Güte, das geht ja richtig vorwärts bei Dir - Glückwunsch

Mal zu einem Problem, mit dem ich gerade selbst kämpfe:
Ich hab gesehen, daß Du den Kernel 2.6.30 an Board hast - grundsätzlich eine sehr gute Entscheidung, denn die neuen Features sowie etlichen Bugfixes aus 2.6.29 die
dort Einzug gehalten haben sind es ja allemale Wert Einziger Nachteil, der 2.6.30 hat
mal wieder seine Strukturen geändert, so daß sich der FGLRX Treiber von ATI nicht
starten lässt - Was folgt ist ein Abbruch, dass DRI nicht initalisiert werden konnte
und xorg fällt zurück in die Konsole.

Hat evtl. jemand eine Idee dafür, wie man das zum Laufen bringen könnte ?
Habe sämtliche MESA-Bib's und libdri auf aktuellsten Stand gebracht, aber der blöde Treiber will einfach nicht

Unter 2.6.29 habe ich sogar compiz ohne jegliche Probleme am Laufen, nur readahead ist dort ja im Kernel ausgeschaltet, weil es in 2.6.29 als unstable markiert wurde... somit kriecht die Kiste (Toshiba Notebook A210) gerade etwas.


Lg
Andy

Es gab mal wieder einen Zeitraum ohne Fortschritt an EasyLFS.
Dafuer geht es jetzt wieder langsam weiter, und EasyLFS wird bald umziehen.

Hallo Dennis Wronka

Machst du eigentlich an dem Projekt weiter?
Ich finde dein Leistung wirklich super und habe mir das Easylfs 0.4
runter geladen und auch schon ausprobiert,hat alles super geklappt.

Vieleicht würde es ja sinn machen auch mal ein Xumgebung und einen
kleinen Desktop wie Xfce mit ein zu Planen.

Ich werde mal schauen was nötig ist zu instalieren um Xfce zum laufen zu
bewegen, und dann Python scripte dafür schreiben, um es zu Automatisieren.

LG

Hi. Erstmal vielen Dank für die Blumen. Ist doch immer schön zu hören dass sich jemand für mein kleines Projekt interessiert.

Also: Ja, ich arbeite noch an EasyLFS, aber viel langsamer. Ich bin mittlerweile verheiratet und Daddy, da hat man dann nicht immer die Zeit für sowas. Vor Allem da ein Testbuild mal eben ein paar Stunden den PC beschäftigt.
Dieser ist zudem zur Zeit defekt, sodass ich nur noch mein Notebook hab, welches aber nur bedingt geeignet ist.

X in EasyLFS einzubauen wäre platzmässig drin, auch wenn das schon ordentlich das Image aufblähen dürfte.
Eine grossen Desktop-Umgebung wie KDE wäre aber overkill.
Der von Dir erwähnte XFCE oder ein Kleiner WM wie IceWM oder Afterstep wären sicher nett.

Anstelle von Python-scripts würde ich Bash-scripts empfehlen, damit alles konsistent bleibt. Zudem ist Python in 0.4 nicht im Standardumfang enthalten, sondern nur optional.
In der nächsten Version wird's zum Standardpaket.

Zudem sollte nach Moeglichkeit beim hinzufügen von Paketen auch auf Kompatibilität mit SELinux achten.

Na dann mal Herzlichen Glückwunsch für die Hochzeit und auch zu deinem Kind
Ich weiß das es das Leben Positive auf dem Kopf stellt geht mir ja auch so

Die Sache mit dem X und dem Xfce wäre denke ich bestimmt eine Sinnvolle
Sache denn es gibt ja auch jedem der sonst mit dem Originalen oder
auch mit Easylfs Arbeitet ein schönen aha Effekt und eben auch die Freude
was zu sehen mit dem die meisten auch was anfangen können.

Also wenn es erwünscht ist würde ich es gerne auf dein Projekt über Python
lösen und dann das Script Easylfs zur freien Verfügung stellen und auch
weiterhin daran Arbeiten damit man in gewissen Abständen Aktuellere
Software zur Verfügung hat wäre doch sinnvoll aufgeteilte Arbeit , mit dem
Bash Scripting bin ich leider nicht vertraut aber da Python ja ehe eine Option
ist wäre es eine gute Idee denke ich.

MFG

Das kannst Du gern machen. Ich wuerde auf jeden Fall gern sehen dass mein System auch gleich X installieren kann.

Zur Zeit gibt es aber leider noch keine Schnittstelle fuer zusaetzliche Module, die wollte ich schon lang mal einbauen, bin ich aber bislang nie zu gekommen. Entsprechend ist die einzige Moeglichkeit es direkt mit in EasyLFS zu integrieren, was eigentlich relativ einfach ist.

Du kannst uebrigens, bei Interesse, auch einen Blick in das Subversion-Repository werfen.
ViewVC gibt's hier: http://svn.easylfs.net/
Subversion ueber svn://svn.easylfs.net/repo/ (fuer Repositories siehe ViewVC )

Die Datei packages.odt im Docs-Repository koennte fuer Dich eventuell auch von Interesse sein.

Allgemein bin ich immer noch irgendwie mitten im Umstieg EasyLFS ein Community-Projekt zu machen, aber dafuer gibt's noch was an Arbeit bevor es soweit ist.