Kernel panic!!

[zoros]

Mah,
avevo suggerito di utilizzare il kernel-huge ... c'è stata qualche obiezione in merito, ma, direi, nessuna motivazione convincente ... ripropongo l'utilizzo del kernel-huge senza initrd ... motivazione: "semplificare quando è possibile"

[Communico]

Motivazioni per non usare l'huge? Perchè andare in giro con un camion se ti basta un'utilitaria?

Dall'ftp di slackware: kernel-generic-smp=2708KB
kernel-huge-smp=5263KB

[metrofox]

Mah,
avevo suggerito di utilizzare il kernel-huge ... c'è stata qualche obiezione in merito, ma, direi, nessuna motivazione convincente ... ripropongo l'utilizzo del kernel-huge senza initrd ... motivazione: "semplificare quando è possibile"

Che c'è di complicato nel dare 1 comando, editare il lilo.conf e scrivere lilo nel terminale?

[zoros]

Mi pare che pochi MB in più di kernel siano trascurabili se paragonati all'enorme spreco di risorse successivamente destinate al desktop manager e applicativi ... i numerosi post di questo topic evidenziano che la creazione dell'initrd non è poi così semplice ed infallibile ...

quindi, se abbiamo sufficienti risorse per far girare un Desktop grafico, non vedo controindicazioni all'uso di un kernel-huge ...

[Blallo]

ma vorrei capire...che problema da avere un kernel più grosso o meno? Si ricompila, si toglie il superfluo ed ecco fatto...

[metrofox]

excerpt from CHANGES_AND_HINTS.TXT;
As stated earlier, it is recommended that you use one of the generic kernels
rather than the huge kernels; the huge kernels are primarily intended as
"installer" and "emergency" kernels in case you forget to make an initrd.
For most systems, you should use the generic SMP kernel if it will run,
even if your system is not SMP-capable. Some newer hardware needs the
local APIC enabled in the SMP kernel, and theoretically there should not be
a performance penalty with using the SMP-capable kernel on a uniprocessor
machine, as the SMP kernel tests for this and makes necessary adjustments.
Furthermore, the kernel sources shipped with Slackware are configured for
SMP usage, so you won't have to modify those to build external modules
(such as NVidia or ATI proprietary drivers) if you use the SMP kernel.

If you decide to use one of the non-SMP kernels, you will need to follow the
instructions in /extra/linux-2.6.27.7-nosmp-sdk/README.TXT to modify your
kernel sources for non-SMP usage. Note that this only applies if you are
using the Slackware-provided non-SMP kernel - if you build a custom kernel,
the symlinks at /lib/modules/$(uname -r)/{build,source} will point to the
correct kernel source so long as you don't (re)move it.

[joe]

Ehi joe,
visto che ti piace sperimentare, perché non prendi semplicemente uno dei kernel-huge (normale o smp a seconda di cosa hai scelto) dalla directory kernels/ del DVD, lo porti in /boot ed usi semplicemente quello ... kernel huge e generic condividono gli stessi moduli, quindi basta il binario "huge" e tutto funziona senza initrd ...

Personlamente ho sempre usato kernel huge per pigrizia...devo ammetterlo, nella creazione dell'initrd necessaria non vi avevo mai capito molto, sopratutto perchè avevo riscontrato anni fa parecchi errori, su cui non avevo avuto la pazienza di indagare, mea culpa.
Ma adesso ho due motivi per cecare di partire da una base più stringata ovvero utilizzare un generic:
- sto mettendo in piedi su di un vecchio P!! con 64 MB di ram un sistemino in grado di far girare qualche client p2p (amule e bittorrent principalmente).
- banalmente: il primo punto mi ha protato a scegliere di scaricare il ramo slack-12.2 includendo solo il kernel e i moduli generic (non smp).

