hjslfs-1.1.19 ist offline

Zitat

Originally posted by M.Temp
bei mir rennt es mit prestable leider nicht durch
Gibt es ne logdatei?

Yep - mehrere
./system/install/log/install.log
Anfang der Zeile zeigt Ausgang der dahinterstehenden Commands - sollte also immer null sein .

Wenn Fehler aufgetreten sind genauere Ursache in
./system/install/log/{host,system}/<SCRIPTNAME>.log
Dahin ist die Bildschirmausgabe "geteet"

Zitat

Was ich sonst so aufm ersten Blick gesehen habe hat er cvs nicht kompilieren können und grub nicht installieren.

cvs war zu erwarten - weiß nich warum der erst im zweiten Anlauf compiliert , aber werds rausfinden .
grub-install klappt nicht , wenn grub nicht compiliert wurde .
Was sagen die Logs ?

Zitat

Trotzdem bringt er die Meldung: "Kompilierung des Basissystems abgeschlossen!" - naja die Frage ist nur wie.....

Hehe - die Mes kommt auch nur am Ende des Scripts als Mitteilung " habe alle Scripte mal gestartet ".
An der Stelle die Logs checken is mir noch zu aufwendig - aber wird dann irgendwann mal lauten " Kompilierung des Basissystems abgeschlossen - es sind Fehler aufgetreten - Logs Checken ! "

Zitat

Ich hab gerade Angst, dass selbst wenn am Ende des Kompiliervorgangs keine Fehler stehen, irgendwo was schief lief, was sich vlt erst im späteren Betrieb zeigt.

Wie oben schon gesagt , die Mes sagt nichts über entstandene Fehler , nur das er nicht aus den Scripten selbst geworfen wurde ...
Fehler sollten in den Logs sein - sind dort keine , ist die Chance recht groß , daß er auch später rennt - es sein denn , man hat etwas zerkonfiguriert - aber nicht wegen Binary Fehler ...
Derzeit ist "make test" bei der libc inaktiv - kostet immens Zeit .
Wenn ich denn diverse andere Baustellen geschlossen hab , werd ich wohl die Variable "make_all_tests" einführen .

HJS

Zitat

Originally posted by vdrchuck
Bei mir das gleiche mit der prestable .

Mit dem grub hat was nicht geklappt (stage1, stage2) und das kernel image ist nicht da (in den kernel sourcen bzw. unter /boot/grub).

Ich schicke dir per PN einen Link um ein tar.bz2 File herunterzuladen mit den Verzeichnissen (/mnt/lfs/.system /mnt/lfs/hjslfs /mnt/lfs/tmp) --> evtl. kannst du daran was erkennen (?).

Yep - er rennt schon im Host bei binutils aus dem Ruder - zwangsläufig fällt damit gcc , libc und damit jedes weitere Script auf die Nase .
Was mich etwas irritiert , daß ich auch im Log von binutils-host nix finden kann ...
Laut var hast du deine LFS Zielpartition nicht formatiert ? Ist empfehlenswert , das zu tun ...

Zitat

Unter /mnt/lfs/tmp gibt es noch zwei Dateien "=tst-cancel4-socket-4-xxxx" di nicht im Archiv sind ?

Sagt mir nix - vermutlich Ausgaben irgendeines Packages .

Nimm mal die testing - die ist bei mir durchgerannt ...
Kontrolliere ./system/install/log/install.log ob binutils durchläuft , wenn wieder nicht , kannste das Ganze abbrechen - kann nicht mehr erfolgreich sein . Und die LFS Partition formatieren lassen oder wenn du den Scripten nicht traust vorher manuell formatieren .

HJS

Zitat

Original von vdrchuck
Ich mach jetzt mal ne Pause ist doch alles was zeitaufwendig .

Normalerweise nur für den Rechner .
Du hast :

- mind. 512 MB RAM ?
- direkt von der CD gebootet ?
- die Zielpartition formatiert ?
- die Hilfspartition formatiert oder mit korrektem fs angegeben ?
- ggf n fscheck auf der Hilfspartition laufen lassen ?

Was den Wiedereinsatzpunkt angeht : Zur Zeit leider keine Aufnahme am abgebrochenen Punkt möglich - Start zwingend wieder bei Null .
Die CD wieder als iso zurück auf die Platte kopiert und mit dem Download verglichen ergibt ne exakte Kopie ?

HJS

Zitat

Original von M.Temp
mal ne Frage: wie mach ich jetzt am besten weiter?

immer alle Scripte nochmals von vorne - also partition platt?
Oder kann ma das irgendwie beschleunigen?

