EasyLFS Projektthread

[Laudian]

ja, Gcc3 hoch ist ein Kompromiss. Hab hier Ende Maerz einen der Debianer aus Muenchen getroffen und mit dem ueber Sicherheit (Securityprofi im Informatikbereich) und damit auch ueber grundlegende OS-Dinge geredet. Seine Meinung war, koennte er GCC 1.4 weiter verwenden, wuerde er das tun ... leider ist das mit aktueller Software nicht mehr durchfuehrbar. Kompiler vor 2.95.1 erfordern erhebliches Umprogrammieren jedes einzelnen Paketes, da selbst die Binutils ab 2.95.1 unterstuetzen ... mit dem 3.0.4 (rund 10MB Download-Volumen) hatte ich arge Probleme, mit der 3.4.6 (18-19MB Download) komm ich ganz gut zurecht. Haette ja ganz gerne eine 3.0.x Version genutzt, aber der Aufwand ist mir zumindest im Moment noch zu gross.

Was die uClibc angeht, es gibt bei CLFS mehrere Projekte die darauf setzen ... das offizielle nutzt allerdings zusaetzlich Busybox und das ist mir dann zu festgelegt ... will die Grundsoftware sowie die Cross-Toolchain selber bestimmen koennen, genauso wie die verwendete Shell ...

XFast muss ich mir erst anschaun. Aber auch da hatte die Webserver-Variante einen Hintergedanken. Plane schon laenger an einem "normalen" Online-Desktop, also einer PhP-Oberflaeche die das regulaere Arbeiten auf einem entfernten PC ueber die normalen Webserver-Schnittstellen ermoeglicht. Habe mir also gedacht, der Plan kann auch local funktionieren, mit dem grossen Vorteil, dass zur Nutzung des heimischen PCs incl der regulaeren Oberflaeche weder VNC, VPN oder SSH genutzt werden muss, sondern ich nur die normalen Geschwindigkeitseinbussen durch Dateitransfer ueber Inet habe ...
Da der gesamte Desktopbereich noch in Planung war und ist, und auch die Frage der Sicherheit noch nicht so ganz geklaert ist, waere das ein ziemliches Zukunftsprojekt. Was dabei auch noch zu klaeren ist, ist die Frage, welcher Browser genutzt werden kann ... oder ob auf einem Webengine alias Gecko oder einer anderen, die moeglichst keine weiteren Bibs benoetigt ein eigener Vollbildbrowser, der moeglichst nur Tabbingfunktion braucht geschrieben werden soll ... dieser Browser laeuft dann im Vollbild auf dem Framebuffer, wers dreist will, kann den Browser auch so einrichten, dass 2, oder 4 oder 9 auf einen Framebuffer gehen und somit entsprechend mehr "Desktops" parallel nutzen
Ganz nebenher existiert dann kein Treiberhungriger X-Server, der mich seit dem er massgeblich nur noch ueber Xrandr konfiguriert wird abgrundtief ankotzt, es wird kein weiterer Treiber als ein VesaFB benoetigt, was enorm Ram spart ... etc pp ... Haette eigentlich nur Vorteile ... nur muss das Sicherheitsproblem geloesst werden und vermutlich ein etwas speziellerer Webbrowser ... der wenn alles optimal laeuft rekursiv nutzbar ist, also sich selbst darstellen kann ueber die PhP-Oberflaeche ...

Noch ist das alles Zukunftsmusik und wirklich eher ein Gedankengespinst ... es war vor einer Woche mehr ein Spass, aus dem ich die Desktopvariante mal ausprobieren wollte

Ich spamme grad irgendwie hier deinen Thread voll, dass weis ich, aber es passte grad dazu ... mal gucken, wenn sich das erhaerten sollte, werd ich mal Featureliste etc zusammen tragen und hier nen eigenen Projektthread basteln.

 

[andy72]

Deine Idee klingt ja Grundsätzlich gut, jedoch habe ich bezüglich der Weboberfläche als Desktop etwas bedenken:

