Newsgroup: it.comp.retrocomputing
Titolo: iBook e Linux

Mentre goccia a goccia sembra arrivare OSX 10.3 (il torrente è in 
magra :P ) ho provato Crux PPC, con risultati non proprio eccelsi.
Dopo un'ora di smanettamenti (
http://www.cruxppc.org/Main/Handbook2-6
), 
preparazione delle partizioni disco (quella speciale di boot da 800k, 
quella per /, quella di swap), di chroot e mount vari, siamo arrivati 
alla compilazione del kernel.
Bene, anzi male... la compilazione fallisce :(
Rovisto fra il codice e trovo una variabile locale (un buffer) di 1024 
bytes, che, unita alle altre variabili, supera il limite per lo stack.
Risolviamo il problema, ricompiliamo, prepariamo yaboot, fstab, 
riavviamo... crash del kernel.
Rimettiamo il CD di Crux, ripartiamo, mount, chroot ..., controlliamo i 
parametri, ricompiliamo, riaggiorniamo, reboot ... crash ...
Erano le 2:30. Tralascio il poco edificante commento, del tipo "si vada 
ad intrattenere nell'altrui posteriore" :(
Intanto OSX è all'83%, anche se arriverà sotto forma di dmg, e mi 
toccherà o convertirlo in ISO, od importarlo in un Mac...

 e mi  toccherà o convertirlo in ISO, od importarlo in un Mac...
"massivan"
Format Factory lo può fare? 

>>>>  
http://www.bb2002.it
 :)  <<<<<
........... [ al lavoro ] ...........

 ma non è solo per roba audio/video?
"massivan"
Si, infatti ho dato un'occhiata
ora ed è solo per estensioni
photo/audio/video. Ho aggiornato
alla versione 2.5. 

 ad intrattenere nell'altrui posteriore" :(
ma hai provato con gli stumenti giusti? ad esempio con Slackintosh,
ma attenzione..  ubuntu sta a debin come debian sta a slackware, in termini 
di approccio novizio..

 di approccio novizio..
Stiamo parlando Crux-PPC.
La compilazione falliva a causa di un buffer allocato nello stack di 1024 
bytes.
Era riferito ad un file di log, niente di essenziale.
Risolto (almeno sembra) il problema, la compilazione ha successo.
Installato il kernel in /boot/zImage, creato per sicurezza anche un link 
simbolico nella root, vmlinux -> /boot/zImage (yabooot ha dato parecchi 
problemi, continuando a cercare vmlinux nella root, nonostante il file di 
configurazione puntasse a /boot/zImage).
Al riavvio, carica il kernel, quattro righe senza messaggi d'errore e più 
nulla. Congelato. Frozen ! 

 nulla. Congelato. Frozen !
in questi casi sarebbe interessante vedere il config del kernel di launch 
make e uno di quello compilato.
oltre che i classici lspci lsscsi, oltre che capire quali moduli hai incluso 
nella initrd di cui non fai riferimento. 

 incluso nella initrd di cui non fai riferimento.
Ho provato due diversi config preconfezionati, dopo aver eseguito
make menuconfig, pensando che andassero bene.
Nessuno dei due ha dato risultati positivi.
Cito a memoria, perché ora ho installato Mac OSX Panther.
La quarta ed ultima riga, conteneva la parola "quiesce", colore di sfondo 
grigio. A questo punto, il kernel del CD di installazione cancella lo 
schermo, ed iniziano i messaggi di boot, su sfondo nero.
Con il kernel compilato, invece, niente schermo nero, si rimane su quello 
grigio.
Mi sarei aspettato qualche messaggio d'errore in fase di boot, ma a quel 
punto non ci si arriva proprio ...

questo (su win):
http://www.crystalidea.com/dmg-to-iso-converter-convert-dmg-to-iso
o questo (su linux):
http://www.acetoneteam.org/
P.S. mai provati personalmente, una volta l'ho fatto ma non ricordo né
il tool né la piattaforma...

> "mr"



"massivan"
Grazie, ho scaricato quello per Win.

Lato Linux ho trovato comodissimo dmg2img ...

 riavviamo... crash del kernel.
puoi spiegarti meglio riguardo questo problema? Sarebbe utile che tu
lo comunicassi agli sviluppatori.

 Cito a memoria, perché ora ho installato Mac OSX Panther.
