Newsgroup: it.comp.os.linux.sys
Titolo: Veremente strano!

Mi e' successa una cosa stranissima. All'intervallo del pranzo, dopo
aver compilato un nuovo 2.2.18 (aggiunte le ide-patch), lancio mkinitrd
e il sistema mi dice che tutte le device di loop sono occupate. Il
messaggio in se non mi dice gran che.
Salvo comunque il vecchio kernel, rinuncio all'initrd e modifico di
conseguenza il lilo. Avviso tutti in azienda che per una decina di
minuti non avranno la posta, la navigazione, i files condivisi
(praticamente tutto) e faccio il reboot.
Arrivati verso la fine dell'/etc/rc.d/rc.sysinit, esattamente dopo
l'enabling swap space, la macchina si blocca. Faccio ripartire con il
vecchio kernel, la macchian si blocca. Faccio ripartire con un vecchio
2.2.14, la macchina si blocca nello stesso punto.
Superato il comprensibile panico, accendo un HP E50 di backup, stacco il
disco di boot dalla prima macchina e lo attacco come terzo disco a
questo E50. Penso a un problema con la swap (visto che il blocco era in
prossimita' della sua attivazione), rifaccio un mkswap -c della
partizione, tutto ok. Provo a rispostare i dischi, la macchina si blocca
Rimetto il disco sull'e50, dopo un po' di prove copio l'rc.sysinit
dell'E50 (una RedHat 6.2) al posto dell'originale (una RedHat 7.0
patchata). Risposto i dischi e finalmente tutto va.
La cosa assurda e' che quel file non e' mai stato modificato (ho
verificato) e inoltre e' identico (verificato stasera) a quello che ho
sulla mia RH7.0 patchata di casa. Perche' mi blocca(va) il sistema? Le
differenze dei 2 files (vecchio e nuovo) sono numerose (infatti non ho
piu' AGP e altro), ma la porzione incriminata e' senz'altro l'ultima (la
parte iniziale viene correttamente eseguita.
Vorrei ripristinarlo, ma devo capire perche' non funziona e quale e' la
causa. Non posso bloccare nuovamente tutti per ore. Suggerimenti?
-- 
Saluti - Marco Coli

 (praticamente tutto) e faccio il reboot.
Marco, la prima cosa che mi viene in mente e' che l'rc.sysinit
della RH 7.0 sia buggato e visto che le segnalazioni su questa
distro si sprecano io darei un'occhiata su 
www.securityfocus.com
 per
verificare se ci sono state segnalazioni sul package initscripts e
poi eventualmente su 
ftp://updates.redhat.com
-- 
|Pierluigi De Rosa (
tho...@durin.khazad-dum.net
)|
|     E' nato il Cosenza Linux User Group	|
|   mail -s help 
cslug-...@lists.linux.it
	|
|      IRC: #cslug - 
irc.openprojects.net
	|

 poi eventualmente su 
ftp://updates.redhat.com
Grazie per il suggerimento. Allora, su securityfocus ci vado subito,
mentre sul sito degli updates di redhat ci sono praticamente di casa,
per verificare quotidianamente se esce qualche bug fix, ma su
initscripts niente, la versione attuale e' la 5.49-1 distribuita
originariamente con la 7.0.
La cosa assurda e' che ha funzionato tutto sino al reboot, quindi ci
deve essere qualche relazione che non comprendo. Ovviamente non era il
primo reboot che facevo da quando ho la 7, ma sino a ieri nessun
problema. E' la prima volta in assoluto che mi trovo davanti a un
problema che non sembra avere ne' capo ne' coda e questo mi sconcerta.
Per non parlare delle 4 ore di fermo inflitte all'azienda.


 Per non parlare delle 4 ore di fermo inflitte all'azienda.
Questo e' sicuramente l'inconveniente piu' grave, me ne rendo conto.


 Questo e' sicuramente l'inconveniente piu' grave, me ne rendo conto.
Sob!
Ecco quanto e' presente nel rc.sysinit-7.0 piu' o meno dove mi si
piantava:
# Generate a header that defines the boot kernel.
KERNEL_TYPE=`uname -r | sed
's_^[^se]*\(\|smp\|enterprise\)$_-\1_;s_^-$__'`
KERNEL_RELEASE=`uname -r | sed 's|smp\|enterprise||g'`
KERNEL_ARCH=`rpm -q --qf '%{ARCH}' kernel$KERNEL_TYPE-$KERNEL_RELEASE
2>/dev/null`
OLD_KERNEL_ARCH_TYPE=`sed -n 's_^/\* Kernel type \(.*\) \*/_\1_p'
/boot/kernel.h 2>/dev/null`
if [ -n "$KERNEL_ARCH" -a "$KERNEL_ARCH$KERNEL_TYPE" !=
"$OLD_KERNEL_ARCH_TYPE" ]; then
  ENTERPRISE="0"
  SMP="0"
  UP="0"
  case "$KERNEL_TYPE" in
  -smp) SMP="1";;
  -enterprise) ENTERPRISE="1";;
  *) UP="1";;
  esac
  cat > /boot/kernel.h << EOF
