macports - gsmartcontrol auf powerbook G4 1.33GHz 12" Aluminium, 768 MB kompilieren, dauert Tage.

[floogy]

Hallo,

kann mir jemand sagen, ob das so zu erwarten ist? libgcc7 und libgcc6 brauchten jeweils 12-24h um kompiliert zu werden.

Ich möchte gsmartcontrol auf einem powerbook G4 1.33GHz 12" Aluminium, 768 MB RAM kompilieren. Es ist Leopard 10.5.8, xcode 3.1.4 und macports 12.6.2 installiert.

Vielleicht weiß auch jemand, was die größten »Brocken« dabei sind. Vielleicht wird es auch besser, wenn man nach gcc6 den Vorgang erneut startet, da der compiler schneller sein könnte?

Die Platte hat ein paar fehlerhafte Sektoren. Wie kann ich herausfinden, ob es an diesen liegen könnte? Wahrscheinlich aber ist der RAM einfach zu knapp?

Welche Alternative außer disk drill free gibt es noch für PPC Leopard?

Kennt jemand ein Universal-Binary von gsmartcontrol für Leopard PPC?

 

[Roman78]

Also um smart auszulesen und zu testen? Da gibt es doch... öööhh wie heißt das noch... Muss ich zuhause mal nachsehen, jedenfalls habe ich da software für PPC.

 

[Olivetti]

für das bisschen G in gsmartcontrol würde ich keinen compiler anwerfen. in jedem dieser smart-gui-tools steckt smartctl, mit dem du alles auslesen kannst. AFAIR gab es vom smartreporter immer eine UB.

 

[oneOeight]

warum kompilierst du nicht einfach nur die smartmontools?
gsmartcontrol ist halt gtk und da braucht es wohl so lange beim kompilieren wegen den ganzen abhängigkeiten.

das abfragen der SMART werte ist auch nicht so schwierig:
smartctl -a /dev/disk0

 

[floogy]

Danke für den Hinweis. Bei Smartreporter 2.7.3 sind wohl die Smartmontools dabei. https://www.corecode.io/smartreporter_lite/index.html
https://web.archive.org/web/20120323131230/https://www.corecode.at/smartreporter/

Mich würde trotzdem interessieren, worauf ihr es zurückführt, dass eine einzelne Library wie libgcc6 schon fast einen Tag benötigt, um zu kompilieren. Es sind ja etliche weitere binaries durch die Abhängigkeiten zu kompilieren (ja, wegen gtk, xorg und weiteres).

smartctl kenne ich von linux und FreeBSD.

 

[oneOeight]

gcc ist halt recht umfangreich, die CPU ist nicht die schnellste, die platte lahm.
das dauert halt, selbst auf meinen dual g4 zieht sich das ewig.

 

[Kaito]

Ich weiß noch als ich gcc auf einem Intel Core2(?)Duo MBP kompilieren durfte, da ich gnat brauchte. Configure + kompilieren hab ich nachts durchlaufen lassen (müssen), bis es irgendwann so durch lief wie gewünscht...

 

[floogy]

Ich habe halt auch schon mal auf einem Pentium 3 667MHz mit 2GB RAM unter Linux den Kernel gebaut. Das lief afair schneller. Mag aber sein, dass mir die Erinnerung einen Streich spielt. Mag mit mehr RAM und SWAP auf einer HDD ohne >78 reallocated blocks besser laufen. Obwohl: Die CPU läuft ja auf 100% Auslastung ...

Werde die defekte HDD (Smart Status ist zwar OK, aber wenn ich ein ppc Linux oder BSD von cdrom starte, gibt es jede Menge DMA Fehler und der Kernel versucht ständig Leseversuche die scheitern) durch eine SSD austauschen und vielleicht auch mehr RAM einbauen.

Jedenfalls Danke an alle!

 

[Olivetti]

eine SSD bringt diesbzgl. gar nichts (ansonsten natürlich schon).
ich habe auf einem alten macbook core2duo u.a. brew als pkg-manager und mich graust's jedesmal, wenn rust fällig ist.

 

[floogy]

Ich wollte die Platte per smart im Auge behalten, bis ich dazu komme sie durch eine SSD zu tauschen. Das mache ich nun mit SMARTreporter-lite. disk drill finde ich etwas "kompliziert", obwohl die Temperaturanzeige praktisch ist.

 

[oneOeight]

wenn du schon schon über 78 reallocated hast und bestimmt noch einige pending, was willst da noch im auge behalten.
tausch die platte.
auch wenn das vielleicht für ein wenig benutztes gerät auch eine teure investition ist.

 

[floogy]

Das ist, wie gesagt auch geplant, per Sata2ide Adapter und SSD. Ich dachte ja auch ursprünglich, dass sei eine Sache von Minuten bis Stunden. Ich hatte merkwürdigerweise SMARTreporter vorher nicht für PPC gefunden.

Hier ein dmesg-Ausschnitt zum Start von lubuntu, als die Platte noch einigermaßen okay war, und als es schon massiv Probleme gab. Mac Os X Leopard started aber einigermaßen zügig, ohne diese Probleme, wohl weil bei der HFS+ Formattierung diese badsectors berücksichtigt wurden(?).

https://pastebin.com/qDehgQ6V


Mi 4 Mär 2020 13:32:08 CET
13:32 up 1 day, 10 hrs, 3 users, load averages: 1,13 1,10 1,08

 

[oneOeight]

Hier ein dmesg-Ausschnitt zum Start von lubuntu, als die Platte noch einigermaßen okay war, und als es schon massiv Probleme gab. Mac Os X Leopard started aber einigermaßen zügig, ohne diese Probleme, wohl weil bei der HFS+ Formattierung diese badsectors berücksichtigt wurden(?).

das liegt einfach in anderen bereichen, HFS+ hat da kein spezielles bad block mapping so weit ich weiß.
wenn du aber schon I/O error bekommst, dann solltest du deine pläne mal beschleunigen, falls du das gerät in kürze öfters verwenden willst.

 

[Roman78]

Ah, ich habe mal geschaut und was gefunden... DiskWarrior und Norton Utilities hat Festplatten tools.

 

[floogy]

Norton Utilities dachte ich auch. Die Norton System Works 3.0.1 gingen aber nicht, vielleicht laufen die nur unter Tiger 10.4.
Vielleicht gut, dass die gar nicht erst liefen: https://www.cnet.com/news/warning-d...r-similar-utilities-on-mac-os-x-10-5-leopard/

Danke auch für den Tipp mit DiskWarrior. Werde ich mir mal ansehen.

Gerade wird gcc7 kompiliert. Bin mal gespannt wie es nach dem Brocken weiter geht. Die Programme und Bibliotheken dazwischen gingen relativ schnell.

Ich werde aber morgen mal nach einer SSD und den Adapter schauen. Es sind keine persönlichen Daten auf der Festplatte. Ich bin da nur am Testen und ausprobieren.

Solche Fehler kamen nur bei den Live- oder Recovery Linux CDs etc.

Leopard hat sich nie über die Platte beschwert. Kann also gut sein, dass da zufällig gar nicht die Blöcke genutzt werden. DiskUtil allerdings scheitert an dem Check und der Reparatur (bzw. es bleiben Fehler nach erfolgreicher Reparatur: Loop).

 

[Shetty]

Ich habe am Freitag (27.02.) ein "sudo port upgrade outdated" auf dem iBook gestartet. Seit gestern oder so kompiliert es immerhin schon gcc7... also ich gehe davon aus dass das normal ist.