non so.. ma se ci torni a giocarci nopasta il .config da qualche parte.
con annessi dmesg filesystem cpuinfo etc etc.. magari qualcosa salta fuori. 

Il file lo ricordo ... 
setup.c
Dove esattamente no.
Aveva a che fare con i log, secondo i commenti inseriti.
Se ho un po' di tempo libero (quando la spalla si risistema) smonto l'HD 
dell'iBook, ne faccio un'immagine e riprovo CruxPPC.

 setup.c
cmq è strano che abbiano definito un char array piuttosto che un buffer, 
direttamente con malloc, grepperò nel directory dei sorci, grazie per la 
segnalazione. 



Considera che il nome può non essere buf[1024] ma altronome[1024], che 
sommato a 16 bytes di variabili varie totalizzava 1040, segnalatomi da 
gcc.
È uno dei primissimi files ad esser compilato.
Anch'io mi sono stupito che la compilazione del kernel fallisse e per 
l'uso di una variabile automatica così grande.
La tentazione che ho avuto è stata, poi, quella di utilizzare il kernel 
del CD di installazione, visto che quasi tutto funzionava, rete compresa.
Poi è arrivato il Panther ed ho deciso di sperimentare Mac OSX, che 
conosco poco.
Mi riservo, come detto, di riprovare con un pochino di calma.

 l'uso di una variabile automatica cosě grande.
ma infatti, volevo capire cosa stoppasse la compilazione, sono dell'idea, 
che quel qualcosa, riguarda la distribuzione piuttosto che il k., voglio 
dire, ppc č la terza platform dopo x86 e arm, ciň sta a significare che 
viene compilato migliaia di volte.. ragion per cui mi sento di escludere il 
k. (ma volevo appunto averne la conferma).
ciao. 

Un consiglio, già che ci siamo.
Ho trovato altre distro per PPC: so che la domanda è difficile, ma hai 
un'esperienza ed una preferenza ?
Ho sia macchine Apple che IBM con processori PPC.
Per il momento montano tutte OSes originali (Mac OS ed AIX), e non mi 
dispiacerebbe provare Linux.

 un'esperienza ed una preferenza ?
http://www.imageno.com/o6iqul86qhvqpic.html
ovvero, l'unico linux che vale la _pena_ di usare .. Slackware :)
(imho).

anche perché spesso e volentieri Darwin -> 
http://www.imageno.com/6eyam0igr1espic.html
 


secondo me ti sei semplicemente dimenticato di compilare builtin il
modulo della tua scheda video.
Infatti se il bootkernel della iso funziona credo che l'inghippo sia
dovuto ad una semplice dimenticanza o errore da parte tua.
dal CRUX PPC Handbook:
"Useful kernel config files are placed into the /usr/src directory.
They are the config files used to build the boot kernels. "
Ti consiglio di usare quello e poi piano piano ripulirlo. Io uso CRUX
PPC (e CRUX) da molto tempo e mi sono sempre trovato discretamente
bene.
saluti,
Nello

On 9 Ott, 02:15, "Corrado Roberto"

ah, ma Slackintosh e' ancora sviluppata? Pensavo fosse in semi
abbandono .



Ed i config built-in ho usato :(
Francamente non ho controllato uno ad uno i moduli, visto che c'era 
l'indicazione "used to build the boot kernels".
In tal caso, mia la leggerezza di non controllare, e loro la 
dimenticanza :P
L'altra possibilità è che, avendo utilizzato l'ultima stable release, non 
fosse poi così stable ;)

 fosse poi così stable ;)
mmh, e questo e' male :D ma non impossibile ahahahha