Oups - die Frage hatte ich noch bei vdrchuck im Ohr
Wie erwähnt - leider derzeit immer restart bei null ...
Wird zwar der Host gesichert , aber das ist leider noch nicht ganz rund und da kommste ja auch noch nicht an ...

Zitat

Du sagst, die testing läuft durch? naja ich schau mir mal die logs an und probier dann vlt die!

Yep - derzeit sind experimental und testing identisch - experimental lief bei mir durch .
Nimm aber generell die testing - in der experimental doktere ich immer rum .
Die kann in wenigen Minutenn schon wieder anders aussehen ...

Zitat

edit: so ich hab die logs, aber ich bringe sie nicht auf meine usbsticks. Die erscheinen einfach net unter /dev
cu

Huch ?
Hab grad mal die CD wieder rein gepackt - USB Adapter für CF etc pp mit CD Card - wird erkannt als sdb ...
Was findeste denn in /sys/block ? Ist da ein sd{a,b,c,d,e,f,g,h} zu finden ?
Hotplug oder Coldplug ?
Optimal :
Coldplug , booten der CD - check von /dev ggf check von /sys/block
Wenn sd<x> da , aber nicht in /dev ( nicht vorstellbar ) aber nichtsdestotrotz :
in /etc/rc.d/init.d ist makedev
./makedev sda bzw geschickter :
cd /dev
/etc/rc.d/init.d/makedev sda

HJS

Zitat

Original von M.Temp
nein in /sys/block/ ist kein sd<x>

steck ich die sticks an kommt nur: blockusb 1-5: new high speed USB device using ehci_hcd and address 8....

Auch bei coldplug ?

HJS

Zitat

Original von M.Temp
nein

so nun sollten meine logs online sein

Yep

Zitat

edit: nach einem coldplug mit anschließendem abziehen und wieder anstecken findet sich in /sys/block/ sdb aber nix in /dev/

beim starten war sda in /dev zu finden

Aus /dev/ verschwindet was ?
Noch nie erlebt , daß udev devices kickt ... kannst aber mit makedev das device erstellen .

********************************************************************************
Ziehe System Sourcen ...
********************************************************************************
1 * wget -nc -P/packages http://switch.dl.sourceforge.net/sourceforge/tcl/tcl8.4.14-src.tar.gz
1 * wget -nc -P/packages http://download-east.oracle.com/berkeley-db/db-4.5.20.tar.gz
1 * wget -nc -P/packages http://www.zlib.net/zlib-1.2.3.tar.gz
1 * wget -nc -P/packages http://www.sethwklein.net/projects/iana-etc/downloads/iana-etc-2.20.tar.bz2
1 * wget -nc -P/packages ftp://invisible-island.net/ncurses/ncurses-5.6.tar.gz
1 * wget -nc -P/packages http://switch.dl.sourceforge.net/sourceforge/flex/flex-2.5.33.tar.bz2
1 * wget -nc -P/packages http://developer.osdl.org/dev/iproute2/download/iproute2-2.6.19-061214.tar.gz
1 * wget -nc -P/packages ftp://ftp.gw.com/mirrors/pub/unix/file/file-4.19.tar.gz
1 * wget -nc -P/packages http://www.bzip.org/1.0.4/bzip2-1.0.4.tar.gz
1 * wget -nc -P/packages http://switch.dl.sourceforge.net/sourceforge/e2fsprogs/e2fsprogs-1.39.tar.gz
1 * wget -nc -P/packages http://procps.sourceforge.net/procps-3.2.7.tar.gz
1 * wget -nc -P/packages http://switch.dl.sourceforge.net/sourceforge/psmisc/psmisc-22.3.tar.gz
1 * wget -nc -P/packages ftp://ftp.cistron.nl/pub/people/miquels/sysvinit/sysvinit-2.86.tar.gz
********************************************************************************

Da haste die Ursache - jede Menge Sourcen nicht gezogen - das so viele Server auf nen Schlag zicken kann ich mir nicht vorstellen .
Ich glaub , du hast n Prob mit der LAN/Inet Verbindung ...

Zitat

andere frage: wenn das herunterladen von einzelnen quellen net klappt (temporary fail oder so) probiert er dass dann nochmal, bzw kann man einen abgebrochen scriptdurchlauf irgendwie wieder aufgreifen?

Im summary Thread noch entdeckt
Derzeit versucht er es mit der Geduld der Standardeinstellungen von wget .
Auf meinem TODO steht ziemlich weit oben die Implementation von allen mir bekannten LFS Mirror .
Entsprechend ne Zeit/Repeat Vorgabe ( durch den User dann natürlich einstellbar ) und spezieller Check des Auspackens der Sourcen mit delete/reload der Sourcen - da hatte bronsky auch schon mal Ärger , daß die Sourcen da aber korrumpiert waren ...

