Multi boot: alcune distro cercano /dev/root

[zoros]

replico senza quotare ... si rischia di fare una disputa personale per dire alla fine le stesse cose ... a me interessa scambiare opinioni e riscontri anche per capire ..

io ho l'impressione che questa /dev/root sia un semplice artificio nato al solo scopo di definire una voce in /etc/fstab (un po' come il fs-type "rootfs") ... come riscontro, ti posto alcuni settaggi di una Slackware64 da poco installata (su /dev/sda2):

Codice: Seleziona tutto

root@darkstar:~# cat /etc/fstab
/dev/root / auto defaults 1 1

root@darkstar:~# mount
/dev/root on / type ext3 (rw,errors=continue,data=ordered)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
usbfs on /proc/bus/usb type usbfs (rw)
/dev/sdc1 on /media/disk type vfat (rw,nosuid,nodev,uhelper=hal,uid=0,utf8,shortname=mixed)

root@darkstar:~# cat /proc/sys/kernel/real-root-dev
0

cioè tutto è montato al posto giusto ... i filesystem di sistema sono stati aggiunti da rc.S ... e la pennina sdc1 riconosciuta automaticamente da kde ...

tutto è montato al posto giusto con una sola riga in /etc/fstab ... e questa riga solo per "accontentare" rc.S ... se poi si fa il boot "read-write" (come faccio io, ma non dovevo dirlo [-X ) anche quell'unica riga non serve più ... conclusione: il /dev/root è proprio virtuale ... serve relativamente (e confonde un po' le idee) ...

[conraid]

Offtopic: @zoros

ma, come ha detto zerouno, se devi montare un particolare filesystem con alcuni permessi (per esempio /tmp con nosuid, noexec, etc...) come fai senza fstab?

[ZeroUno]

Offtopic: @zoros

ma, come ha detto zerouno, se devi montare un particolare filesystem con alcuni permessi (per esempio /tmp con nosuid, noexec, etc...) come fai senza fstab?

zoros si riferisce alla fstab minimale, ovvero la non necessità di metterla se non serve altro che la root. E' chiaro che gli altri li devi inserire per forza in fstab.
La mia obiezione è che la root nella fstab va inserita comunque.
rc.S: /sbin/fsck $FORCEFSCK -C -a /
dovrebbe cercare di capire quale sia il device a partire dalla fstab, infatti nel momento in cui viene avviato quel comando, la mtab non è disponibile e non saprebbe che pesci pigliare.
idem: /sbin/mount -w -v -n -o remount /
non credo sia cosa sana modificare l'rc.S affinchè riesca ad autodeterminare il root-device (non che ci voglia molto, basta cercare su /proc/mounts).

certo, se viene fatto il boot in read-write allora il problema non si pone, però hai il non piccolo problema di non poter effettuare mai un vero check del filesystem (non è sufficiente il check del journal e il recover dallo stesso per assicurarsi una integrità del disco; un controllo periodico va sempre effettuato). Ma dimmi, zoros, hai patchato rc.S perchè non ti mostri il warning?

Ciao
01

[zoros]

sono un po' "asincrono" in questi giorni, replico solo ora ... impegni vari ... forse anche parte dello Staff è "incasinato" con il lavoro in questi giorni ... comunque vedo con piacere che finalmente anche ZeroUno è tutto verde ... però sono ancora io l'ultimo (zo....)

più o meno è come dice ZeroUno: mi riferisco ad una installazione comune uso desktop, cioè quella per i più ... per questo scopo (e senza mettere mano ai files di configurazione di Pat) basta una sola linea in /etc/fstab perché il sistema (hal, ecc.) si adatta da solo ... lo scopo sarebbe quello di raggiungere una installazione funzionante e facilmente replicabile ... chiaro che cose particolari vanno definite ancora in fstab ... a meno di modifice di alcuni rc. di avvio ...