PHP erlaubt ja eine ganze Menge, angefangen von "einfachen" Dateimanipulationen bis hin zu
kompletten Strukturen (sieht man ja am ganzen Web 2.0-Gehabe) - aber um den Web-Desktop
möglichst schnell darzustellen (d.h. zB wenn ich ein Fenster via Div-Element darstelle und ziehen
will) wird es im Framebuffer arge Einbußen geben, denn ein Framebuffer ist eben kein beschleunigter
Desktop sondern eben nur ein Puffer - ein Klumpen RAM in dem sich alles abspielt.
Rein von der Performance her hege ich da Zweifel

Aber viellt. kann man ja im Framebuffer mehr machen als ich vermute - eine wirkliche Ahnung
habe ich davon von Programmiererseite nicht

Lg

 

[Dennis Wronka]

Meine Idee bezueglich xfast war auch eigentlich weniger diesen als vollwertigen Ersatz fuer eine grafische Oberflaeche zu nutzen sodass der User dort arbeiten kann, sondern eben rein als Platform fuer den Browser. Somit koenntest Du einfach Firefox einsetzen.

Obwohl, hab grad mal fix gegoogelt und es scheint dass GTK+ mittlerweile auch auf dem Framebuffer arbeiten kann, ohne X. Somit ist es dann wohl auch moeglich Firefox im Framebuffer laufen zu lassen.

Uebrigens, keine Panik wegen dem Thread-Hijacking. Ist schon in Ordnung.

 

[Dennis Wronka]

So, hab jetzt mal was rumgetestet.

Mein Speicher scheint okay zu sein, wie eigentlich erwartet. Zudem hab ich mal einen Build in QEmu (ohne KQEmu oder KVM) gestartet und auch dort ist das Problem aufgetreten, also auch kein KVM-spezifisches Problem.
Das Problem scheint auch unabhaengig von der Bit-Zahl des OS und vom der VM zugewiesenen Speicher zu sein (hab es mit 512MB und 1GB probiert, was zuvor wunderbar geklappt hat).

Im Moment tippe ich also auf ein Kernel-Problem in Zusammenhang mit ext3 und ext4. ext2 funktioniert, und gerade jetzt laeuft ein Test-Build mit JFS, da ich testen will ob auch andere Journaling Filesystems (zusaetzlich zu den genannten werde ich wahrscheinlich auch noch die anderen beiden in meiner Liste, ReiserFS und XFS, testen), und da sieht es bislang noch ganz gut aus. Aber mal abwarten.
Wie gesagt, ext2 ist okay.

Naja, ich werde mal weitertesten. Eventuell nochmal den 2.6.28er Kernel ausgraben und damit testen und dann mal schauen wie's weitergeht.

 

[Dennis Wronka]

So, nach einem Monat Arbeit mal wieder ein Update. Sehr viel hat sich in der Zeit nicht getan. Ich hab hauptsaechlich rumgetestet was denn nun mit ext3 und ext4 los ist.
Die anderen Dateisysteme sind in Ordnung, ReiserFS hab ich zwar nicht getestet, dafuer aber ext2, XFS und JFS, welche alle wunderbar arbeiten.
Ist nur dumm dass ext3 zur Zeit Standard ist und ext4 diese Position in absehbarer Zeit eigentlich einnehmen soll.

Zum Problem an sich hab ich ja bereits was gepostet:

Ansonsten hab ich zur Zeit Probleme mit Ext3 und Ext4. Da muss ich mal pruefen warum denn ueberhaupt. Problem koennte eventuell der Kernel sein, oder aber fehlerhafter Speicher. Beides waere bloed. Den Kernel wieder auf 2.6.28.x runterzusetzen wuerde heissen dass ich einige Aenderungen am LiveCD-Prozedere rueckgaengig machen muesste (Kernel 2.6.29 hat da ein paar Sachen einfacher gemacht da SquashFS direkt integriert ist), Speicher pruefen ist langwierig und langweilig, aber wenigstens ist der noch recht neu und sollte somit einfach umtauschbar sein.

