Page 1 of 1

PROBLEMI di controllo fsystem al riavvio in caso di crash

Posted: 18 October 2017, 19:50
by Alex-G
Se dopo una chiusura non corretta o un crash il filesystem rimane un po corrotto, al successivo riavvio il sistema dovrebbe fare un controllo automatico e invece non lo fa mai, si blocca al boot perché ovviamente non riesce ad accedere alle partizioni con il fsystem non pulito e mi tocca avviare e2fsck manualmente da riga comandi nella console di manutenzione, smontando le partizioni ecc. ecc. poi il journal viene sempre correttamente recuperato, per *me* va anche bene (anche se l' assenza di un automatismo è un po' una perdita di tempo) io non ho problemi ma se devo installarlo a qualcuno meno esperto chiaramente non va (persino windows fa il controllo in automatico) per cui c'è un modo di farglielo fare automaticamente? Anche di default se non solo quando va in crash. Grazie

Di seguito i dati della macchina: purtroppo per ragioni di spazio ho dovuto installare il sistema su 2 dischi distinti, non è certo ottimale ma finché non trovo un hdd più capiente non posso fare altrimenti; le etichette delle partizioni linux le ho aggiunte a mano

CPU~Dual core AMD Athlon II X2 250 (-MCP-) speed/max~1800/3000 MHz Kernel~4.9.41-nrj-desktop-1rosa-i586 i686 Up~1 day Mem~677.7/1506.7MB HDD~100.0GB(55.8% used) Procs~191 Client~Shell inxi~2.3.0

Rosa Desktop Fresh R8.1

Disk /dev/sda: 74,5 GiB, 80026361856 bytes, 156301488 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xae83a548

Device Boot Start End Sectors Size Id Type
/dev/sda1 4096 6281215 6277120 3G 82 Linux swap / Solaris
/dev/sda2 * 61935616 156301487 94365872 45G 7 HPFS/NTFS/exFAT
/dev/sda3 6281216 17635327 11354112 5,4G 83 Linux Root
/dev/sda4 17635328 61935615 44300288 21,1G 5 Extended
/dev/sda5 30693376 61935615 31242240 14,9G 83 Linux Var
/dev/sda6 17637376 30693375 13056000 6,2G 83 Linux Home
Partition table entries are not in disk order.

----------------------------------

Disk /dev/sdb: 18,7 GiB, 20020396032 bytes, 39102336 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xa76f33c5

Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 2048 1146879 1144832 559M 83 Linux Boot
/dev/sdb3 1146880 39102209 37955330 18,1G f W95 Ext'd (LBA)
/dev/sdb5 1148928 23164927 22016000 10,5G 83 Linux Usr
/dev/sdb6 * 23165730 39102209 15936480 7,6G c W95 FAT32 (LBA)

Re: PROBLEMI di controllo fsystem al riavvio in caso di cras

Posted: 23 October 2017, 10:46
by NicCo
Sai, anch'io penso che sarebbe utile, e mi sono posto lo stesso tipo di problema, penso che in questi casi, in fase di avvio, un controllo, ed una relativa e conseguente procedura di recover automatico,

windows os c'è l'ha, mi sembra anche mac os,
tutte le volte che ho spento in malo modo, o si è spento in malo modo, per una ragione o l'altra, poi al successivo riavvio, sono stato testimone di un tempo più lungo in fase di riavvio (un paio di minuti), ma partono con il filesystem risistemato,

e per quanto riguarda la corruzione del rpm db, a cui ho assistito già fin troppe volte per i miei gusti, anche in questo caso il sistema potrebbe avvisare, e proporre una riparazione automatica con una ricostruzione del db, avvisando l'utente che in questo caso occorreranno alcune decine di minuti, e di avere pazienza,


a questo punto, bisognerebbe sapere se altre distribuzioni di linux prevedano qualcosa del genere, o questa mancanza è tipica in linux, su tutte le distro intendo,

qualcuno di Voi ne è a conoscenza? Grazie!

Re: PROBLEMI di controllo fsystem al riavvio in caso di cras

Posted: 24 October 2017, 2:24
by andreas
No, non sono a conoscenza di distribuzioni che adottino questo sistema. Ricordo però che mandriva o mandrake linux tempo addietro facevano questo controllo e spesso i tempi di boot si allungavano a causa di questi check.
Il vero problema, a mio avviso, è che con dischi da svariati terabyte questi controlli probabilmente porterebbero via una quantità di tempo inaccettabile e quindi andrebbe data all'utente la possibilità di decidere quando effettuare le eventuali riparazioni, supposto che non si trovi un sistema per effettuare queste verifiche in background.
Comunque concordo sul fatto che si tratta di un problema aperto.

Re: PROBLEMI di controllo fsystem al riavvio in caso di cras

Posted: 24 October 2017, 19:02
by Alex-G
andreas wrote:No, non sono a conoscenza di distribuzioni che adottino questo sistema. Ricordo però che mandriva o mandrake linux tempo addietro facevano questo controllo e spesso i tempi di boot si allungavano a causa di questi check.
Il vero problema, a mio avviso, è che con dischi da svariati terabyte questi controlli probabilmente porterebbero via una quantità di tempo inaccettabile e quindi andrebbe data all'utente la possibilità di decidere quando effettuare le eventuali riparazioni, supposto che non si trovi un sistema per effettuare queste verifiche in background.
Comunque concordo sul fatto che si tratta di un problema aperto.

