miklos ha scritto:xen come prodotto lo conosco giusto il minimo indispensabile
pero' da quel che capisco io linode usa la modalità paravirtualizzata e non in emulazione hardware (modello virtualbox). insomma nell'immagine che mettono a disposizione il kernel non c'e' perchè non viene utilizzato.. viene utilizzato quello messo a disposizione dall'hypervisor.
riprova ne è che non ho ne' un bootloader ne' i pacchetti del kernel. pero' puo' darsi che nn c'abbia capito un tubo
Anche io lo conosco giusto un minimo. Il sistema di virtualizzazione in cui la macchina guest usa il kernel della macchina host è openvz (che è un chroot avanzato, in cui hai un minimo di gestione della /proc, ma il kernel a cui fai le richieste dirette è quello con cui è stato bootato l'host).
In xen ci sono due kernel; uno è quello dell'hypervisor e uno della macchina guest, che non necessariamente devono coincidere; l'importante è che quello della macchina guest abbia al suo interno compilato il supporto per xen, e i due kernel comunicano tra di loro.
Il bootloader c'è, ma risiede sull'hypervisor. Evidentemente in linode il bootloader punta ad una immagine del anch'essa kernel presente sull'hosting. In Tophost invece risiedono sull'hypervisor gli stage di grub, ma il menu.lst e i dischi a cui punta sono quelli della macchina guest, quindi ho controllo completo, anche se diventa un'arma a doppio taglio.
Infatti tu hai kernel compilati, testati e certificati da loro, e se la macchina non ti parte è perchè hai fatto casini con init.
Io posso compilarmi un kernel customizzato, ma se faccio un errore e la macchina non mi parte sto fregato (anche perchè la modalità 'boot da cd' non esiste).
La console che ho a disposizione io è un'applet java (un vnc client) che mi simula il monitor (con tanto di framebuffer; quando bootto vedo i pinguini
)..
io alla fine ipotizzo un qualche bug strano legato a gcc/glib che magari genera binari non compatibili con chissa quale set di istruzioni mancante della cpu in questione. bug che evidentemente è stato fixato con le nuove versioni (da qui la current)
non c'è altra soluzione. Forse dovresti segnalare la cosa su linuxquestions. Ho notato che le glibc sono compilate con il flag "-O3" che mi sembra di capire che ha tanti feedback negativi.
pero' la mia domanda è... esiste un modo per poter vedere qualcosa di piu' del laconico "illegal instruction?!?!?!"..
beh, fondamentalmente tu hai fatto una istruzione illegale
. che vuoi che ti dica? anzi che non panica! "illegal instruction" lo dice il processore al kernel; il kernel non fa altro che dirtelo a te. Windows ti direbbe "questo programma ha eseguito una istruzione illegale e sarà chiuso" (mi è successo), non è che è molto più chiaro.
in effetti.. ma penso che il gioco nn valga la candela sopratutto perchè non ho un gran banda internet.. con linode puoi crearti un sistema in virtualbox eppoi trasferirlo tramite ssh+dd (percio' teoricamente puoi installare una qualsiasi distribuzione linux).. quindi magari potrei provare a installare una 14.0 in locale.. trasferirla e vedere che succede.. ma ripeto non so se mi imbarchero' in quest'impresa..
Se è un problema di compatibilità con il processore, installare su virtualbox e portarla su xen non dovrebbe risolvere.
Io ho fatto l'installazione in chroot, l'ho testata e poi l'ho sostituita a quella originale. Ormai è una pratica che faccio spesso.
Fai questo lavoro.. prendi l'installer della 14.0 (initrd.img) e scompattalo in una directory. Questa dovrebbe usare le glibc della 14.0 (ovviamente). Entraci in chroot e vedi se da lo stesso messaggio.
Ho fatto una
guida qualche anno fa; è un po' vecchiotta ma molte cose sono ancora valide.
Codice: Seleziona tutto
# mkdir -p /SLACK/INSTALL ; cd /SLACK/INSTALL
# gzip -cd /SLACK/INSTALL/isolinux/initrd.img|cpio -i
# mount -o bind /proc /SLACK/INSTALL/proc
# mount -o bind /dev /SLACK/INSTALL/dev
# chroot /SLACK/INSTALL
Se le librerie sono fallate dovresti ottenere già l'errore.
Oppure prova a scaricare tutti i pacchetti elencati
quì (clicca su Packages (Show/Hide) )
Codice: Seleziona tutto
# mkdir -p /SLACK
# installpkg -root /SLACK *.t?z
# mount -o bind /proc /SLACK/proc
# mount -o bind /dev /SLACK/dev
# chroot /SLACK
ora dovresti avere più o meno la stessa installazione che ti ha dato problemi con le glibc, solo che se ti crasha quì non fai casini.
)
), dare un make oldconfig e fare un po' di adattamenti. La 14.0 non l'ho provata.