però sono tutte storie OFFTOPIC, infatti mi sono trovato spesso a scrivere in "Porting Slackware" ... quindi aggiungo solo per curiosità:
la -current e -current64 sono sull'altro PC che uso poco (ma userò perché si va avanti, non indietro) ... queste partono in read-only, sono originali, ma con fstab minimo ...

la Slackware che uso quotidianamente per lavoro è una versione modificata che contiene modifiche anche agli script di avvio ... questa versione parte in read-write, così da anni ... è assolutamente vero che il journaled non è sufficiente a garantire l'integrità del filesystem nel tempo ... l'idea era di fare l'operazione contraria al normale avvio: parte in rw e se qualcosa non va "chroota" su una ramdisk per il fsck ... la cosa è stata provata su tante macchine e, con sorpresa, non si sono mai evidenziati problemi seri ... problemi sui files si possono verificare in /tmp (ma mi pare che anche ZeroUno abbia fatto delle modifiche per pulire e portare in RAM la /tmp) ...

in ogni caso non volevo parlarne qui ... si tratta di esperimenti ... l'approccio classico read-only è sicuramente quello da preferire ... ma chissa che un domani ...

[ZeroUno]

però sono ancora io l'ultimo (zo....)

farò richiesta per la tua espulsione

basta una sola linea in /etc/fstab perché il sistema (hal, ecc.) si adatta da solo ... lo scopo sarebbe quello di raggiungere una installazione funzionante e facilmente replicabile

Dal momento che in fstab viene messo /dev/root la replicabilità rimane, comunque è questione di gusti. Personalmente preferisco lasciare in fstab tutti i filesystem che mette l'installer (/, /proc, /sys, /proc/bus/usb, /dev/shm e swap) perchè così ho un riscontro più immediato di quello che sarà montato al boot (nonostante quei filesystem virtuali rc.S non li legge dalla fstab)

(ma userò perché si va avanti, non indietro)

io ho ancora una 12.0 che uso regolarmente e va che è una scheggia. Mentre su un server ho una slamd64 12.1. In entrambe come aggiornamenti ci metto solo le patch.

... queste partono in read-only, sono originali, ma con fstab minimo ...

l'idea era di fare l'operazione contraria al normale avvio: parte in rw e se qualcosa non va "chroota" su una ramdisk per il fsck

spiega meglio, la cosa mi interessa. Come ti accorgi che qualcosa non va? ma soprattutto quando? Il problema del mount rw a filesystem non integro riguarda un pericolo di corruzione dei dati soprattutto nel momento stesso del mount (ammesso che non fallisca). Per me ti complichi la vita.

ma mi pare che anche ZeroUno abbia fatto delle modifiche per pulire e portare in RAM la /tmp) ...

nessuna modifica, solo aggiunto in fstab
none /tmp tmpfs defaults 0 0
Se hai molta ram l'operazione è consigliata; se usi programmi di videoediting l'operazione è praticamente obbligata. Con la /tmp in ram si ottiene un sensibile aumento delle performance dei programmi che usano pesantemente la tmp come appoggio.
Inoltre il vantaggio è che la /tmp rimane pulita al reboot e non occupa spazio (dare un du -sk /tmp periodico o un ls -lt /tmp per accorgersi della sozzura). Basta ricordarsi di non mettere nulla di importante in /tmp.
L'operazione è sconsigliata in caso di poca ram a disposizione (usa anche la swap, ma è comunque sconsigliata)

in ogni caso non volevo parlarne qui ... si tratta di esperimenti

non è OT, anzi, il discorso è interessante.

Ciao
01

[zoros]

non è OT, anzi, il discorso è interessante.

è sicuramente interessante, però si rischia di innescare false (o errate) aspettative ... premesso questo ...

spiega meglio, la cosa mi interessa. Come ti accorgi che qualcosa non va? ma soprattutto quando? Il problema del mount rw a filesystem non integro riguarda un pericolo di corruzione dei dati soprattutto nel momento stesso del mount (ammesso che non fallisca). Per me ti complichi la vita.