Quindi, la tua soluzione per altro molto "semplice" e rapida in generale, non era per me molto comoda: infatti non avevo in locale il kernel huge nè i suoi moduli...questo significava doverli scaricare e conta che non ho una connessione moderna ma devo accontentarmi di un cellulare. In altre parole questo avrebbe significato un tempo di attesa non trascurabile per il download.
Inoltre dovendo/volendo tenermi stretto in termini di leggerezza del kernel, ho due strade: limare o aggiungere. Per come la vedo io è più semplice aggiungere perchè le evntuali mancanze vengono segnalate dal manifestarsi di problemucci vari, quindi si capisce l'esigenza di una riconfigurazione increscendo del kernel.

Per tutti questi motivi ho preferito il generic e la creazione dell'initrd. Il supporto ext3 alla fine lo posso sempre aggiungere come built-in nel kernel. Senza bisogno di tutto ciò che offre l'huge...

Comunque grazie per la disponibilità e la proposta di una terza soluzione percorribile in questi casi.

[zoros]

Sì, joe,
chiaramente per ciò che devi fare c'è proprio bisogno della grande scalabilità di Linux ... diciamo che per l'uso comune su moderni PC si può fare a meno di certe ottimizzazioni per cercare di semplificare le cose ... io ho l'impressione che ci siano molte persone che utilizzano un kernel-huge, magari personalizzato ... visto che la 2.6 lo prevede, stavo addirittura pensando in questi giorni di farmi una initramfs built-in, appunto con l'idea di semplificare ...

@metrofox:
complimenti per la tua passione per Linux e per Slackware in particolare ... passione che, vedo, ti è venuta molto presto ...

cortesemente, se in futuro puoi anche arricchire i tuoi post con qualche breve commento in italiano di quanto riporti ...

EDIT:

... non avevo in locale il kernel huge nè i suoi moduli ...

un breve edit doveroso per sottolineare una questione di cui mi sono accorto solo recentemente (come si dice, talvolta ci si perde in un bicchier d'acqua):
non esistono i moduli per l'huge ... huge e generic condividono gli stessi moduli, per cui ti bastava il bzImage ...

[joe]

In effetti hai ragione ho fatto confusione con la versione smp:

Codice: Seleziona tutto

kernel-modules-2.6.27.7-i486-1.tgz	2008-Nov-21 06:15:53	18.3M	application/x-gtar
kernel-modules-2.6.27.7-i486-1.tgz.asc	2008-Nov-21 06:15:53	0.1K	text/plain
kernel-modules-2.6.27.7-i486-1.txt	2008-Nov-21 06:15:53	0.5K	text/plain
kernel-modules-smp-2.6.27.7_smp-i686-1.tgz	2008-Nov-21 05:29:27	19.1M	application/x-gtar
kernel-modules-smp-2.6.27.7_smp-i686-1.tgz.asc	2008-Nov-21 05:29:27	0.1K	text/plain
kernel-modules-smp-2.6.27.7_smp-i686-1.txt	2008-Nov-21 05:29:27	0.5K	text/plain

[Communico]

Sì, joe,
chiaramente per ciò che devi fare c'è proprio bisogno della grande scalabilità di Linux ... diciamo che per l'uso comune su moderni PC si può fare a meno di certe ottimizzazioni per cercare di semplificare le cose ... io ho l'impressione che ci siano molte persone che utilizzano un kernel-huge, magari personalizzato ... visto che la 2.6 lo prevede, stavo addirittura pensando in questi giorni di farmi una initramfs built-in, appunto con l'idea di semplificare ...

Scusa ma non vedo tutta questa semplificazione nell'evitare di dare un comando....
btw mi potresti spiegare cosa intendi per initramfs built-in?

[zoros]

Scusa ma non vedo tutta questa semplificazione nell'evitare di dare un comando....
btw mi potresti spiegare cosa intendi per initramfs built-in?

sembra in effetti tutto semplice, basta un comando per creare l'initrd ... l'impressione che si ricava però leggendo qua e la nei forum è che molti invece si trovano in difficoltà con queste cose ...

comunque mi dovete scusare se porto avanti a più riprese questo discorso ... per me è molto importante trovare delle semplificazioni (anche se poi nel spiegarle forse sembrano ancora più complicate di quanto vogliono semplificare ) ... per la initramfs ho spiegato (forse) la questione nella sezione "Porting Slackware" e con soddisfazione adesso ho un binario 2.6.29.1 di 4M, unico, che contiene un sistemino Linux in grado di reggersi da se ... niente "kernel panic!"

[conraid]

In alcuni contesti (root in LVM, RAID o CRYPT) avere un initrd è necessario, anche se compilando il kernel nel modo giusto (cioè senza aver bisogno di moduli) puoi far sì di usare lo stesso initram per più kernel
E una motivazione per non usare l'huge è che in questi casi non riesci a farlo caricare insieme ad un initram (di cui ripeto in alcuni contesti ce n'è sempre bisogno)