So, hab jetzt mal was rumgetestet.

Mein Speicher scheint okay zu sein, wie eigentlich erwartet. Zudem hab ich mal einen Build in QEmu (ohne KQEmu oder KVM) gestartet und auch dort ist das Problem aufgetreten, also auch kein KVM-spezifisches Problem.
Das Problem scheint auch unabhaengig von der Bit-Zahl des OS und vom der VM zugewiesenen Speicher zu sein (hab es mit 512MB und 1GB probiert, was zuvor wunderbar geklappt hat).

Nun ja, eine Loesung gibt es bislang nicht.
Ein Problem ist dass ich mittlerweile GLibC in Abhaengigkeit mit dem laufenden Kernel kompiliere um moeglichst die aktuellsten Features nutzen zu koennen. Das verhindert natuerlich dass ich mal eben einen aelteren Kernel ausprobieren kann. Das ist natuerlich kein unloesbares Problem, dennoch hab ich diesen Test erstmal aufgeschoben, da es ja auch noch andere Baustellen und andere Moeglichkeiten gibt.

Zur Zeit teste ich einen Build mit dem alten Scheduler (SLAB). Moeglicherweise hilft es ja diesen zu nutzen anstelle des neuen (SLUB).
Mal schauen was dabei rauskommt.
Als naechste Moeglichkeit gaebe es dann noch wieder den alten IDE-Treiber zu nutzen anstelle der neuen LibATA, obwohl ich doch eigentlich gern letztere nutzen wuerde.

Naja, es gibt halt noch einiges zu tun.

Ansonsten arbeite ich zur Zeit daran alle Scripts zu ueberarbeiten sodass make install (oder zusaetzliche/equivalente Aktionen) nur dann ausgefuehrt werden wenn der Code auch erfolgreich kompiliert wurde. Das sollte helfen Probleme zu vermeiden wenn mal ein wenig was schiefgeht. Stage 1 ist bereits fertig (aber noch ungetestet), Stage 2 kommt dann in den naechsten Tage, ist ja doch etwas groesser als Stage 1.

Auch das Update von GCC hat neue Probleme gebracht. Irgendwie kommt die Installation von GetText durcheinander, aber scheinbar nur auf 64-Bit...
Eine Loesung hab ich bereits gefunden, wuerde aber gerne darauf verzichten koennen. Muss mal weiter testen.

GLibC 2.9 hat sich beim kompilieren in eine Endlosschleife gehaengt. Aber nur beim 2. Durchgang (welcher nur noetig ist wenn SELinux installiert wird). Das Problem konnte geloest werden indem dieser Durchgang erst erfolgt nachdem GCC installiert wurde, das wiederum scheint aber wieder Probleme mit SELinux zu erzeugen, denn dies kann nicht geladen werden.
Naja, ich hoffe dass sich das mit der neuen Version der GLibC (aktuelle 2.10.1) gegessen ist.

Ja, was gibt's sonst? Bash 4.0, GDB, ...
Bei den POSIX-Capabilities gibt es auch ein Problem, denn es scheint als waere das PAM-Modul pam_cap, welches eigentlich einen User mit Capabilities ausstatten soll, vollkommen nutzlos. Zumindest funktioniert es bei mir nicht, und auch Fedora kann's scheinbar nicht besser.

Mein Rechner hat in letzter Zeit also so einiges zu tun. Da wird eifrig kompiliert. Oft in 2 VMs gleichzeitig.

 

[Dennis Wronka]

GLibC 2.9 hat sich beim kompilieren in eine Endlosschleife gehaengt. Aber nur beim 2. Durchgang (welcher nur noetig ist wenn SELinux installiert wird). Das Problem konnte geloest werden indem dieser Durchgang erst erfolgt nachdem GCC installiert wurde, das wiederum scheint aber wieder Probleme mit SELinux zu erzeugen, denn dies kann nicht geladen werden.
Naja, ich hoffe dass sich das mit der neuen Version der GLibC (aktuelle 2.10.1) gegessen ist.

