slacky.eu

Salve

ho una slack 12 installata di fresco sul mio fisso
con il kernel di default 2.6.15
mi son cimentato più volte nella ricompilazione avvolte con esito positivo ultimamente pessimo ( = kernel panic !)
Ora so che è buona norma mantenere l'immagine funzionante
, ma mi son sempre chiesto come poterla linkare ai link simbolici sistem.map etc.. ?
O meglio nel momento in cui vado ad installare la nuova immagine nella dir /boot , devo anche relinkare il sistem.map , il config , il vmlinuz ai file che ho ottenuto
dopo la ricompilazione, quindi la vecchia immagine funzionante (più i suoi file system.map e config ) non può più essere linkata ai link simbolici presenti nella boot
essendo questi orami destinati ai nuovi file !
E' il caso che prenda in considerazione l'initrd?
In qualche wiki del sito ho letto essere questa la soluzione ma non so se mi sbaglio oppure no
Qualche delucidazione in più sarebbe molto gradita !

Grazie

Non preoccuparti di queste cose.
Il config ti serve per ricompilazioni, a runtime non ti serve.
Puoi anche avere l'opzione del kernel che ti crea /proc/config.gz ma puoi anche non averla

System.map ti serve più in fase di debug e sviluppo.

Io solitamente faccio così.
Compilo un kernel, sposto i file, modifico lilo e guardo se funziona.
Se funziona modifico allora config e system.map, ma senza fretta e senza farmi problemi.

Il link simblico vmlinuz lo lascio sempre al kernl huge

dall'ultima riga che hai scritto
desumo che io possa far puntare lilo direttamente al file immagine e non al link vmlinuz?
Dove l'immagine è quella den nuovo kernel appena compilato?

moebius77 ha scritto:dall'ultima riga che hai scritto
desumo che io possa far puntare lilo direttamente al file immagine e non al link vmlinuz?
Dove l'immagine è quella den nuovo kernel appena compilato?

Certo, ci mancherebbe altro.
Puoi anche inserire più voci in lilo

quindi ricapitolando.....

compilo i sorgenti del kernel
trasferisco i file nella directory /boot senza rifare i link
aggiungo al lilo.conf la voce che punta direttamente alla nuova immagine per testarla
quindi a sito positivo linko il sistem.map e il config
e lascio il vmlinuz alla immagine nativa del kernel in modo tale da poter sempre riavviare un kernel funzionante
in caso qualcosa vado storto

Giusto?

moebius77 ha scritto:quindi ricapitolando.....

compilo i sorgenti del kernel
trasferisco i file nella directory /boot senza rifare i link
aggiungo al lilo.conf la voce che punta direttamente alla nuova immagine per testarla
quindi a sito positivo linko il sistem.map e il config
e lascio il vmlinuz alla immagine nativa del kernel in modo tale da poter sempre riavviare un kernel funzionante
in caso qualcosa vado storto

Giusto?

io faccio così, ognuno poi ha il suo modo di operare

OK grazie per il tuo aiuto!!!

conraid ha scritto:

moebius77 ha scritto:quindi ricapitolando.....

compilo i sorgenti del kernel
trasferisco i file nella directory /boot senza rifare i link
aggiungo al lilo.conf la voce che punta direttamente alla nuova immagine per testarla
quindi a sito positivo linko il sistem.map e il config
e lascio il vmlinuz alla immagine nativa del kernel in modo tale da poter sempre riavviare un kernel funzionante
in caso qualcosa vado storto

Giusto?

io faccio così, ognuno poi ha il suo modo di operare

Domanda a conraid:

su una installazione ex novo di Slackware, PJV mette sempre
un link statico di /boot/System.map verso il suo, scelto installando.

Lo cancello sempre subito, cosi` ho quello compilato da me,
con la stessa data della bzImage compilata.

Con cp /usr/src/linux/System.map /boot
IMVHO riscrivi quello originale linkato.

Se rebooti il /boot/vmlinux originale hai un /boot/System.map sbagliato.
L'ho gia` dimenticato di fare, problemi con un kernel molto piu` giovane.

Mario Vanoni

ehm...
va da se che va seguita la filosofia di pat per tutti i file

Per esempio se abbiamo compilato 2.6.25.3
cd /usr/src/linux-2.6.25.3
cp .config /boot/config-2.6.25.3
cp System.map /boot/System.map-2.6.25.3
cp arch/x86/boot/bzImage /boot/vmlinuz-2.6.25.3

meglio ancora se si usa un localversione nel config e si compila in quel modo. Per esempio aggiungendo "pippo"
Così avremmo i moduli in /lib/modules/2.6.25.3-pippo
e potremmo fare
cp .config /boot/config-2.6.25.3-pippo
cp System.map /boot/System.map-2.6.25.3-pippo
cp arch/x86/boot/bzImage /boot/vmlinuz-2.6.25.3-pippo

Hai ragione Mario, ma lo davo per scontato

confesso che non ho capito molto degli ultimi due post
comunque avrei una piccola domandina da porre a conraid
qualche tempo fa ho postato una domanda sulle differenze tra kernel huge e smp
alla quale concludevi dicendo di non far confusione e che esistevano diversi tipi di kernel:
huge
huge-smp
smp

La domanda e' :
che differenza c'e' tra gli ultimi due ?

moebius77 ha scritto:confesso che non ho capito molto degli ultimi due post
comunque avrei una piccola domandina da porre a conraid
qualche tempo fa ho postato una domanda sulle differenze tra kernel huge e smp
alla quale concludevi dicendo di non far confusione e che esistevano diversi tipi di kernel:
huge
huge-smp
smp

La domanda e' :
che differenza c'e' tra gli ultimi due ?

Eh no, spero davvero di non aver detto così.
Esistono diversi tipi di kernel

huge: tutto compreso (si usa per installazioni e emergenza)
generic: tutto modulare (si usa sempre, ma bisogna creare l'initrd)

di questi due ne esiste sia la versione smp sia quella normale.
Quella smp è uguale alla normale solo compilata per supportare più processori

quindi avrai
huge
huge-smp
generic
generic-smp

@conraid

E` uscito 2.6.25.4,
ma e` buggy, dovuto pare ad Alan Cox.
Aspetto il 2.6.25.5.

Mario Vanoni

Mario Vanoni ha scritto:@conraid

E` uscito 2.6.25.4,
ma e` buggy, dovuto pare ad Alan Cox.

Alan Cox che fa bug??? Questa si che è una notizia

P.S.
non vedo patch di AC però nel changelog

P.S.2
vedo
vt: fix canonical input in UTF-8 mode
che palle utf8, sembra che non sempre seguisse le impostazioni di vt.default_utf8

conraid ha scritto:

Mario Vanoni ha scritto:@conraid

E` uscito 2.6.25.4,
ma e` buggy, dovuto pare ad Alan Cox.

Alan Cox che fa bug??? Questa si che è una notizia

P.S.
non vedo patch di AC però nel changelog

P.S.2
vedo
vt: fix canonical input in UTF-8 mode
che palle utf8, sembra che non sempre seguisse le impostazioni di vt.default_utf8

Chiedo scusa, sbagliato colpevole, e` Alan Stern,
l'errore e` in USB ohci_sm501.c che non compila.
Disguido tra Greg Kroah-Hartmann, Andrew Morton e Alan Stern.
La thread in LKML e` chiara.

Mario Vanoni