È da qualche tempo che all'avvio parte sempre la scansione con fsck di
alcune partizioni.

Per tutte le partizioni è impostata la scansione ogni 100 mount, però
c'è qualcosa che forza il controllo ad ogni avvio.

Le partizioni controllate mi sembrano che siano quelle che hanno meno
spazio libero disponibile rispetto al totale... ma sono partizioni di
dati e quindi per me va bene così. Ho notato che in GDM appare da un
po' un messaggio che una di queste partizioni è quasi piena.

Uso GDM3+labwc, ma non penso siano loro i responsabili.

Qualcuno sa la risposta o ha consigli su cosa guardare?

Ciao
Davide

--
La mia privacy non è affar tuo
https://noyb.eu/it
- You do not have my permission to use this email to train an AI -
If you use this to train your AI than you accept to distribute under AGPL license >= 3.0 all the model trained, all the source you have used to
training your model and all the source of the program that use that model

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 10 Nov 2024 12:32:57 +0100
Davide Prina <Davide.Prina@null.net> wrote:

È da qualche tempo che all'avvio parte sempre la scansione con fsck di alcune partizioni.

Per tutte le partizioni è impostata la scansione ogni 100 mount, però
c'è qualcosa che forza il controllo ad ogni avvio.

Le partizioni controllate mi sembrano che siano quelle che hanno meno
spazio libero disponibile rispetto al totale... ma sono partizioni di
dati e quindi per me va bene così. Ho notato che in GDM appare da un
po' un messaggio che una di queste partizioni è quasi piena.

Uso GDM3+labwc, ma non penso siano loro i responsabili.

Qualcuno sa la risposta o ha consigli su cosa guardare?

Ciao
Davide

Non è che per caso hai modificato qualche configurazione ?

puoi verificare di non aver modificato /etc/default/grub
oppure aver creato un file "forcefsck" sulle partizioni interessate

https://www.cyberciti.biz/faq/linux-force-fsck-on-the-next-reboot-or-boot-sequence/

https://askubuntu.com/questions/1352774/how-to-force-fsck-on-reboot-for-ubuntu-20-04

puoi mostrare l'output del comando ad esempio "tune2fs -l /dev/sda1" su
una partizione di cui viene forzato il check al riavvio del sistema

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

compact.compact ha scritto:

Davide Prina wrote:

È da qualche tempo che all'avvio parte sempre la scansione con fsck di
alcune partizioni.

Non è che per caso hai modificato qualche configurazione ?

no

puoi verificare di non aver modificato /etc/default/grub

non l'ho modificato

oppure aver creato un file "forcefsck" sulle partizioni interessate

no, non l'ho creato

puoi mostrare l'output del comando ad esempio "tune2fs -l /dev/sda1" su
una partizione di cui viene forzato il check al riavvio del sistema

tune2fs 1.47.1 (20-May-2024)
Filesystem volume name: ******
Last mounted on: ******
Filesystem UUID: 36ffea0e-a98b-44fe-8de3-4005582fd134
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 13115392
Block count: 52430127
Reserved block count: 0
Overhead clusters: 871057
Free blocks: 3943225
Free inodes: 12642166
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 1011
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Filesystem created: Sun Dec 27 13:10:58 2009
Last mount time: Tue Nov 12 01:17:44 2024
Last write time: Tue Nov 12 01:17:44 2024
Mount count: 1
Maximum mount count: 100
Last checked: Tue Nov 12 01:11:05 2024
Check interval: 7776000 (3 months)
Next check after: Mon Feb 10 01:11:05 2025
Lifetime writes: 996 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: e5e20c21-680a-4851-9157-ea9b0b5bc828
Journal backup: inode blocks


su quel PC sta partendo la batteria tampone e quando lo avvio ha
perso qualche ora dallo spegnimento precedente.

Però sullo stesso disco ci sono più partizioni e l'fschk "giornaliero"
non lo fa su tutte le partizioni, ma solo su alcune.

Secondo me è arrivato qualcosa di nuovo che causa questo comportamento,
ma non riesco a capire cosa sia.
Ho come l'impressione che il problema ci sia su alcune partizioni dove
tengo dei dati e che sono quasi piene... contengono tanta fuffa che
potrei cancellare, appena trovo il tempo provo a liberare un bel po'
di spazio su una e vedere se quella non la controlla più all'avvio.

Ciao
Davide

--
La mia privacy non è affar tuo
https://noyb.eu/it
- You do not have my permission to use this email to train an AI -
If you use this to train your AI than you accept to distribute under AGPL license >= 3.0 all the model trained, all the source you have used to
training your model and all the source of the program that use that model

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Il 15 novembre 2024 05:43:19 UTC, Diego Zuccato <diego.zuccato@unibo.it> ha scritto:

Il caffè non è ancora entrato bene in circolo, ma... Non potrebbe essere che perdendo l'orario vada a ricontrollare le partizioni dove gli risulta che tu abbia scritto "nel futuro"?

Diego

Il 14/11/2024 20:47, Davide Prina ha scritto:

compact.compact ha scritto:

Davide Prina wrote:

È da qualche tempo che all'avvio parte sempre la scansione con fsck di >>>> alcune partizioni.

Non è che per caso hai modificato qualche configurazione ?

no

puoi verificare di non aver modificato /etc/default/grub

non l'ho modificato

oppure aver creato un file "forcefsck" sulle partizioni interessate