/* This file is automatically generated at boot time. */
#ifndef __BOOT_KERNEL_H_
#define __BOOT_KERNEL_H_
/* Kernel type $KERNEL_ARCH$KERNEL_TYPE */
#ifndef __MODULE_KERNEL_$KERNEL_ARCH
#define __MODULE_KERNEL_$KERNEL_ARCH 1
#endif
#ifndef __BOOT_KERNEL_ENTERPRISE
#define __BOOT_KERNEL_ENTERPRISE $ENTERPRISE
#endif
#ifndef __BOOT_KERNEL_SMP
#define __BOOT_KERNEL_SMP $SMP
#endif
#ifndef __BOOT_KERNEL_UP
#define __BOOT_KERNEL_UP $UP
#endif
#endif
EOF
fi
# Adjust symlinks as necessary in /boot to keep system services from
# spewing messages about mismatched System maps and so on.
if [ -L /boot/System.map -a -r /boot/System.map-`uname -r` ] ; then
        ln -s -f System.map-`uname -r` /boot/System.map
fi
if [ ! -e /boot/System.map -a -r /boot/System.map-`uname -r` ] ; then
        ln -s -f System.map-`uname -r` /boot/System.map
fi


 sconvolge!!
Come sarebbe a dire 'ho modificato il Sysinit'? Ma non avevi scritto
che si e' piantato quando hai lanciato mkinitrd, o ricordo male?
Mi ripeti per favore che passi hai seguito per aggiornare il kernel? A
questo punto sono un po' confuso..


piantava:
Quando hai tempo, rimetti il file rc.sysinit originale e in testa
mettici "set -x", quindi reboot e vedi bene dove si ferma.
-- 
giu...@pobox.com

 questo punto sono un po' confuso..
Evidentemente e' un po' colpa mia. Mi rispiego daccapo: il primo
problema l'ho avuto dopo la compilazione, tentando di lanciare mkinitrd,
quando il sistema mi dice che tutte le loop devices sono occupate (mai
avuto questo messaggio). Pazienza, mi sono detto, tolgo da lilo.conf il
riferimento all'initrd, non mi e' necessario per effettuare il boot,
quando il sistema risale ci riprovo. Il sistema a questo punto non sale
piu', neanche con il kernel precedente (che mi ero salvato in .prev),
neanche con il 2.2.16, neanche con un floppy con il 2.2.14 che caricato
il kernel continua dalla mia root partition su HD.
Tutte le volte mi si pianta nello stesso punto, verso la fine del
rc.sysinit, presumibilmente (al 90%) in quella porzione di script che ho
accluso nel precedente messaggio.
Risolvo (dopo altri tentativi andati a vuoto) staccando il disco di
boot, e mettendolo come disco aggiuntivo su un altro sistema,
montandolo, e sostituendo il file rc.sysinit (avevo capito che qualche
problema era la') originale (della RH7.0, ma che usavo ormai da 2 mesi)
con l'rc.sysinit del sistema ospite (una RH6.2). A questo punto,
ripristinando il disco al suo posto, il sistema sale con tutti i kernels
che mi pare! Si noti che una delle differenze tra i due files e' proprio
la sezione che ho spedito, ma che ho fatto diversi reboot in passato
senza problemi. 


 mettici "set -x", quindi reboot e vedi bene dove si ferma.
Ok, faro' questa verifica appena mi e' possibile. Immagino non a
brevissimo tempo, dato che poi per rimettere le cose a posto mi tocca
togliere il disco e rimetterlo nell'altra macchina.


 montandolo, e sostituendo il file rc.sysinit (avevo capito che qualche
Mah secondo me, non vorrei insistere, ma c'e' piu' che un bug del
kernel un bug dell'rc.sysinit della RH 7, opzione che mi pare molto
piu' verosimile.. Potresti anche pensare di segnalare la cosa a
Bugtraq, in fondo, no?


 Bugtraq, in fondo, no?
Penso che lo faro', dopo aver fatto qualche altro test (fuori orario
ufficio!!!)
Grazie della collaborazione!


 Grazie della collaborazione!
Figurati, e' un piacere..


togliere il disco e rimetterlo nell'altra macchina.
Ma non puoi fare il boot con una minidistro tipo muLinux? 
Queste mini distribuzioni non usano il tuo disco e hanno tutti i comandi 
che ti servono in un sigolo dischetto.
HTH
-- 
"It's an electronic jungle out there, and evolution 
is the name of the game" - Linus Torvalds

 che ti servono in un sigolo dischetto.
Grazie del suggerimento. Nel panico che era sopravvenuto in seguito
all'incidente, non ho avuto molto tempo per ragionare! 


 Fammi sapere allora..
Trovato il responsabile!! 
modprobe agpgart
Il tentativo di caricamento di questo modulo, effettuato proprio
nell'rc.sysinit, nella porzione di script che avevo identificato, freeza
completamente la macchina. Ha sempre funzionato regolarmente, fino a
quel reboot. Non e' un problema di compilazione del modulo, in quanto
anche facendo il boot da kernel diversi (che quindi caricano un altro
modulo) si ha il problema. Si noti che tutto ha sempre funzionato. Non
e' stato aggiunto/modificato/tolto alcunche' nell'hw
L'unica cosa che mi viene in mente e' un problema hw del chip AGP della
macchina


 macchina
Eh ok, ed ora? Voglio dire, ora che sai che e' un bug del chip AGP? Se
si verifica lo stesso malfunzionamento, a parte sostituire la scheda
non vedo altre soluzioni, purtroppo..
-- 
Pierluigi De Rosa (
tho...@durin.khazad-dum.net
).
<<      LINUX: the choice of a GNU generation     >>
<<   For my real address... ask the Balrog.       >>
* Sostenete la Lega per la Soppressione dei Troll *

 non vedo altre soluzioni, purtroppo..
Al momento non abilito AGP, e vado avanti. Nel momento in cui ho un
altro malfunzionamento, sostituisco la scheda. Intanto mi tengo pronto
una macchina di backup.


 una macchina di backup.
Si, direi che la sia proprio questa la cosa migliore..