infatti avevo scritto "l'idea era ..." idea poi mai perfezionata, perché veri problemi di avvio non si sono mai presentati ... cioè non è mai successo che il sistema non sia arrivato al login ... al limite c'è stato un montaggio read-only al posto di rw, altre volte piccole anomalie di alcuni programmi (lentezza nel caricare, segnalazione errori) ... un avvio "rescue" o con una recovery-tools live ha sempre risolto ... intervento manuale però ...
io direi che la vera sorpresa di questo esperimento è che non sono stati mai persi dei dati, interventi fsck: pochissimi (parlo di ext3) ...

comunque hai ragione: il boot rw potrebbe complicare la vita ... e c'è un famoso OS che generalmente parte riempiendo un file di log (quindi rw) e talvolta non arriva al login (ma si riavvia di continuo) ... allora dobbiamo usare ntfsfix di Linux e al 99% dei casi, forzando lo scandisk, lo ripariamo (che regalo!) ... devo dire che la Slackware (in rw) finora si è comportata meglio, molto meglio

io ho ancora una 12.0 che uso regolarmente e va che è una scheggia. Mentre su un server ho una slamd64 12.1. In entrambe come aggiornamenti ci metto solo le patch.

anche tu segnali (se ho capito il senso) che la 12.0 e dintorni è riuscita molto bene ... per me è un capolavoro di stabilità, mi è difficile cambiare ...

nessuna modifica, solo aggiunto in fstab
none /tmp tmpfs defaults 0 0
Se hai molta ram l'operazione è consigliata; se usi programmi di videoediting l'operazione è praticamente obbligata. Con la /tmp in ram si ottiene un sensibile aumento delle performance dei programmi che usano pesantemente la tmp come appoggio.
Inoltre il vantaggio è che la /tmp rimane pulita al reboot e non occupa spazio (dare un du -sk /tmp periodico o un ls -lt /tmp per accorgersi della sozzura). Basta ricordarsi di non mettere nulla di importante in /tmp.
L'operazione è sconsigliata in caso di poca ram a disposizione (usa anche la swap, ma è comunque sconsigliata)

io invece ho messo in rc.S alcune righe che cancellano e ricreano la /tmp (andrebbe fatto anche per /var/tmp):

Codice: Seleziona tutto

echoc "Svuoto la directory dei file temporanei " green
/bin/rm -Rf /tmp
/bin/mkdir -p /tmp
chmod 1777 /tmp

con i giga di memoria che abbiamo oggi si potrebbe passare alla tua soluzione (/tmp in RAM) ... a parte la velocità di elaborazione lo svuotamento della /tmp andrebbe fatto ad ogni avvio, alcuni programmi continuano ad "incasinarsi" per file di lock e spazzatura rimasta in /tmp ... non mi sembra però che questa funzionalità sia di serie anche nelle ultime release ...

queste sono le mie impressioni/esperienze ... senza pretese ... ma dopo questa mia ennesima uscita infelice:

però sono ancora io l'ultimo (zo....)

farò richiesta per la tua espulsione

... non dovrai neanche scomodarti, lo farà sicuramente qualcun altro ...

[ZeroUno]

veri problemi di avvio non si sono mai presentati

Il problema non è "non si sono mai presentati" ma sul tipo di problema che ti potresti aspettare e quali controlli faresti per individuarli, perchè i problemi si creano, all'occorrenza (dai un fsck -y -f a file system montato in rw e vedi se non li crei i problemi)

un avvio "rescue" o con una recovery-tools live ha sempre risolto ... intervento manuale però ...

e anche quì è importate pensare che tipo di intervento dovrebbe poter fare rc.S, cioè quanto automatica deve essere la cosa.

anche tu segnali (se ho capito il senso) che la 12.0 e dintorni è riuscita molto bene ... per me è un capolavoro di stabilità, mi è difficile cambiare ...

c'è anche da dire che la stabilità in una distribuzione (qualsiasi) viene data dal non upgradare in continuazione, ed anche che kde4 non è poi così tanto adatto per la scheda grafica che ha quel pc, nonostante ho portato a 1G la ram; inoltre trovo più stabile/rapido firefox 2 che 3 sotto certi punti. Poi c'è anche da dire che i programmi che uso di più (praticamente quasi gli unici) sono firefox e konsole.