Ora si rischia di scatenare una guerra di religione tra i vari fan
delle varie distro.
uso (usavo) linux su architettura powerpc da svariati anni, ho iniziato
a rompermi le corna 10 anni fa' su un rs6k 7248 (che al epoca non era
esattamente ben supportato), me le sono passate un po' tutte.
Se hai tempo da perdere prendine uno a caso dal mucchio, se vuoi qualcosa
che sia aggiornato e con una buona base di pacchetti disponibili non ci
sono molte alternative a debian, ci sarebbe fedora al limite ma la vedo
meglio su roba enterprise piuttosto che sul ibook
slackintosh e' nata morta ed e' svariate release indietro, e lo dico
da utente di vecchia data di slackware, crux ppx ha una serie di glitch
e rogne varie, c'e' gentoo se vuoi passare il resto della vita a compilare
oppure la "storica" (su ppc eh) yellow dog linux che da qualche release
pero' e' puntata piu ai sistemi recenti (e quindi spesso e volentieri
c'e' qualche problema con i kernel che non includono supporto per hw dei
vecchi powermac etc), ci sarebbe ubuntu per ppc, porting non piu 
ufficiale, l'ultimo giro era funzionante ma non ci farei troppo 
affidamento per hw datato.
Scegli in base alle tue preferenze, io ho deciso che linux basta e 
avanza su x86, su altre piattaforma ho la possibilita' di usare os
diversi (e piu' interessanti) e la sfrutto, a parte i vecchi powermac
dato che non sopporto macos classic, e quindi rimangono con linux o
netbsd (oddio, avevo anche fedora su un rs6k 9114 power4 insieme ad 
aix 6.1, ma la beta di aix 7.1 ha scacciato fedora dal secondo disco)
p.s, se hai la rage 128 sul ibook attenzione che il relativo driver
di xorg e' rotto da tempo (e su alcune distro non e' nemmeno piu
incluso), su x86 funzion(icchi)a, su ppc e' un po' un dramma.
-- 
member of the italian hobbyist DECnet network - 
decnet.ipv7.net
www.unsupported.info
 - 
img.unixantichrist.net



Ho problemi con le Ati ed Ubuntu su molti x86 ... non aggiorno più quel 
settore quando ci sono le novità ... altrimenti schermo nero :)
Detto fra noi, preferisco anch'io archiviare le macchine con il loro 
sistema originale. Avendo tempo, una prova si può anche fare ;)

Mac OS classic, per quel poco che l'ho usato nell'ultimo mese, non m'è 
dispiaciuto, se lo rapportiamo agli anni, al tipo di macchine ed 
all'utilizzo per cui era pensato.
Cero, soffro la mancanza di una console caratteri (*enormemente*), una 
certa "chiusura" del sistema e l'utilizzo preponderante del mouse.

 originale. Avendo tempo, una prova si può anche fare ;)
