linux user group brescia

> > Comincio ad odiare i vari BIOS e LILO.
> ti credo. il problema, come veniva sottolineato anche in linux kernel
> questi giorni, e` che, presa la documentazione ed implementato
> qualcosa, bisogna cominciare a fare tutte le dovute modifiche per
> la marea di hardware buggato in giro. non sono da ultimi i bios,
> che, soprattutto per quanto riguarda l'apm, stanno dando dei bei
> grattacapi ai developer.

APM e' uno `standard' nato male e implementato peggio (quanti notebooks
 effettivamente implementano apm a dovere? quasi nessuno a dire il vero).
Per la gestione del power saving sicuramente ACPI e' destinato ad essere
 una soluzione migliore ma e' estremamente complesso (richiede la sua
 bella macchina virtuale per implementare il sottolinguaggio che usa)
 e richiede lavoro non da poco.
[una forma di supporto e' presente nei 2.3, ma se si vuole farsene qualchecosa
 serve un demone userspace. Anche in questo caso, pero', ci sono ancora
 alcuni bugs in disperata necessita' di essere fissati]

> > (viene mappato come 0x83) e in effetti non lo è. Non ho sottomano un
> > disco di boot per windoze. Avreste qualche soluzione da suggerirmi?
> ho le idee confuse e non ho voglia di pensare, adesso.
>
> > Tenete presente che a meno di catastrofi naturali il RAID 0 dai dischi U2
> > non si muove. Mica posso dare a windoze un disco del genere, non se lo
> > merita!
> > 
> > Qualcuno conosce GRUB? Al momento non ho tempo di documentarmi ma sembra
> > molto più figo. Anche lui soffre delle limitazioni del BIOS sul 1024
> > cil. e sui 2 dischi avviabili?
> a me, personalmente, grub non garba eccessivamente, per alcuni dettagli
> (ma, invero, gli ho dato una scorsa veloce, percui dovro` mettermi a
> studiarlo con calma.)

GRUB e' un programma grosso... probabilmente troppo grosso per un `boot loader'.
In particolare si potrebbe fare facilmente a meno della graziosa interfaccina
 a menu (che pero' puo' essere utile in alcuni frangenti). Il fatto di
 avere una `console locale' aiuta, secondo me, a risolvere alcuni problemi
 come pure la possibilita' di caricare un kernel non mappato in modo lineare...

[questo potrebbe essere utile, ad esempio, se venisse implementato il
 supporto per raiserfs (oltre ad ext2, fat, bsd ffs) e /boot fosse su
 una partizione raiserfs montata SENZA notails... ]

Come `boot loader' tout court concordo che e' forse in alcuni casi un poco
 eccessivo...

> il problema del 1024esimo cilindro e` stato risolto da tempo, con piccoli
> loader, scritti, almeno quelli che ho visto io, in assembler
> che bypassavano il bios... invero ho sempre temuto di provarli, e 
> perche` marcati come cazzeggio sfizioso di programmazione, e perche`
> testati solo dagli autori e da qualche amichetto (speravo quindi che
> venissero implementati in lilo per ottenere tutte le sicurezze della
> cosa...), e perche` non mi servivano...
>
L'ultima versione di lilo (la .22) dichiara di supportare il boot oltre il
 8.4-esimo Gb se il bios la supporta. I problemi di cui si parlava in lkml
 sono relativi dischi IDE piu' grossi di 32Gb e sul fatto che il metodo
 standard usato dal BIOS da' piu' grattacapi che non soluzioni in questo
 caso. Se non si hanno problemi di compatibilita', basta settare il
 disco (per boot e tutto il resto) in modo LBA... altrimenti ci sono
 un sacco di pasticci...

Una nota: il problema qui non e' quello del 1024o cilindro... il problema
e' che il BIOS prova a fare il boot solo dall'eventuale controller IDE e
 dal PRIMO controller SCSI, ma non dal secondo (che pure e' visibile).
L'idea e' di configurare il boot loader in modo tale da fargli caricare
 `in catena' dal secondo disco il sistema operativo.
Questo teoricamente lilo dovrebbe farlo (a meno di remapping del disco)...
 gurb dovrebbe consentire di ispezionare cosa succede in modo un poco 
 piu' approfondito.

Ciao,
 lg