io invece ho messo in rc.S alcune righe che cancellano e ricreano la /tmp (andrebbe fatto anche per /var/tmp):

Anche questa è una soluzione valida ma rischia di essere lenta

alcuni programmi continuano ad "incasinarsi" per file di lock e spazzatura rimasta in /tmp ... non mi sembra però che questa funzionalità sia di serie anche nelle ultime release ...

non credo che sia plausibile metterlo di serie, e nemmeno si può mettere di serie la soluzione del tmpfs perchè non si può dare per scontato che la ram che abbiamo a disposizione sia sufficiente per l'uso di tmp che ne facciamo.


Ciao
01

[targzeta]

Visto che siamo più o meno andati OT e visto che si parla di patch agli script rc e di filesystem vi chiedo, che problemi potrei incontrare visto che ho disabilitato l'fsck all'avvio? O meglio, ho modificato lo script di shutdown in modo da creare un file particolare, e lo script di init in modo da controllare la presenza di questo file, se non lo trova allora esegue il fsck, mentre se lo trova lo rimuove e non fa niente. Sono anni che uso linux, i suoi filesystem e questo metodo di gestione e per ora non ho incotrato nessun problema. Visto che sapete di cosa parlate mi interesserebbe anche la vostra opinione.

Grazie mille,
Emanuele

[zoros]

Visto che siamo più o meno andati OT e visto che si parla di patch agli script rc e di filesystem vi chiedo, che problemi potrei incontrare visto che ho disabilitato l'fsck all'avvio? O meglio, ho modificato lo script di shutdown in modo da creare un file particolare, e lo script di init in modo da controllare la presenza di questo file, se non lo trova allora esegue il fsck, mentre se lo trova lo rimuove e non fa niente. Sono anni che uso linux, i suoi filesystem e questo metodo di gestione e per ora non ho incotrato nessun problema. Visto che sapete di cosa parlate mi interesserebbe anche la vostra opinione.

Grazie mille,
Emanuele

Ma guarda un po' ! ... gratta-gratta, viene fuori qualcuno che si è posto un problema simile ... mi sembra un'ottima idea la tua, Spina ... semplice ed efficace, non ci avevo pensato ... la mancanza del file di "chiusura" sarà il flag che attiva fsck al riavvio ...
certo che non risolve completamente la questione perché file corrotti si possono generare anche in caso di regolare spegnimento del pc ... però ti posso dire che (almeno con ext3) problemi al filesystem sono veramente rari e probabilmente un fsck attivato saltuariamente da una "maldestra" chiusura del pc è sufficiente a scongiurare perdite di dati ... almeno queste le mie osservazioni pratiche, ma non sono grandi numeri: qualche centinaio di pc ...

[ZeroUno]

O meglio, ho modificato lo script di shutdown in modo da creare un file particolare, e lo script di init in modo da controllare la presenza di questo file, se non lo trova allora esegue il fsck

Ovvero hai fatto precisamente (quasi) quello che viene effettuato in automatico solitamente.
Parliamo di ext2 per essere più generici; l'ext3 da un valore aggiunto. Probabilmente le seguenti cose le sai, ma le dico per fissarle.
Il comando mount marca il filesystem come mounted. Il comando umount esegue il flush della cache e marca il filesystem come unmounted/clean.
Quando al boot viene effettuato il mount read-only viene ignorato quel flag.
Quando viene effettuato l'fsck come prima cosa viene controllato quel flag; se è marcato come clean il check del fs non viene eseguito. Se invece è mancato come mounted, il check viene eseguito. E questo è quanto fai tu. Quel file particolare ti emula questo flag.
In aggiunta però l'fsck non effettua solamente il check ogni crash ma anche ogni tot numero di mount o dopo un tot numero di giorni dall'ultimo mount. Questo perchè non sempre l'umount garantisce l'integrità del filesystem; in casi particolari (bug, instabilità, probl hw, altro) potrebbe succedere che qualcosa non viene flushato correttamente ma l'umount marca comunque il filesystem come clean.