So, das Problem mit SELinux scheint gegessen zu sein. Problem war nicht GLibC, sondern meine eigene Ignoranz gegenueber der Kernel-Dokumentation... Mit Hilfe der SELinux-Mailingliste konnte aber dem Problem auf die Spur gekommen werden. Somit kann es jetzt heiter weiter gehen.

GLibC haengt sich zwar auch in Version 2.10.1 noch in eine Endlosschleife, aber da das SELinux-Problem nicht von der geaenderten Position von GLibC in der Kompilier-Reihenfolge herruehrt duerfte es wohl kein Problem sein GLibC mit SELinux-Support eben etwas spaeter zu installieren, eben nach GCC, wo es scheinbar keine Probleme mehr macht.

Ein kurzer Test mit SLAB und ext4 sieht bislang auch schonmal nicht schlecht aus. Moeglicherweise ist ja SLAB wirklich des Raetsels Loesung um endlich wieder in den Genuss von ext3 und ext4 zu kommen.
Aber ob das auch wirklich der Fall ist muss eben noch ein wenig getestet werden.

In den naechsten Tagen steht also der Test mit SLAB an, und es gibt scheinbar so einiges an der SELinux-Policy zu tun um diese in einen brauchbaren Zustand zu versetzen.

Und dann mal schauen was noch so zu tun ist.

 

[Dennis Wronka]

Okay, wieder ein Update, ein ganz kleines...

Wie erwaehnt hat sich das SELinux-Problem nun erledigt. Da ich aufgrund des neueren Kernels eh meine Kernel-Config anpassen muss werd ich die noetige Aenderung dort auch gleich aufnehmen.

Letzte Nacht hab ich eine minimale 32-Bit Installation durchgefuehrt. Gerade jetzt laeuft eine identische 64-Bit Installation.
Diese Systeme werde ich dann nutzen um neue LiveCDs mit der aktuellen Software zu bauen, dabei werde ich auch gleich den Test mit SLAB durchfuehren um zu sehen ob dann ext3 und ext4 funktionieren. Wenn das klappt wird SLAB auf den CDs zum Einsatz kommen und auch Teil der Kernel-Config werden.

Zusaetzlich hab ich etwas aufgeraeumt. Die Dateien fuer das InitRamFs habe ich zuvor in /initramfs gehabt, was doch etwas unschoen ist. Das Verzeichnis wurde nun nach /usr/src/initramfs verschoben.

An den Scripts wird auch fleissig gearbeitet. Stage 1 habe ich ja bereits abgeaendert sodass make install abhaengig vom Erfolg des Compiles durchgefuehrt wird, Stage 2 ist jetzt in Arbeit.
Ausserdem hab ich mein Hilfs-Script cp2initramfs angepasst, das Kopieren der fuer Programme noetigen Libraries funktioniert jetzt besser.

Zu guter Letzt sei noch erwaehnt dass ich, nachdem ich zuletzt schon GDB in die Liste der verfuegbaren Pakete aufgenommen habe, nun auch strace hinzugefuegt habe. Beide sind natuerlich optional.

Es gibt noch ein paar Baustellen, so kompiliert z.B. BlueZ zur Zeit nicht und DPkg hat auch ein kleines Problem, aber da werde ich mich in naeherer Zukunft drum kuemmern.

 

[Dennis Wronka]

So, ein 32-Bit Build mit SLAB und ext4 ist erfolgreich durchgelaufen. Entsprechend werde ich wohl nun von SLUB auf SLAB umstellen.
Heute kommt noch ein Test mit 64-Bit, aber ich bin zuversichtlich.

Das neue 32-Bit System wurde nun auch direkt in eine LiveCD verpackt sodass ich dann anschliessend testen kann das System von der CD auf ein ext4-Dateisystem zu installieren.