HJS

Zitat

Original von vdrchuck

Ok, habe ich noch nicht gemacht.

Was bei ner frisch formatierten Partition allerdings auch nicht nötig sein sollte .

Zitat

Das mit dem nicht vorhandenen Wiedereinsetzpunkt ist schade, und die CD habe ich nicht als ISO zurückgesichert -> da ich das ISO wie erwähnt direkt in der VMWare als CD-Rom einbinde.

OK - dann kann kein Fehler beim Brennen passiert sein .

Mein Prob ist , daß ich einfach nicht erkennen kann , warum die Scripte bei mir laufen und bei dir nicht und bei m.temp irgendwie auch nicht wirklich .
Potentielle Ursachen , die mir noch einfallen :

VMWare ist ne mögliche Ursache , allerdings ist die Chance die geringste von allen möglichen Ursachen .
Der Kernel der CD hat alle gängigen Module/Treiber die zum Zeitpunkt der Erstellung nicht experimental waren .
Leider enthält die CD die pciutils nicht - du könntest allerdings :
per /.init die addonscripts holen , abbrechen , in /hjslfs/Scripts wechseln und :
./pciutils getsrc
./pciutils build
eintippeln - dann haste lspci
Unbekannte Geräte ?

Eine ( aber auch eher unwahrscheinliche ) Variante wäre auch ein Haken beim Upload .
Da drivehq nur max 50 MB am Stück zuläßt , mußte ich dd bemühen und appenden .
Theoretisch könnte dort was verloren gegangen sein , ohne daß das Iso unbrauchbar wird ... aber eher theoretisch ...

Sonst fällt mir nix mehr ein ...

HJS

Zitat

Original von M.Temp
hi danke für deine geduld

Keine Ursache - Danke für deinen Einsatz

Zitat

ja das hab ich befürchtet. drumm die andere Frage.

ich teste es gerade nochmal mit "testing"

*Daumendrück*

Zitat

ein Vorschlag: wenn er einige sorucen net zeiht/findet, dann könnte er doch gleich abbrechen und net sinnlos zum kompilieren anfangen

Das Handicap ist , daß der Compilerlauf nicht sinnlos ist , wenn er gpm oder nano nicht laden kann ...
Wenns zwingend notwendige Sourcen wie ncurses , shadow oder auch der Kernel selbst sind , dann wäre der Abbruch sinnig .

Die Scripte , die das erkennen , wären aber recht aufwendig - wenn man bedenkt , daß i.d.R. die Sourcen abrufbar sind .

Was um einiges schneller und leichter zu realisieren wäre , ist n sed/grep über die getsrc.log und bei irgendwas anderem als ne 0 am Anfang ne Mes an den User "log checken - abbrechen/mach hinne ?"
So in der Art ...

HJS

Zitat

Original von M.Temp

ich denke da bin ich schuld bzw. mein LAN

ich probier's gerade nochmal - mal schau'n was passiert -bekommst dann ein Feedback

Ächz - und ich hatte schon befürchtet , daß nur Rechner bei hjs auch mit hjslfs laufen

HJS

Zitat

Original von vdrchuck
Ich starte gerade nochmal ein Versuch, ist jetzt aber erst beim gcc --> eigentlich habe ich nichts geändert außer manuell partitioniert und formatiert.
Nee stimmt nicht diesmal habe ich über das Menü die Swappart. inaktiviert --> stand als default immer inaktiv, und bei den vorherigen Versuchen habe ich diese immer aktiviert.

Wenn er denn durchläuft , war das wohl das Prob

Zitat

Des Weiteren ist mir aufgefallen das auf der CD libproc-3.2.7.so fehlt, und somit die Tools top und ps nicht laufen --> ist das so normal ?

Die Lib fehlt - Yep - ist leider kein Feature , sondern ein Bug
In der Jimmi Bondi Edititon (007) wird se drin sein

Zitat

So er hat den "gcc" jetzt ohne den vorherigen Fehler beendet und ist nun an der glibc dran --> sieht auf jedenfalls schon mal besser aus .

Hmm, die einzigste Änderung ist eigentlich nur die inaktive Swap Part., weil beim formatieren (per Scripte) hatte er eigentlich vorher keinen Fehler gemeldet.

Na dann ist ja Land in Sicht - jetzt wäre nur noch interessant , wer der Übeltäter für die Mit-Swap-Will-Ich-Nicht-Kiste ist ...

HJS