Le ati sono diventate un vero dramma da svariato tempo, specie con
le schede che usano chip piu recenti del r300 (quindi fondamentalmente
tutto cio che e' successivo alle radeon 9800 e simili), ci sono bug
che si rincorrono da tempo, alcuni mai fixati, altri che ritornano
e in generale noto una scarsa attensione nel testare le modifiche
e le nuove feature introdotto nei driver, ad esempio molti problemi
sulle mobility dei laptop si verificano solo a risoluzioni piu
elevate della classica 1024x768 o 1280x800, chi come me ha un 
laptop con schermo sxga+ (1400x1050) bestemmia spesso e volentieri.
Recentemente ho perso qualche mese (e qualche anno di vita) dietro
un bug non segnalato da nessuna parte (di cui pero' gli sviluppatori
erano coscienti) relativo alla mobility x1300 (r500) in cui usando
xvideo oltre una certa risoluzione (o full screen sul 1400x1050) si 
evidenziavano una serie di righe verticali e altri disturbi sul
video, alla fine e' risultato essere un problema con la gestione del
bicubic filtering da parte del r500, alla fine la soluzione e'
disabilitarlo (con xvattr), tant'e che negli ultimissimi driver e'
stato disabilitato di default per tutti i chip r400 e r500 based.
Potrei portare svariati esempi (supportati da vari bug report
tutt'ora aperti) ma non e' la sede adatta (ne ha una qualche
utilita' farlo), non parlo poi dei driver propietari ati visto
che ci sarebbe da mettersi le mani nei capelli .. 


 affidamento per hw datato.
yd è una distro da playstations :°D
in merito a slackintosh, chi la usa (come il sottoscritto) non ha bisogno di 
pkg precompilati da terzi, basta attingere dalla distro ufficiale e 
compilare secondo l'archittettura, e ciò vale anche in ambito arm, vedi 
slackedarm. 

 l'archittettura, e ciò vale anche in ambito arm, vedi slackedarm.
Si vabbe, finche e' su un paio di sistemi che si usano per giocare
e sperimentare si puo' anche fare, quando magari si parla di roba
di produzione da gestire insieme ad altri N sistemi diventa un po'
time consuming la cosa, ma come dicevo, questione di preferenze
personali, finche parliamo di riportare in vita un vecchio ibook
alla fine va' bene praticamente tutto.
Direi che siamo decisamente OT, non vorrei finire in una
discussione piu o meno allegra e simpatica sulle differenze tra 
le varie distribuzioni.
(anche perche se propio volessi infilarmi in qualche discussione
si potrebbe parlare di una serie di problemi che vanno al di la'
delle distribuzioni, vedasi kernel, xorg, etc, che stanno evidenziando
un discreto calo nella qualita' del codice e soprattuto una certa 
faciloneria nel eccitarsi per l'ultimissima feature da integrare prima di 
subito nel mainstream senza adeguato testing e senza curarsi di bug 
critici esistenti da mesi se non anni)


 alla fine va' bene praticamente tutto.
mah, sono dell'idea che un sysadmin rispettoso della propria
professione, non si azzardi ad installare il primo pkg scaricato
precompilato dal repository della propria distrubuzione, ma besì
pianificherebbe e studierebbe il relativo configure, nei minimi
dettagli, per poi compilare, testare, e solo successivamente
applicare il pkg cosi generato alla produzione, seguendo questa
ottica, la filosofia Slackware, a cui facevo riferimento prima,
rientra nei termini della corretta filosofia di amministrazione, in
altri termini mi guarderei bene di colui il quale, preso alle
strette, opterebbe per qualcosa di semplice già pronto secondo una
metrica generalizzata e quindi adattata al caso.
Cordiali saluti
Corrado Roberto
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.6 OE plugin - Corrado Roberto
iQIVAwUBTLCxBrU57c/jaGFOAQL4KxAAvl5ftP8F/fYSEoMcdqxUUVp9V7gdmf6k
j+tWTUxJvhDW7oV8lqhuvKflqydkfJZ4ezoYG2UHfxLRn6OwMIY24XOqFRqcqR4h
xexAAE7WM4ALXhQSr1Bth2pcvQXE+SsxWf7Q1WVGdSpE6tu6LXdzGud3SktspxFn
upLnG2CGkEH2w/sehnhmNmSgtRQ9fCnjtSyuFDeTUMTaNdeN+o+rPCn7BuSIg37O
hbT9+Ggb6eVM2v6TpWaUGXyGJ7dE6jX1fjep9vfVmci2eaOvn/oHCajopinVsZbC
lYNr+mK1e00KTAi+8SAaHytpPro9xkmvncvcP6I944+W8ueenYGNo0mDj7hcERJM
j5UTdB/cSZwm6IoeLapb7jXzyxOkKjkUA0Hmt1KcXOSCsbJO1rYGk8CvyHw6e5oZ
OF6TRbFW8t7qjSBFcSzFZr4PZHoggJjNbHHteEPwpQGPPPyOEsNhYPdgTu6uHs5y
8XlVuH2DLVW/tL9jRKFZ3czTZEDatsaXPBdtrMO2l4Gl4CGSa2MY8vuSkik318f4
eO6TWqR860vyVRboYao5JJ2YdK05OS9VuTpD1uqaL+W2LJEd/FgKs4VjTjbnIiW4
GTbqgq+vtD9zcMW0xqmVNaBaKfsq8eLkCScj0fEeD6jmNAOJKfBdvWsifhiEv27a
r17q4BSyu38=
=/L9u
-----END PGP SIGNATURE-----

 quindi adattata al caso.
fortuna che ci sei tu che verifichi ogni singola riga di codice di
cio che hai sotto mano .. 
fa' sempre figo eh, scusa pero' se non mi leggo tutte le volte i
sorgenti di un apache prima di aggiornarlo o installarlo, e se mi
fido ragionevolmente di un pacchetto ufficiale di una debian
stable, che non implica non avere un sistema di staging su cui
testare le modifiche per evitare problemi
(certo se poi non e' apache ma il programmello misconosciuto
scritto da pincopallo il sorgente me lo spizzo ogni singola volta, 
ma in certi ambienti il programmello misconosciuto e' meglio
evitarlo propio)
direi di chiudere sta discussione prima che arrivi qualcuno ancora
piu' figo dicendo che lui scrive personalmente ogni singolo applicativo
per avere totale controllo ..
saro' sicuramente un sysadmin mediocre, fortuna che lavoro per
la concorrenza (solaris, aix, tru64, hp-ux), i sistemi con linux
impereranno presto gia che tutti gli altri li gestiamo noi poveri
incompetenti.
oh prima di chiudere giusto per curiosita', di quanti sistemi parliamo ?
no perche a "noi" (per generalizzare) toccano attivita' (spot o meno)
su un numero di macchine che varia, ma spesso si parla di 40/50 sistemi
a salire (anche di molto, si fa' presto ad avere sotto un ced con piu
di 200 sistemi che anzi e' ancora piccolino)
quando ero giovane e avevo dieci macchine sott'occhio era anche fattibile
(forse perche era l'unica soluzione, non e' che ci fossero tutti sti
precompilati ufficiali per sco openserver 5.0.5)


 per avere totale controllo ..
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.6 OE plugin - Corrado Roberto
iQIVAwUBTLDFd7U57c/jaGFOAQL0ExAAlrHjBRMdaEqg3K0/TML9Sih283mssGU0
9E3VRg/bNnod5RugKZ+4UoxMA6px4xozPl+saeLDVKLjDrn/iCCiH+hE8BBiF56Y
fuq94VWqTUy223+9rTffSuN0oHavFBnPIHDZERz1hhl8Qq2ukdgLGcD+60z9KfG0
cNkopfGVSy2L7eSXuXdQ5NlV7bbG2+ezrtNHxdy6KFRRD9mE2Z+J0ul+CdrNY56Q
NGi2J2QXoA1wS5J1HPduGOGvobRTeEk523/r6VaeXXPiUAlBCnGcWURID5gO5Acd
uP/MMA864RjD84pq774Ci2MVHFHPVUgo1JMrUYHddDGxoAnZE2+xbyV5o/t6WuCJ
Vz9CxaZBgsqHdn6mN2mwjtC5NleDLNviGDdBvMVYGLAedSV6YLZLUnnIQW+abahq
EM8GpS15CAkFpYb3GXLJUYv4eamWexar4uCAGvnbEqrqPvLzSa4YbHT5bgk94g1X
Ec60XuRmYokUPgW56vC7kphfvuZXfzhmbVI70qKkYJQt9gc3E2RZNu4t/V2GW2Kq
NZwBqEJdR74Mr24fnx+SciyBHk2puf1JtSR2ZKNpDCpfU7g6gWDgkyKvmYv+9U+O
ix73Fs83UmizuW0NdFOAkDohijD72YJiVphqCrOY3JQjISp/4wJDS5NerY1Ll6k3
clEbqoBU5g8=
=aUEL
-----END PGP SIGNATURE-----

Fatemi dire l'ultima parola ... :)
Quando ho chiesto un parere sulle distribuzioni era perché volevo sapere 
se qualcuno avesse un'esperienza diretta... non solo "prediligo 
Slackintosh" oppure "è meglio PenguinPPC" ma "ho installato xxxx su un 
iBook con questi risultati ...".
Su un iBook, nato con Mac OS, OSX 10.3 s'è rivelato più che decente. Non 
è una macchina da "produzione" né tantomeno server o workstation.
Pur prediligendo Unix e Linux, l'OSX m'è sembrato più maturo e più 
rispondente allo scopo: sistemare una quasi-retromacchina.
Poi, le distribuzioni sono una faccenda di gusti personali.
Non avendo esigenze produttive, le distro me le provo in macchina 
virtuale, confinando tutti i possibili "danni".
Pace e bene ! :)

 confinando tutti i possibili "danni".
Meglio di cosi ..


 Pace e bene ! :)
print <<<eof 

 che in linux _nulla_ deve essere lasciato al caso.
eggia, tipo aspettarsi che funzioni semplicemente nelle situazioni in
cui dovrebbe semplicemente, appunto, funzionare
mah .. ce mancava l'avvocato difensore di linux 


 mah .. ce mancava l'avvocato difensore di linux
non andare fori tema con le provocazioni... io non le seguo. 

 
È un post ironico, vi avverto ! Non prendetelo sul serio !
Diciamo che:
1) non ti aspetti un errore durante la compilazione del kernel, dovuto ad 
un problema (seppur sciocco) di programmazione, in fase d'installazione. 
E sono uno che compila molto... e l'utente della strada che volesse 
provare CruxPPC ? Giustamente, è escluso a priori, non si lascia nulla al 
caso :) LOL !
2) non ti aspetti di dover installarlo tenendo acceso un secondo PC per 
consultare la guida all'installazione (che è pure non proprio precisa ...)
3) non ti aspetti che si blocchi al riavvio, avendo usato i config in 
dotazione. Ma è il bello dell'avventura !
4) Quando ho provato Debian per Sparc, mi sono imbattuto in un kernel bug 
(fra l'altro documentato) per le SS5 (CPU soft lockup).
E va bene, sono sfortunato ;P
La maggioranza delle mie macchine è Linux/LAMP, sono un suo fautore ma 
non vedo perché non si possa esser critici.

 lascia nulla al caso :) LOL !