Waehrend des letzten Builds sind auch ein paar neue Probleme aufgetaucht, diese wurden behoben und in Patches gepackt sodass beim bei der Installation der entsprechenden Pakete (PartImage und cdrkit) keine Probleme auftreten.
Grund fuer die Fehler sind vermutlich in GCC (PartImage) und GLibC (cdrkit) zu finden. GCC wird ja gerne mal von Version zu Version etwas strikter in der Auslegung der Standards und GLibC hat scheinbar ein paar neue Funktionen die cdrkit zusaetzlich selbst implementiert.

 

[Dennis Wronka]

So, nochmal ein kurzes Update.

Vorhin hab ich mal wieder die Pakete aktualisiert, insgesamt 39, darunter der Kernel, GLib, HAL, die CoreUtils und einige andere.

Zur Zeit gibt es folgende Baustellen:

1. Test ob alle Pakete kompilieren:
   Falls Pakete noch Probleme haben muessen diese natuerlich, entweder in den Installationsscripts oder per Patch behoben werden.
2. Test ob nach dem Wechsel vom SLUB- zum SLAB-Allocator nun auch ext3 und ext4 wieder funktionieren:
   Ein Test mit einer neuen LiveCD mit SLUB brachte den alten Fehler. Grad jetzt laeuft ein Test mit einer LiveCD mit SLAB. Ergebnis gibt's morgen.
3. Test ob alle Libraries richtig abgelegt werden:
   Dies betrifft nur die 64-Bit Version. Libraries sollen dort nicht in /lib und /usr/lib sondern /lib64 und /usr/lib64 abgelegt werden. Ausnahmen sind zur Zeit noch ein paar Pakete die in /usr/lib Unterverzeichnisse anlegen und dort eigenen Kram verwalten, z.B. Python und Perl.
4. Kernel-Config:
   Die aktuell bei der Installation eingesetzte Kernel-Config ist noch vom Kernel 2.6.28. Diese muss aktualisiert werden um vernuenftig mit dem aktuellen Kernel mitzuspielen, vor allem in Hinblick auf das InitRamFs welches ich zuletzt verschoben hab.
5. Test von GCC mit Stack-Protection:
   Die Moeglichkeit Stack-Protection zu aktivieren ist bereits gegeben. Dabei wird zum einen das gesamte System mit Stack-Protection kompiliert, zum anderen ist diese auch im endgueltigen System standardmaessig aktiviert, sodass alle Software die im Anschluss kompiliert wird den gleichen Schutz erfaehrt.
   Dies muss aber noch weiter getestet werden, vor allem der 2. Build der GLibC war da etwas heikel.
6. SELinux-Policy:
   Die Reference-Policy muss erweitert werden damit EasyLFS arbeiten kann. Optimalerweise sollte die Policy soweit angepasst sein dass man waehrend der Arbeit im System nicht von SELinux behelligt wird.
7. LZMA-Kompression fuer SquashFS:
   Da die letzten Versionen von EasyLFS alle ueber LZMA-komprimierte Module verfuegten waren diese bedeutend kleiner als die aktuellen Images sind. Nach Moeglichkeit sollte auch die kommende Version LZMA nutzen um die CD-Images moeglichst klein zu halten. Dies haengt aber nicht unwesentlich davon ab ob der noetige Code in den Kernel einfliesst.
8. Konditionelles make install:
   Wie bereits erwaehnt ist Stage 1 bereits abgeschlossen, Stage 2 ist in Arbeit. Da dies aber so einige Scripts sind dauert das natuerlich ein wenig.
9. Eine neue LiveCD fuer die 64-Bit-Version:
   Fuer die 32-Bit-Version gibt es bereits eine neue LiveCD mit SLAB. Ein Image mit der selben Ausstattung wie in der 32-Bit-Version muss auch fuer die 64-Bit-Version erstellt werden.
10. Test ob LVM/Software-RAID und verschluesselte Partitionen funktionieren.

Aktuell arbeite ich an den Punkten 2 (fuer 32-Bit) und 8. Wenn 2 abgeschlossen ist folgen 1 (fuer 32-Bit) und 9, welches notwendig fuer die 64-Bit-Tests der Punkte 1 und 2 ist.
Danach werd ich dann weitersehen. Auf jeden Fall werd ich mit den genannten Punkten noch ein paar Tage beschaeftigt sein, oder eher mein PC.

 

[Dennis Wronka]

So, mal ein Update. Hier nochmal der Reihe nach die im vorigen Post angesprochenen Punkte, mit aktueller Status-Info.

• Test ob alle Pakete kompilieren:
  Falls Pakete noch Probleme haben muessen diese natuerlich, entweder in den Installationsscripts oder per Patch behoben werden.

Daran hab ich nicht direkt gearbeitet, aber ein paar kleine Fehler behoben die ein paar Pakete an der Installation hinderten.

• Test ob nach dem Wechsel vom SLUB- zum SLAB-Allocator nun auch ext3 und ext4 wieder funktionieren:
  Ein Test mit einer neuen LiveCD mit SLUB brachte den alten Fehler. Grad jetzt laeuft ein Test mit einer LiveCD mit SLAB. Ergebnis gibt's morgen.

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...

• Test ob alle Libraries richtig abgelegt werden:
  Dies betrifft nur die 64-Bit Version. Libraries sollen dort nicht in /lib und /usr/lib sondern /lib64 und /usr/lib64 abgelegt werden. Ausnahmen sind zur Zeit noch ein paar Pakete die in /usr/lib Unterverzeichnisse anlegen und dort eigenen Kram verwalten, z.B. Python und Perl.

Da hab ich nicht dran gearbeitet, und ich erinnere mich nicht daran "zufaellig" was daran gemacht zu haben. Steht also noch aus.

• Kernel-Config:
  Die aktuell bei der Installation eingesetzte Kernel-Config ist noch vom Kernel 2.6.28. Diese muss aktualisiert werden um vernuenftig mit dem aktuellen Kernel mitzuspielen, vor allem in Hinblick auf das InitRamFs welches ich zuletzt verschoben hab.

Steht noch aus. Daran werd ich mich wohl machen wenn EasyLFS mehr oder weniger fertig ist, denn ansonsten muss ich das nur spaeter nochmal durchkauen, z.B. wenn Kernel 2.6.30 kommt bevor ich fertig bin (was wahrscheinlich ist).

• Test von GCC mit Stack-Protection:
  Die Moeglichkeit Stack-Protection zu aktivieren ist bereits gegeben. Dabei wird zum einen das gesamte System mit Stack-Protection kompiliert, zum anderen ist diese auch im endgueltigen System standardmaessig aktiviert, sodass alle Software die im Anschluss kompiliert wird den gleichen Schutz erfaehrt.
  Dies muss aber noch weiter getestet werden, vor allem der 2. Build der GLibC war da etwas heikel.

Auch hier hab ich nichts dran gemacht.

• SELinux-Policy:
  Die Reference-Policy muss erweitert werden damit EasyLFS arbeiten kann. Optimalerweise sollte die Policy soweit angepasst sein dass man waehrend der Arbeit im System nicht von SELinux behelligt wird.

Aehnlich wie die Kernel-Konfiguration ist die SELinux-Policy was fuer die spaete Phase der Arbeit an EasyLFS. Aendert sich die Software kann sich ja durchaus mal was an deren Anforderungen aendern, und somit eventuell auch an der Policy. Zudem koennte ja auch eine neue Reference-Policy kommen bevor ich fertig bin und ich muesste von Neuem beginnen.

• LZMA-Kompression fuer SquashFS:
  Da die letzten Versionen von EasyLFS alle ueber LZMA-komprimierte Module verfuegten waren diese bedeutend kleiner als die aktuellen Images sind. Nach Moeglichkeit sollte auch die kommende Version LZMA nutzen um die CD-Images moeglichst klein zu halten. Dies haengt aber nicht unwesentlich davon ab ob der noetige Code in den Kernel einfliesst.