In condizioni teoriche il check con l'esistenza di quel file che usi è più che sufficiente.
Comunque con l'avvento dell'ext3 si, queste condizioni teoriche non sono lontane dal presentarsi.

Io spesso in passato patchavo i vari script rc per esigenze particolari, ma poi ho smesso perchè quello che c'è ora mi va piuttosto bene e non ho il problema di dover riportare le modifiche dopo gli upgrade.

Ciao
01

[sir_alex]

Ma mollare Lilo e passare a qualcosa di più serio, tipo Grub?

[zoros]

veri problemi di avvio non si sono mai presentati

Il problema non è "non si sono mai presentati" ma sul tipo di problema che ti potresti aspettare e quali controlli faresti per individuarli, perchè i problemi si creano, all'occorrenza (dai un fsck -y -f a file system montato in rw e vedi se non li crei i problemi)

secondo me invece è risolutiva la faccenda: veri problemi di avvio non si sono mai presentati ... la perfezione non serve, meglio una ragionevole certezza ...

... e anche quì è importate pensare che tipo di intervento dovrebbe poter fare rc.S, cioè quanto automatica deve essere la cosa

come sopra: in questo caso sembra che non sia indispensabile spingere al massimo gli automatismi ...

c'è anche da dire che la stabilità in una distribuzione (qualsiasi) viene data dal non upgradare in continuazione, ed anche che kde4 non è poi così tanto adatto per la scheda grafica che ha quel pc, nonostante ho portato a 1G la ram; inoltre trovo più stabile/rapido firefox 2 che 3 sotto certi punti. Poi c'è anche da dire che i programmi che uso di più (praticamente quasi gli unici) sono firefox e konsole.

secondo me la stabilità del s.o. (e relativi applicativi) si dovrebbe misurare da come si comporta con il processo n.1, che non è init, ma l'umano ... e l'umano si scoccia se non capisce le cose o gli sembra di perdere il suo tempo ... secondo me i nuovi DM si stanno evolvendo in una direzione errata ...

io invece ho messo in rc.S alcune righe che cancellano e ricreano la /tmp (andrebbe fatto anche per /var/tmp):

Anche questa è una soluzione valida ma rischia di essere lenta

finora la procedura si è rivelata veloce ... e poi in /tmp c'è poco o niente ... ma spesso quel poco che "incasina" tutto ...

[zoros]

Ma mollare Lilo e passare a qualcosa di più serio, tipo Grub?

Grub ha qualche funzionalità in più ... ma anche Lilo è in grado di avviare il sistema ... il problema deve essere risolto a monte ...

e poi perché Lilo non sarebbe serio ?

[ZeroUno]

Ma mollare Lilo e passare a qualcosa di più serio, tipo Grub?

Grub ha qualche funzionalità in più ... ma anche Lilo è in grado di avviare il sistema ... il problema deve essere risolto a monte ...

e poi perché Lilo non sarebbe serio ?

Quoto in pieno.

01

[ZeroUno]

...
veri problemi di avvio non si sono mai presentati ...
[...cut...]

C'è anche da dire che io ho parlato della teoria e quindi della 'presentabilità' dei problemi. Se per un uso desktop la soluzione va benissimo (e quì stiamo parlando di quello, vero?), con un server di produzione non è plausibile che a seguito di un reboot indesiderato (di notte) la macchina non riparta perchè c'è bisogno di un troubleshooting manuale. Questa è una cosa che faceva impazzire gli amministratori dei server sun solaris che al 90% dei casi a seguito di un reboot brutale la macchina non riusciva quasi mai a fare il check dei dischi automatico (è un po' di anni che non amministro una macchina solaris, quindi adesso non so come va) fermandosi quindi in maintenance mode.
Comunque ripeto, per un utilizzo desktop la tua soluzione fa il suo dovere, ma personalmente preferisco quella standard.

Ciao
01