HAHAHAH :) beh del resto anche il problema che esponevo io ...
Comunque crux-ppc e' una distro piuttosto giovane, qualche problema ci 
sta', magari se dettagli meglio il problema puoi aprire un bug report
e nel caso la prossima volta in cui incrocio nullpointer (hint, sito
di cruxppc, about, primo nome del team) gli pesto un piede :)
(non per nulla stavo provando crux-ppc tempo fa' ..)
per quanto riguarda debian su sparc, purtroppo da tempo il port
sparc32 del kernel non e' piu mantenuto, dalle ultime release del
2.4 la situazione e' andata sempre piu degradando, smp non funzionante, 
problemi con la gestione delle seriali (e la console nel 90% la hai li)
e tutta una serie di altre rogne, col 2.6 non e' migliorata la cosa, 
e alla fine anche debian ha deciso di droppare il port.
In queste situazioni c'e' poco da fare .. "ritenta e sarai piu fortunato"
prova una release diversa del kernel se propio vuoi linux .. 



ahaha, questo me lo ricordo bene.. ehm, fu tutto "merito" mio...
Non essendo un progetto ricco non hanno tutte le macchine per fare i
test ed i ragazzi non rientrano
neanche nella categoria "collezionisti" quindi mi era stato chiesto di
testare il bootkernel proprio su un mio vecchio catorcio (dove avevo
tempo addietro scoperto che i driver firewire PCLynx freezavano il
kernel)... ecco riassumiamo dicendo che in quell'afoso mese di giugno
avevo di meglio da fare! Poi ricordo che fu fatta una nuova build, la
2.5a, corretta.
Ammetto che lo scatafascio, soprattutto in ambito powerpc, e colpa di
chi come me non testa le varie release candidate e si annoia anche di
riportare eventuali bugs, lo ammetto io mi sto mbutizzando ovvero se
una cosa non funziona dico che fa cagare ed aspetto la prossima
versione.
nello
--
Apple PowerPC32/64, Genesi Efika MPC5200B, IBM 9114-275 tutti con CRUX
PPC

 dotazione. Ma è il bello dell'avventura !
infatti questo e' davvero strano e meriterebbe un bug report

Cerchiamo d'esser precisi ...
I due config usati, in ordine:
1) linux-2.6.32.3.config
2) linux-2.6.32.3-Chrp32.config
Gli altri erano Efika, Pegasos, Sam.
Di files setup.c che ce sono oltre venti (ho controllato nella iso), 
tutti platform-dependent.
Un setup.c contiene char log[1024], ma non sono sicuro fosse quello.
Il messaggio in fase di compilazione del kernel era inequivocabile:
... omissis ...
in setup.c
Sospendiamo qui: appena ho tempo riprovo sull'iBook, ma devo prima far 
l'immagine disco, non ho vogli di reinstallare OSX e tutta la 
configurazione accessoria:(

 cosa non funziona dico che fa cagare ed aspetto la prossima versione.
Dopo svariate peripezie con l'ultima moda di infilare feature senza 
testarle che si sta' generalizzando per un sacco di cose nel mondo open 
(kernel, xorg, altri mille mila cazzi) ho la consapevolezza che fara'
cagare e che non funzionera' a priori, non resto mai deluso :)
Tanto per restare OT, qualche problema particolare da segnalare
sul 9114-275 ? c'ho ficcato un terzo disco (oltre ai due con
aix 6.1 e 7.1) e sarei tentato di provare crux-ppc li .. 
(vedo in firma che ne hai appunto uno) 



