OVH Community, your new community space.

Problema: non parte da disco, ma in vKVM fila tutto liscio


Marius
12.05.2012, 11.34
Ciao, mi spiace non poterti essere d'aiuto e ti ringrazio per il suggerimento/consiglio ma ho da tempo abbandonato la soluzione vps che non potevo più aggiornare e sono migrato su un server Kimsufi (e devo dire che lo consiglio).

Ti auguro miglior fortuna (o forse semplicemente maggior bravura ;>) della mia nella risoluzione del problema, e ti rinnovo i ringraziamenti per aver provato a fornirmi una soluzione.

Ciao!

z4k
12.05.2012, 10.17
ciao

anche io sto riscontrando diversi problemi dopo aver aggiornato da lenny a squeeze, uno fra tutti e' una specie di bug nel pacchetto grub-pc che non riesco a risolvere, il mio problema che dopo l'aggiornamento sono spariti di file delle partizioni sda sda1 con un fdisk -l non compare nulla, ma la macchina si avvia normalmente ed il pacchetto grub-pc risulta semprte danneggiato ad ogni aptitude purge/reinstall ecc

posso chiederti di listarli i file che hai nella /boot??

ho una idea che potresti provare per il tuo problema, ho notato che il file /etc/grub.d/01_OVHkernel contiene un errore alla riga 12:
Codice:
linux=`ls -1 -t /boot/bzImage | head -n1`
in quanto il file /boot/bzImage non esiste, potresti provare a creare un symlink all'immagine del tuo kernel presente sempre in /boot, il mio ad esempio e' fatto cosi:

Codice:
ls -l /boot
lrwxrwxrwx 1 root root      33 11 mag 18.03 bzImage -> bzImage-2.6.24.5-xxxx-grs-ipv4-32
-rw-r--r-- 1 root root 3267416 29 mag  2008 bzImage-2.6.24.5-xxxx-grs-ipv4-32
forse il tuo problema e' che grub non riesce a trovare l'immagine di boot e non si avvia

Marius
09.10.2011, 17.20
Aggiungo nuovi dettagli nella speranza che tra i tanti visitatori qualcuno trovi il giusto spunto per suggerirmi qualcosa...

Il supporto OVH mi ha risposto:
il server è bloccato al boot sul hard disk
su questo errore :
"/sbin/sh :can't acces tty job control turned off
(initramfs)"

Dopo il netboot su bzImage, il server risponde al
ping e i ports sono aperti.
solo che dopo il netboot su kernel ovh il server risponde si al ping ma non sull'ip di failover, e di ssh non se ne parla proprio.

Googlando, quel messaggio di errore sembra di una vaghezza desolante. Ho verificato la correttezza del grub.cfg (coerenza di UUID del disco e partizionamenti vari) ed altre cose riportate qua e la, ma quello che proprio mi confonde (data la scarsa conoscenza in merito) è la differenza di comportamento con il caricamento in vKVM, dove la fase di boot avviene senza nemmeno un warning (e no, l'installazione/upgrade non è avvenuta via vKVM quindi kernel moduli e quant'altro non dovrebbero essere stati tarati/configurati sul sistema virtuale della vKVM visto che la Lenny di OVH dal disco parte tranquillamente).

Idee? O anche solo un messaggio di conforto

Marius
07.10.2011, 00.39
Come da topic.

Il mio caro RPS I (con una Debian Lenny upgradata a Squeeze "manualmente") parte tranquillamente e senza problemi di rilievo se avviata con la modalità vKVM, riesco anche a fare login ed esplorare il disco ecc. Quando sposto il boot sul disco, però, nulla da fare.

Riavviando da vKVM a boot dal disco, il ping sull'ip di failover, come ovvio, "sparisce" da subito dopo il riavvio hardware. Il ping sull'ip "diretto", invece (e qui, non avendo ben chiaro il meccanismo non so se è "normale") risponde per diversi minuti, salvo poi fare la fine dell'altro (dopo mezzora ancora nessun segno di vita). Riavviando in modalità vKVM, invece, il boot si completa (nuovamente e del tutto) in meno di 8 minuti cronometrati.

Inoltre, dai log di sistema il tentativo di boot dall'hd sembra non comparire affatto, come se il problema sorgesse ben prima dell'avvio del demone di log (la bios? il bootloader? il kernel? il ram disk?)

Dal momento che consideravo la vKVM un buon modo per diagnosticare problemi all'avvio, e che invece il caricamento proprio in quella circostanza non presenta problema alcuno, come posso arrivare a capire di che problema si tratta e quindi risolvere?

Come dicevo, la distro è una Debian Squeeze (ex Lenny) con kernel "originale" 2.6.32-5-686 aggiunto a mano in sostituzione di quello OVH che non voleva saperne di star calmo (Panic da tutte le parti). Il bootloader è Grub 1.98+20100804-14. Il ram disk è quello automaticamente creato per il kernel in questione. Le partizioni sono in ext4, /dev/sda1 su / da 5 GB e /dev/sda2 su /home/ per i restanti 25. Se serve sapere altro chiedete pure.

Grazie per l'attenzione e le eventuali risposte