Wie zuvor erwaehnt ist dieser Punkt schlichtweg davon abhaengig ob der LZMA-Code in den Kernel einfliesst. Sobald dies der Fall ist werde ich mich dransetzen.

• Konditionelles make install:
  Wie bereits erwaehnt ist Stage 1 bereits abgeschlossen, Stage 2 ist in Arbeit. Da dies aber so einige Scripts sind dauert das natuerlich ein wenig.

Stage 2 ist nun auch abgeschlossen. Der Punkt ist somit abgehakt.

• Eine neue LiveCD fuer die 64-Bit-Version:
  Fuer die 32-Bit-Version gibt es bereits eine neue LiveCD mit SLAB. Ein Image mit der selben Ausstattung wie in der 32-Bit-Version muss auch fuer die 64-Bit-Version erstellt werden.

Daran arbeite ich gerade. Oder besser gesagt: Mein PC kompiliert grad fleissig.

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

Spaeter...

Zusaetzlich sei noch erwaehnt dass zuletzt die Erstellung einer LiveCD fuer 64-Bit daran scheiterte dass es ein Problem bei der Installation gab.
Von CD (mit etwas aelterer Software) konnte ich das aktuelle System erfolgreich auf Platte installieren. Dieses System war dann aber nicht in der Lage sich selbst nochmal zu kompilieren, obwohl dieses Problem bei einem identischen 32-Bit-System nicht bestand.
Ich hab nun was gefunden und eine Kleinigkeit an der Installation von GCC (2. Durchlauf Stage 1) geaendert (nur fuer 64-Bit Installationen) und hoffe dass dies nun zum Erfolg fuehrt.

Hier also mal kurz die Liste der Punkte (abzueglich der erledigten), in der Reihenfolge die ich mir zur Zeit fuer die Abarbeitung vorstelle.

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

Okay, im Moment arbeite ich also an Punkt 1. Zeitgleich arbeite ich auch noch an einer neuen LiveCD fuer 32-Bit, da dies aber nur so nebenbei passiert verdient dies keinen eigenen Punkt. Noetig ist's eigentlich nicht, sondern laeuft hauptsaechlich als ext4-Test.

Anschliessend kommen Punkte 2 und 3, die koennen in einem Abwasch durchgefuehrt werden da ich sehen werde ob irgendwelche Libraries falsch abgelegt werden wenn ich alle verfuegbaren Pakete installiere.

Punkt 4 duerfte einige Durchlaeufe benoetigen. Mindestens 4, wenn alles glatt laeuft (fuer 32- und 64-Bit, jeweils mit und ohne SELinux).

Punkt 5 sollte mit 3 Tests getan sein, hier sollte es nicht noetig sein mit beiden Versionen von EasyLFS zu testen.

Wenn sich EasyLFS der Veroeffentlichung naehert, also wenn alles so funktioniert wie es soll werde ich wohl eine Art Freeze durchfuehren nach dem sich nichts mehr an den Paket-Versionen aendern sollte. Dann ist es Zeit sich um die Punkte 6 und 7 zu kuemmern.

Punkt 8 ist, wie gesagt, optional und davon abhaengig ob der Kernel diese Moeglichkeit bietet. Dieser Punkt steht zwar am Ende der Liste, duerfte aber an Prioritaet gewinnen sobald Support vorhanden ist.

So, das war es nun erstmal wieder in Sachen EasyLFS.
Es geht also heiter weiter und ich freu mich bald mal wieder eine Installation auf einem echten System durchfuehren zu koennen.
Die letzte, und bislang einzige, echte Installation war EasyLFS 0.1 auf einem 586er Notebook mit 64MB RAM und 4GB Festplatte. Prozessortakt hab ich vergessen, war aber glaub ich 133MHz. Auf jeden Fall hat das Ding 3 Tage gebraucht um EasyLFS zu kompilieren.
Mein PC wird da sicher "ein wenig" schneller sein.

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.