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)
PROBLEMI di controllo fsystem al riavvio in caso di crash
Re: PROBLEMI di controllo fsystem al riavvio in caso di cras
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!
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!
.
--- Professional experience ---
Kernel designer, engineer, maintainer and tester for ROSA Desktop and OpenMandriva Lx O.S.
--- currently I'm playing with ---
LTS Kernels > Linux 4.1.12-nrjQL <<< Linux 3.18.17-nrjQL <<< Linux 3.14.46-nrjQL
EOL Kernels > Linux 3.19.8-nrjQL <<< Linux 3.17.8-nrjQL <<< Linux 3.15.10-nrjQL
--- Professional experience ---
Kernel designer, engineer, maintainer and tester for ROSA Desktop and OpenMandriva Lx O.S.
--- currently I'm playing with ---
LTS Kernels > Linux 4.1.12-nrjQL <<< Linux 3.18.17-nrjQL <<< Linux 3.14.46-nrjQL
EOL Kernels > Linux 3.19.8-nrjQL <<< Linux 3.17.8-nrjQL <<< Linux 3.15.10-nrjQL
Re: PROBLEMI di controllo fsystem al riavvio in caso di cras
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.
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.
AndreaS
Procio Intel i7-4930k, mobo Asus X79-Deluxe, Adaptec raid 7805, Nvidia Quadro 6000 - Rosa Fresh R3 X64
Procio Intel i7-4930k, mobo Asus X79-Deluxe, Adaptec raid 7805, Nvidia Quadro 6000 - Rosa Fresh R3 X64
- Alex-G
- Utente
- Posts: 113
- Joined: 19 September 2011, 11:49
- ROSA: Rosa
- OpenMandriva: OpenMandriva
- Kernel: Vari
- Desktop: Vari
- country: IT
Re: PROBLEMI di controllo fsystem al riavvio in caso di cras
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...
Last edited by Alex-G on 29 October 2017, 20:47, edited 2 times in total.
- dlob
- Nuovo utente
- Posts: 2
- Joined: 29 September 2016, 17:59
- ROSA: Rosa-Fresh-R8
- OpenMandriva: OMLx3.0-x86_64
- Kernel: 4.7.3-desktop-1omv
- Desktop: KDE
- country: Italy
Re: PROBLEMI di controllo fsystem al riavvio in caso di cras
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ì?
Quindi non è così?
- Alex-G
- Utente
- Posts: 113
- Joined: 19 September 2011, 11:49
- ROSA: Rosa
- OpenMandriva: OpenMandriva
- Kernel: Vari
- Desktop: Vari
- country: IT
Re: PROBLEMI di controllo fsystem al riavvio in caso di cras
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
chkdskchiaramente 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.
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
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 funzionatoAlex-G wrote: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...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.
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
Last edited by Alex-G on 3 December 2017, 13:45, edited 1 time in total.
Re: PROBLEMI di controllo fsystem al riavvio in caso di cras
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.
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.
.
--- Professional experience ---
Kernel designer, engineer, maintainer and tester for ROSA Desktop and OpenMandriva Lx O.S.
--- currently I'm playing with ---
LTS Kernels > Linux 4.1.12-nrjQL <<< Linux 3.18.17-nrjQL <<< Linux 3.14.46-nrjQL
EOL Kernels > Linux 3.19.8-nrjQL <<< Linux 3.17.8-nrjQL <<< Linux 3.15.10-nrjQL
--- Professional experience ---
Kernel designer, engineer, maintainer and tester for ROSA Desktop and OpenMandriva Lx O.S.
--- currently I'm playing with ---
LTS Kernels > Linux 4.1.12-nrjQL <<< Linux 3.18.17-nrjQL <<< Linux 3.14.46-nrjQL
EOL Kernels > Linux 3.19.8-nrjQL <<< Linux 3.17.8-nrjQL <<< Linux 3.15.10-nrjQL
- Alex-G
- Utente
- Posts: 113
- Joined: 19 September 2011, 11:49
- ROSA: Rosa
- OpenMandriva: OpenMandriva
- Kernel: Vari
- Desktop: Vari
- country: IT
Re: PROBLEMI di controllo fsystem al riavvio in caso di cras
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!) l' ultima volta l' ho solo guidato un attimo per telefono ma il bello è che risolto una volta... risolto per tutti e x sempre