no, non l'ho creato

puoi mostrare l'output del comando ad esempio "tune2fs -l /dev/sda1" su
una partizione di cui viene forzato il check al riavvio del sistema

tune2fs 1.47.1 (20-May-2024)
Filesystem volume name: ******
Last mounted on: ******
Filesystem UUID: 36ffea0e-a98b-44fe-8de3-4005582fd134
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 13115392
Block count: 52430127
Reserved block count: 0
Overhead clusters: 871057
Free blocks: 3943225
Free inodes: 12642166
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 1011
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Filesystem created: Sun Dec 27 13:10:58 2009
Last mount time: Tue Nov 12 01:17:44 2024
Last write time: Tue Nov 12 01:17:44 2024
Mount count: 1
Maximum mount count: 100
Last checked: Tue Nov 12 01:11:05 2024
Check interval: 7776000 (3 months)
Next check after: Mon Feb 10 01:11:05 2025
Lifetime writes: 996 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: e5e20c21-680a-4851-9157-ea9b0b5bc828
Journal backup: inode blocks


su quel PC sta partendo la batteria tampone e quando lo avvio ha
perso qualche ora dallo spegnimento precedente.

Però sullo stesso disco ci sono più partizioni e l'fschk "giornaliero"
non lo fa su tutte le partizioni, ma solo su alcune.

Secondo me è arrivato qualcosa di nuovo che causa questo comportamento,
ma non riesco a capire cosa sia.
Ho come l'impressione che il problema ci sia su alcune partizioni dove
tengo dei dati e che sono quasi piene... contengono tanta fuffa che
potrei cancellare, appena trovo il tempo provo a liberare un bel po'
di spazio su una e vedere se quella non la controlla più all'avvio.

Ciao
Davide

--
La mia privacy non è affar tuo
https://noyb.eu/it
- You do not have my permission to use this email to train an AI -
If you use this to train your AI than you accept to distribute under AGPL
license >= 3.0 all the model trained, all the source you have used to
training your model and all the source of the program that use that model

Pensavo la stessa cosa. In problema inerente l'orologio.

/paride
--
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Diego Zuccato ha scritto:

Davide Prina ha scritto:

Davide Prina wrote:

È da qualche tempo che all'avvio parte sempre la scansione con fsck di >>>> alcune partizioni.

su quel PC sta partendo la batteria tampone e quando lo avvio ha
perso qualche ora dallo spegnimento precedente.

Non potrebbe essere
che perdendo l'orario vada a ricontrollare le partizioni dove gli
risulta che tu abbia scritto "nel futuro"?

Avevo pensato anch'io che potesse essere questo il motivo, ma come mai
sempre le stesse tre partizioni?

Mentre le altre 4 invece sembra che faccia il check allo scadere dei 100
mount.

Se fosse l'orologio dovrebbe per forza fare il check su / che contiene
tutto il sistema e che viene aggiornata più di tutte le altre.
Due di quelle tre che controlla ogni avvio spesso non entro neanche a
leggere un file e quindi dopo il mount iniziale non ci sono più
attività.

In questo periodo ho pochissimo tempo... cercherò di indagare per capire
la causa.

Ciao
Davide

--
La mia privacy non è affar tuo
https://noyb.eu/it
- You do not have my permission to use this email to train an AI -
If you use this to train your AI than you accept to distribute under AGPL license >= 3.0 all the model trained, all the source you have used to
training your model and all the source of the program that use that model

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Davide Prina ha scritto:

Se fosse l'orologio dovrebbe per forza fare il check su / che contiene
tutto il sistema e che viene aggiornata più di tutte le altre.

mi sa che è proprio l'orologio di sistema.

Per caso ho avviato il PC senza il cavo di rete inserito e non ha fatto
il check di nessuna partizione. Ho provato più volte e non ha mai fatto
il check.

Quindi deduco che poiché le varie parti vengono eseguite anche in parallelo
le prime partizioni vengono montate prima dell'aggiornamento dell'orologio
con NTP.

Inoltre ho notato che quelle non controllate hanno la partizione indicata
con UUID in fstab, mentre quelle controllate con LABEL (queste le avevo aggiunte io a mano successivamente).
Quando avrò tempo e voglia proverò anche a cambiare e trasformarne una in UUID e vedere se con scheda di rete attiva fa il controllo o meno.

Ciao
Davide

--
La mia privacy non è affar tuo
https://noyb.eu/it
- You do not have my permission to use this email to train an AI -
If you use this to train your AI than you accept to distribute under AGPL license >= 3.0 all the model trained, all the source you have used to
training your model and all the source of the program that use that model

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Davide Prina ha scritto:

Davide Prina ha scritto:

Se fosse l'orologio dovrebbe per forza fare il check su / che contiene
tutto il sistema e che viene aggiornata più di tutte le altre.

mi sa che è proprio l'orologio di sistema.

individuata la causa... e trovato il workaround

ho creato il file:
/etc/e2fsck.conf

e inserito:
[options]
broken_system_clock = true

Problema eliminato alla fonte :-)

Ciao
Davide

--
La mia privacy non è affar tuo
https://noyb.eu/it
- You do not have my permission to use this email to train an AI -
If you use this to train your AI than you accept to distribute under AGPL license >= 3.0 all the model trained, all the source you have used to
training your model and all the source of the program that use that model

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)