[Communico]

Scusa ma non vedo tutta questa semplificazione nell'evitare di dare un comando....
btw mi potresti spiegare cosa intendi per initramfs built-in?

sembra in effetti tutto semplice, basta un comando per creare l'initrd ... l'impressione che si ricava però leggendo qua e la nei forum è che molti invece si trovano in difficoltà con queste cose ...

comunque mi dovete scusare se porto avanti a più riprese questo discorso ... per me è molto importante trovare delle semplificazioni (anche se poi nel spiegarle forse sembrano ancora più complicate di quanto vogliono semplificare ) ... per la initramfs ho spiegato (forse) la questione nella sezione "Porting Slackware" e con soddisfazione adesso ho un binario 2.6.29.1 di 4M, unico, che contiene un sistemino Linux in grado di reggersi da se ... niente "kernel panic!"

Ok capito, praticamente è un kernel monolitico statico, giusto?
Comunque credo che in un normale ambito pc sia da preferire un kernel generic con initramfs (basta leggersi il readme di pat e copiare i comandi che ci sono scitti, 0 problemi...). Per il semplice motivo che lo dice S.Pat

[zoros]

In alcuni contesti (root in LVM, RAID o CRYPT) avere un initrd è necessario, anche se compilando il kernel nel modo giusto (cioè senza aver bisogno di moduli) puoi far sì di usare lo stesso initram per più kernel
E una motivazione per non usare l'huge è che in questi casi non riesci a farlo caricare insieme ad un initram (di cui ripeto in alcuni contesti ce n'è sempre bisogno)

Alcune cose del tuo discorso non mi sono molto chiare, replico per quanto mi pare di intendere:

per i volumi logici, gli md e le partizioni criptate è necessario un codice aggiuntivo ... siccome queste funzionalità non sono comprese nel kernel tree è chiaro che ci vuole una ramdisk ... ma non è detto che un giorno queste funzionalità non siano di serie nel kernel (lo stesso vale per i dischi usb: c'era una patch che avrebbe risolto la questione, ma il team di sviluppo l'ha bocciata ... per il momento) ... in ogni caso si tratta di funzionalità particolari che non interessano ai più ...

per quanto riguarda il kernel huge io mi riferivo ad un kernel gigante in generale, non quello specifico di Pat ... comunque le initrd e initramfs funzionano anche anche con kernel built-in (compreso l'huge Slackware) ... infatti ho compilato un kernel con la initramfs built-in, funziona a meraviglia ... la mia intenzione è di arrivare ad una initramfs con riconoscimento LVM, RAID e forse anche CRYPT incorporati nel kernel stesso ...

Ok capito, praticamente è un kernel monolitico statico, giusto?
Comunque credo che in un normale ambito pc sia da preferire un kernel generic con initramfs (basta leggersi il readme di pat e copiare i comandi che ci sono scitti, 0 problemi...). Per il semplice motivo che lo dice S.Pat

No, parlavo di un kernel con tanti moduli built-in e comprensivo di initramfs compilata nello stesso binario ... quanto ai readme, non sempre sono esatti e completi ... consideriamo che chi ci regala ogni giorno righe e righe di codice Linux (e dintorni) spesso non ha il tempo materiale per documentare tutto ...

comunque vedo che l'argomento "kernel" appassiona molti ... non credo ci sia una verità unica al riguardo, ma è sempre interessante parlarne ...

[conraid]

per quanto riguarda il kernel huge io mi riferivo ad un kernel gigante in generale, non quello specifico di Pat ..

è proprio questo il punto, se il kernel è "troppo" gigante a volte non riesce a caricare anche l'initram