ah, quindi e' una questione del kernel linux vanilla.
Cmq io giusto per prova mi sono riscaricato la iso ed ho preso sia il
kernel che il config e qui ha compilato senza problemi... che ci sia
stato qualche errore non segnalato durante lo scompattamento del
kernel?
Imho ti conviene prendere il kernel gia' compilato (ed i moduli)
direttamente dall'iso per fare prima... poi ti scarichi un kernel piu'
nuovo e te lo compili secondo i tuoi bisogni.
Quello chrp non e' per le macchine apple e cmq non credo funzioni
manco sugli ibm rs6000 604e/604ev/604r perche' i ragazzi di cruxppc
non hanno hw sul quale testare quindi dalla prossima release lo
elimineranno. Hanno avuto tante promesse di donazione ma poi nada..


si, funziona benone su quella macchina. Solo ricordati di applicare la
patch inclusa (accrocchio fatto in casa cruxppc) se vuoi usare
una gxt4000 o 65000.

report
il setup.c esiste lo trovi dentro alla /linux{uname
- -r}/arch/{plataform_directory}/platforms/{arch_type_directory}
il char array cosi come riportato non è un bug, perché 1024 è un
valore arbitrario generalizzato che può benissimo essere esteso a
1040 se non a 1048, è compito del launch conf instanziare detta
variabile in funzione della arch di destinazione, con il relativo
valore che cmq non è superiore al 1024..
come già detto ribadisco che il problema sta altrove.
Cordiali saluti
Corrado Roberto
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.6 OE plugin - Corrado Roberto
iQIVAwUBTLHEqbU57c/jaGFOAQJ4DA//czCDoPIGViAoT452brFkHsaOAjvL0XkP
jo2gLpV8sRgBFbPsyBZROdzVbnRl1fJL4XRqGquHuPXC/Cv7UXMzwPTVzZMwgmHe
JnwtijS1ipAXFmVeC4pV0AjouGcHO4h4LAxeBkck5dDdhmVww+Zad6G6thsPYPpv
fwcUO8fZqtB+sT+z0GGYOzls8yDkkE65PX4Zg26ByVVdXJmntU0KvMCjVTFc8PWC
3H8yq+c1xwZtebWFdTFvFOdQWdz+cw8tBXnkyOL+ruibYrMpaAYqGa7tJBfgYZnW
iZp8gKWC/HdwKAmLmX8eCQ9r6cjH8IItrw22r84fHsK76QA85r6kVWIyVRrtZp+n
6OL/JmpxRsNGJ5QvwELppz9xQMWSAFn93iwvT9rdNbDHJA5RCHejtI4t3JxB/euI
uGXuqVxhcG/88vqKkUziHdoyj8AF9Wb4pQPCLcePFLRSzzcNFvQYqAflFFFD8o0q
IxpfO23le8nq5WanxcfUIy/Arytd8qpH2AskAmVpnmO1MhDgcqXv7uXanMdm/5Xi
2OgUSbPk1Wr7Gd5kjCZkZR0L5XSzjDdYHUyOQqeFdGulTq5hWIPoaqUo9fyeXTRq
JmD0JWf2WRHG36hJdgX4SSjOK6TpGaCtY5wUGyHVsfxDuOoGcVdECz42Ira6W65G
3XfuqTQuEBs=
=zpkq
-----END PGP SIGNATURE-----

e poi basta solo documentarsi un po sugli argomenti di compilazione di detta 
arch.
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/arch/powerpc/Kconfig.debug
http://patchwork.ozlabs.org/patch/28385/
arch/powerpc/platforms/chrp/setup.c:378: error: the frame size of 1040 bytes 
is larger than 1024 bytes



La mia patch è stata quella di ridurre 1024 a 1000 ed, ovviamente, 
aggiornare corrispondentemente il codice in chrp_event_scan.
Non so se il valore 1024 fosse "mandatory".


vabbe' visto che se ne parla...
quello un bug noto e che colpisce solo quando c'e':
CONFIG_PPC_CHRP=y
che tra l'altro non serve per compilare il kernel per macchine apple.
Tale problema fu segnalato a BenH dai ragazzi di cruxppc...
btw, fu scelto di non correggerlo visto che non era un problema reale
e di bypassarlo con:
CONFIG_PPC_DISABLE_WERROR=y


si, lo so ma si continuava a parlare erroneamente di un baco di
cruxppc e non del kernel linux.

CONFIG_PPC_DISABLE_WERROR=y
ecco ecco, questa risposta mi sembra molto sensata++ ^^
ciň dimostra quanto sia fondamentale conoscere il configure di ciň che si va 
a compilare.