Basterebbe che all' avvio il sistema facesse un check dell' attributo o bit "dirty" e allora presentasse la scelta ma in teoria dovrebbe già farlo, ricordo anche io che mandriva lo faceva, non sarà che è stata "persa o dimenticata" qualche impostazione di default relativa al filesystem? Qualcosa che viene settato nella fase di installazione tipo con tune2fs ... o un comando dato al kernel...

Re: PROBLEMI di controllo fsystem al riavvio in caso di cras

Posted: 24 October 2017, 21:11
by dlob
Interessante, ero convinto che l'ultima colonna nel file /etc/fstab si preoccupasse del controllo in caso di filsysytem corrotto (https://help.ubuntu.com/community/Fstab).
Quindi non è così?

Re: PROBLEMI di controllo fsystem al riavvio in caso di cras

Posted: 2 December 2017, 5:30
by Alex-G
SI in teoria quelle ultime opzioni in fstab dovrebbero risolvere il problema, tuttavia non accade e non solo ma per risolverlo ho dovuto smontare, controllare e rimontare tutto manualmente, sto quindi pensando di creare un script che in base alle partizioni esistenti mi faccia in automatico quelle operazioni

Anche qua ci sono delle info interessanti
http://xmodulo.com/automatic-filesystem ... linux.html
e in effetti ho attivato la seguente opzione
/etc/sysconfig/autofsck
AUTOFSCK_DEF_CHECK=yes
che però non pare funzioni in tutti i casi
Alex-G wrote:
andreas wrote:No, non sono a conoscenza di distribuzioni che adottino questo sistema. Ricordo però che mandriva o mandrake linux tempo addietro facevano questo controllo e spesso i tempi di boot si allungavano a causa di questi check.
Il vero problema, a mio avviso, è che con dischi da svariati terabyte questi controlli probabilmente porterebbero via una quantità di tempo inaccettabile e quindi andrebbe data all'utente la possibilità di decidere quando effettuare le eventuali riparazioni, supposto che non si trovi un sistema per effettuare queste verifiche in background.
Comunque concordo sul fatto che si tratta di un problema aperto.
Basterebbe che all' avvio il sistema facesse un check dell' attributo o bit "dirty" e allora presentasse la scelta ma in teoria dovrebbe già farlo, ricordo anche io che mandriva lo faceva, non sarà che è stata "persa o dimenticata" qualche impostazione di default relativa al filesystem? Qualcosa che viene settato nella fase di installazione tipo con tune2fs ... o un comando dato al kernel...
Per cui proverò anche con uno script tipo questo (invero abbastanza grezzo, si potrebbe rendere più generico facendo in modo che individui automaticamente le partizioni presenti in fstab e quindi adattabile a quialsiasi PC) dato che manualmente ha funzionato
chkdsk

Code: Select all

#!/bin/sh 
echo "This is a custom script for check and repair my linux partitions" 
echo " " 
umount /dev/sda1
umount /dev/sdb2 
echo " " 
fsck -pf /dev/sda1
echo " "
fsck -pf /dev/sdb2
echo " "
mount /dev/sda1
mount /dev/sdb2
echo " "
read -p "Press ENTER key to close this terminal" 
exit
chiaramente nello script, per come è fatto, ognuno ci deve mettere il percorso delle proprie partizioni (come dicevo sopra si potrebbe rendere più generico ed autoadattabile) consiglio di inserire sempre /root e /usr, alla fine basta rimontare solo la /usr e inviare manualmente un reboot; questo mi ha risolto egregiamente il problema della riparazione del fsystem di PC di terzi perché al limite basta indicargli di avviare dalla recovery, inserire la password di root, avviare lo script chkdsk, reboot e tutto va a posto abbastanza semplicemente.

Re: PROBLEMI di controllo fsystem al riavvio in caso di cras

Posted: 3 December 2017, 13:45
by NicCo
Ho trovato interessante la tua idea, e l'ho già segnalata a ROSA:
Ho chiesto loro se è possibile realizzare qualcosa di simile, con uno script perfezionato alle diverse situazioni delle partizioni, da integrare direttamente sul grub di ROSA, come un' utilissima funzione di FileSystem Recovery.

Re: PROBLEMI di controllo fsystem al riavvio in caso di cras

Posted: 3 December 2017, 14:01
by Alex-G
Ora in teoria potrei anche etichettare la questione come risolta... però volevo prima indagare meglio il perché le altre opzioni non funzionano (alla fine è sempre una possibilità in più nel caso le altre per qualche motivo non funzionassero) ma non essendo un mio PC, quindi domani passerò dal tipo a cui l' ho installato (peraltro, a parte questo problema, perfettamente soddisfatto del nuovo sistema Rosa che gli ha sostituito l' oramai obsoleto Vista) e mi faccio la copia delle configurazioni in /etc , magari mi era sfuggito qualcosa; di fatto però così mi ha risolto un vero grattacapo perché ogni volta che il PC per qualche motivo si spegneva in modo non corretto (va via la luce, una ciabatta malfunzionante ecc.) dovevo intervenire manualmente ... un bella scocciatura con egli che, *giustamente*, mi chiama al telefono (Alessandroooo! Aiutoooo!) :shock: :cry: l' ultima volta l' ho solo guidato un attimo per telefono ;) ma il bello è che risolto una volta... risolto per tutti e x sempre :mrgreen: