E' un po' che non posto da queste parti, ma ho trovato un problema troppo interessante e una risoluzione che potrebbe essere utile a qualcuno. Poi ho pensato "Postiamolo, così chi ha lo stesso problema può trovare una soluzione rapida", ma non è detto che sia indolore.
Poi potrebbe darsi che il thread fiorisca e che riesca a trovare altre cose altrettanto interessanti.
Ma andiamo con ordine.
Avevo installato la Slackware 12.2 poco tempo fa, sarà un mese circa. C'era su lilo e volevo mettere su GRUB, molto più di classe, stabile e versatile (poi spiego una differenza sostanziale di struttura tra LILO e GRUB).
Morale: scaricati i sorgenti di GRUB 0.97, configurato, compilato ed installato.
Volevo installare GRUB sull'MBR, ma non andava. Continuava a dire strane cose, a non trovare il file "stage1" nella directory
/boot/grub, dove potevo vederlo benissimo, con permessi e flag a posto. E non riuscivo a capire perchè. Stessa cosa, a quanto ne so, fa GRUB2.
Cerco un po' su Internet e trovo una discussione interessante che mi porta a capire una cosa importante.
dumpe2fs <volume> | grep inode_sizeSe la riga
inode_size riporta un numero diverso da 128 non c'è verso di far leggere a GRUB il file
stage1. Le cose stanno così: GRUB sembra incapace di leggere filesystem con inode_size diverso da 128. E, purtroppo, l'unico modo per sistemare il problema è riformattare la partizione con il valore di inode_size giusto. Nel più semplice dei casi, se l'avete formattata con
ext3 la riga può essere la seguente:
mke2fs -j -I 128 <volume>dove
<volume> rappresenta la partizione da formattare. Inutile che vi dica che prima di farlo, se avete a cuore quello che c'è sopra, fate un backup. Le cose possono diventare spinose se si tratta della partizione di sistema.
La partizione di sistema tiene dei file "delicati" che devono avere dei permessi e dei flag ben definiti, altrimenti si possono verificare problemi. Ad esempio, uno dei primi che mi è capitato era l'impossibilità di diventare superuser tramite
su. Mi diceva sempre:
setgid: operation not permittedo qualcosa del genere.
Allora controllate i flag di
su con
ls -la /bin/suI flag devono essere
-rwsr-xr-xcome specificato qui:
http://perl.plover.com/classes/unixsec/samples/slide008.htmlSe non sono quelli sopra diventate
root e fate:
chmod 4755 /bin/sue il problema scompare.
Ma i problemuzzi potrebbero essere altri.
LILO e GRUB sono fondamentalmente differenti. LILO è più semplice, ma fa anche molta fatica a riconoscere molte periferiche esterne, se non tutte. Ho notato che LILO e
udev non stanno molto bene insieme: non appena delle periferiche vengono aggiunte al sistema
udev si mette al lavoro e genera nuove periferiche secondo le specifiche in
/etc/udev/rules.d, ma LILO non se ne accorge e confronta i volumi nel file
/proc/partitions con le periferiche in
/dev (che, guarda caso, è generato da
udev).
Il problema si verifica quando esistono delle regole di udev che generano nomi di periferica "differenti" dalla normale nomenclatura dichiarata dal kernel (hda, hdb, sda, sdb...).
In altre parole, data una regola che chiama "/dev/sda1" (kernel) "/dev/USB_flash_key" (udev) e si tenti di installare LILO sull'MBR, LILO stesso evidenzia /proc/partitions (dichiarato dal kernel) differente dalla struttura di /dev/ (dichiarata da udev) ed esce dando un messaggio di errore.
GRUB invece no.
Da qui la mia "avversione" (che non è una vera e propria avversione, essendo LILO comunque un bootloader venerabile e rispettabile) verso LILO e la mia tendenza ad installare sempre GRUB.
