[Linuxtrent] Re: md autodetect e moduli dischi
- From: "Daniele P." <linuxtrent-79252@xxxxxxxx>
- To: linuxtrent@xxxxxxxxxxxxx
- Date: Wed, 6 Oct 2004 12:51:45 +0200
Ciao,
a piccoli passi ma si va...
> > Se si prendono due partizioni che costituiscono un raid1 e si mettono
> > assieme manualmente (nell'interfaccia dell'installer) l'installer non
> > tocca il contenuto delle partizioni ma poi lo vede correttamente.
> > Nel mio caso sia la partizione /boot che tutta la stuttura lvm dopo aver
> > creato il device mdX e mdY hanno mantenuto i loro dati.
> > Il fatto che l'installer di default prenda come buona una partizione
> > contenente lvm sopra raid invece del raid intero secondo me è un baco.
>
> Ah interessante conclusione...
> e ????
> spiegaci il motivo di questa certezza :-)
> a me senbra una feature....
Non è una certezza, secondo me ci sono ragionevoli motivi per cui l'installer
dovrebbe comportarsi diversamente:
1) Se trova un il persistent superblock di un partizione di un raid dovrebbe
cercare di inizializzare il raid, se non ci riesce dare un warning.
2) Se all'interno della partizione ci sono comunque dei dati consistenti
dovrebbe dare un altro warning e chiedere all'utente se usare o no questi
dati facendo finta che il raid non esista e magari suggerendo (se possibile)
la correzione della tabella delle partizioni.
3) Nel caso particolare quando l'installer inizializza lvm, lvscan genera un
warning che l'installar tacitamente ignora, anche in questo caso un warning
sarebbe gradito.
4) L'installer non specifica se la creazione di un raid device sia distruttiva
o conservativa (mkraid o mdadm --assemble)
> > devfs_mk_dir: invalid argument.<4>devfs_mk_dir: invalid
> > argument.<4>devfs_mk_dev: could not append to parent for /disc
> > devfs_mk_dir: invalid argument.<4>devfs_mk_dev: could not append to
> > parent for
> > /disc
> > devfs_mk_dir: invalid argument.<4>devfs_mk_dev: could not append to
> > parent for
> > /disc
> >
> > # E così via per circa 144 volte
>
> Ovvio, non ti crea il disc....
> ma il modulo devfs è incluso nell'initrd e lo hai inizializzato come
> parametro al boot?
Ma secondo me è builtin. Vuoi sapere questo? Stiamo parlando la stessa lingua?
Quale disc? E perché tutto sembra funzionare? Scusa ma le tue risposte mi
suscitano mille domande...
# grep DEVFS /boot/conf*
/boot/config-2.6.8-1-386:CONFIG_DEVFS_FS=y
/boot/config-2.6.8-1-386:# CONFIG_DEVFS_MOUNT is not set
/boot/config-2.6.8-1-386:# CONFIG_DEVFS_DEBUG is not set
/boot/config-2.6.8-1-686-smp:CONFIG_DEVFS_FS=y
/boot/config-2.6.8-1-686-smp:# CONFIG_DEVFS_MOUNT is not set
/boot/config-2.6.8-1-686-smp:# CONFIG_DEVFS_DEBUG is not set
> > # Qui mi sono accorto si blocca se nella riga di boot di grub si passa
> > anche
> > # console=ttyS0 console=tty0 (Sarà un altro baco???)
>
> Di chi???? :-)
Non lo so, forse di chi ha installato il sistema!
Non vedo ragioni per cui il kernel dovrebbe bloccarsi in questo punto
semplicemente perché tutti gli altri kernel che ho controllato via seriale
non si sono mai fermati in questa fase e dato che il kernel senza i parametri
console in qualche modo parte...
Le seriali sono riconosciute correttamente un bel po' prima:
Serial: 8250/16550 driver $Revision: 1.90 $ 54 ports, IRQ sharing enabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Daniele P.
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx
Other related posts: