Forum: PC Hard- und Software Mint 19.2 zerschießt sein Dateisystem


von Reinhard S. (rezz)


Lesenswert?

Moin,

mein Mint 19.2 zeigt nach
Beitrag "Linux Mint 19.2: Grafischer Login klappt nicht mehr"
mal wieder lustige Symptome:

Im Normalbetrieb meint es plötzlich nicht mehr schreiben zu können, da 
das Dateisystem read-only ist. Dementsprechend geht auch kein 
Herunterfahren mehr. Nach hartem Shutdown startet es nur noch in die 
built-in-Shell.

fsck von dieser Shell aus gestartet bringt mir eine Menge Fehler und 
nach deren Beseitigung läuft es erstmal wieder. Da ich den Fehler 
allerdings vorgestern schonmal hatte und da durch ein Backup vom Mai 
"gelöst" habe mache ich mir wenig Hoffnungen auf eine dauerhafte Lösung.

Einen SSD-Schaden würd ich ausschließen, da das parallel installierte 
Win7 wie immer läuft. Auf der 317-GB-Partition sind laut 
Systemüberwachung 29 GB "frei" und 12 GB "verfügbar", also sollte 
Speicherplatz auch nicht das riesige Problem sein, ich überlege aber 
trotzdem, mir mal eine größere SSD zuzulegen.

dmesg mit Filter auf Error zeigt mir folgendes:
1
[    1.303651] tpm_crb MSFT0101:00: can't request region for resource [mem 0xc7f65000-0xc7f6502f]
2
[    2.004884] mmc0: Unknown controller version (3). You may experience problems.
3
[   16.334912] Could not find key with description: [ce44adcfc00e19c0]
4
[   16.334916] Could not find valid key in user session keyring for sig specified in mount option: [ce44adcfc00e19c0]
5
[   16.334918] Error parsing options; rc = [-2]

Hat hier jemand hilfreiche Tips? Meine Theorien sind entweder doch zu 
wenig Speicherplatz oder irgendein Update seit letzter Zeit schießt 
quer.

: Bearbeitet durch User
von Marcello E. (leto)


Lesenswert?

Versuch mal den TPM im BIOS abzuschalten.

von Irgend W. (Firma: egal) (irgendwer)


Lesenswert?

Reinhard S. schrieb:
> Hat hier jemand hilfreiche Tips? Meine Theorien sind entweder doch zu
> wenig Speicherplatz oder irgendein Update seit letzter Zeit schießt
> quer.

Ich würde bei so merkwürdigem Verhalten auch RAM fehler nicht 
ausschliesen. Lass mal einen. Usb-Boot-Stick basteln und memtest mal 
eine Tag lang laufen lassen...

Beitrag #6778532 wurde von einem Moderator gelöscht.
von Bauform B. (bauformb)


Lesenswert?

Reinhard S. schrieb:
> dmesg mit Filter auf Error zeigt mir folgendes:

Das war aber nach der Reparatur, oder? Melde dich mal gleich nach dem 
Start auf einer Textkonsole als root an und arbeite ansonsten ganz 
normal. Sobald der Fehler auftritt, machst du auf der root-Konsole ein 
dmesg.

von Reinhard S. (rezz)


Lesenswert?

Bauform B. schrieb:
> Reinhard S. schrieb:
>> dmesg mit Filter auf Error zeigt mir folgendes:
>
> Das war aber nach der Reparatur, oder?

Ja, richtig.

> Melde dich mal gleich nach dem
> Start auf einer Textkonsole als root an und arbeite ansonsten ganz
> normal. Sobald der Fehler auftritt, machst du auf der root-Konsole ein
> dmesg.

Gute Idee. Mal schauen, ob ich immer daran denke :)

von Georg A. (georga)


Lesenswert?

RAM oder SSD. Probleme der SSD können auch sehr selektiv sein.

von Andreas B. (bitverdreher)


Lesenswert?

Reinhard S. schrieb:
> Einen SSD-Schaden würd ich ausschließen, da das parallel installierte
> Win7 wie immer läuft.
Es könne ja auch Teile des Speichers der SSD defekt sein. Es muß nicht 
immer der Controller sein.

> fsck von dieser Shell aus gestartet bringt mir eine Menge Fehler und
> nach deren Beseitigung läuft es erstmal wieder. Da ich den Fehler
> allerdings vorgestern schonmal hatte

Das spricht auch für eine defekte SSD.

Beitrag #6778896 wurde von einem Moderator gelöscht.
Beitrag #6778899 wurde von einem Moderator gelöscht.
von Walter K. (walter_k488)


Lesenswert?

Ich würde auch auf SSD tippen.
Wenn nun Windows problemlos läuft - was ja eigentlich ohnehin eher 
selten der Fall ist ;-) … kann es einfach daran liegen, dass Windows 
zufälligerweise in nicht-kritischen Bereichen der SSD liegt.
Im übrigen war es schon immer eine gute Idee, wenn man 5 bis 10% einer 
SSD gar nicht erst nutzt - also beim anlegen der Partitions außen vor 
lässt.

von Jack V. (jackv)


Lesenswert?

Wenn ein Schaden am SSD vermutet wird, so wäre ein Blick in die 
SMART-Daten, sowie ein SMART-Selbsttest, anzuraten. Das Werkzeug hierfür 
wäre ›smartctl‹.

von Programmierer (Gast)


Lesenswert?

Reinhard S. schrieb:
> dmesg mit Filter auf Error zeigt mir folgendes:

Diese Fehler haben nichts mit dem Dateisystem zu tun. Bei ständig 
kaputtem Dateisystem würde ich auch auf defekten RAM oder SSD tippen.

Rudi Ratlos schrieb im Beitrag #6778896:
> Ich habe 20.04_32!bit am Laptop gehabt. Jedes zweite Mal war das Menü
> verschwunden, es fuhr --derartig langsam-- hoch

Ich habe Linux Mint 20.2 64bit auf einem uralten Laptop und es ist 
blitzschnell und stabil, schneller als Windows. Und überhaupt, 32bit?! 
Seit Version 20 hat Linux Mint keine 32bit-Versionen mehr.

von Nano (Gast)


Lesenswert?

Jack V. schrieb:
> Wenn ein Schaden am SSD vermutet wird, so wäre ein Blick in die
> SMART-Daten, sowie ein SMART-Selbsttest, anzuraten. Das Werkzeug hierfür
> wäre ›smartctl‹.

So sehe ich das auch und dann wäre noch ein Blick in die fstab sinnvoll 
um zu sehen, mit welchen Parametern die Linux Partition auf der SSD 
eingebunden wurde.
Es gibt da ein paar Parameter, die das totschreiben deutlich reduzieren. 
Bei neuen Distris sind die defaultmäßig aktiv.

Und wenn du es bezüglich SMART grafisch und bequem haben willst, kannst 
du auch gsmartcontrol verwenden.

von Marcello E. (leto)


Lesenswert?

Nochmal,

tpm_crb MSFT0101:00: can't request region for resource

zeigt das das TPM nicht eingebunden werden kann.
Deshalb versuche mal das TPM im BIOS abzuschalten.

von Dieter (Gast)


Lesenswert?

Schau bitte auch was swap macht. Hast Du eine Swappartition?
Wenn da ein Fehler auftritt, kann sein dass swapfile verwendet wird und 
die rootpartition herunternudelt. swapon ohne Parameter zeigt 
Informationen an.

von Norbert (Gast)


Lesenswert?

Dieter schrieb:
> swapon ohne Parameter zeigt Informationen an.

swapon -s wenn ich mich nicht täusche.

von Rummel Rainer (Gast)


Lesenswert?

Die Dateisystemfunktionen liegen doch im Kernel. Sehr sehr 
unwahrscheinlich dass Mint da was zerschießt. Auch die Begründung dass 
Win funktioniert und deshalb die SSD wohl keinen Defekt hat kann man so 
nicht unterschreiben. Bei selektiven ssd Fehlern ist so ein Verhalten 
ganz typisch.

von Reinhard S. (rezz)


Lesenswert?

Dieter schrieb:
> Schau bitte auch was swap macht. Hast Du eine Swappartition?

Nein, hab ich nicht.

> swapon ohne Parameter zeigt Informationen an.
1
NAME      TYPE      SIZE USED PRIO
2
/dev/dm-0 partition   2G 120K   -2

TPM hab ich bereits deaktiviert, außer dem Wegfall der oben genannten 
Fehlermeldung sind mir bisher aber keine direkten Änderungen 
aufgefallen.

Obwohl: Der Standby-Modus, der bisher nicht funktioniert hat 
(Wiederaufwachen aus Standby resultierte in Neustart) läuft jetzt 
plötzlich wie er soll. Wunderwelt der Technik.

Der Fehler ist grad wieder aufgetreten, da ich aber die dmesg-Meldungen 
nicht mehr auf Platte speichern kann (read-only...) hier der Spaß:
1
[ 1512.629922] show_signal_msg: 12 callbacks suppressed
2
[ 1512.629933] clock-applet[1366]: segfault at 55be59680cc0 ip 00007fe21fe2a354 sp 00007ffcfdb57080 error 5 in libharfbuzz.so.0.10702.0[7fe21fe02000+9c000]
3
[ 1512.878155] BUG: Bad page map in process clock-applet  pte:8000006e1bf818b3 pmd:21fa22067
4
[ 1512.878161] addr:00000000b011f245 vm_flags:08100073 anon_vma:0000000093da3a82 mapping:          (null) index:55be59680
5
[ 1512.878162] file:          (null) fault:          (null) mmap:          (null) readpage:          (null)
6
[ 1512.878165] CPU: 2 PID: 1366 Comm: clock-applet Tainted: G           OE    4.15.0-151-generic #157-Ubuntu
7
[ 1512.878166] Hardware name: FUJITSU LIFEBOOK E746/FJNB292, BIOS Version 1.28 07/28/2020
8
[ 1512.878167] Call Trace:
9
[ 1512.878171]  dump_stack+0x6d/0x8b
10
[ 1512.878174]  print_bad_pte+0x222/0x2e0
11
[ 1512.878175]  _vm_normal_page+0x9c/0x100
12
[ 1512.878176]  follow_page_pte+0x1e2/0x6c0
13
[ 1512.878178]  follow_pmd_mask+0x209/0x640
14
[ 1512.878179]  follow_page_mask+0x17a/0x210
15
[ 1512.878180]  __get_user_pages+0x1ee/0x760
16
[ 1512.878181]  get_dump_page+0x4a/0x70
17
[ 1512.878183]  elf_core_dump+0x838/0xa50
18
[ 1512.878186]  do_coredump+0x8ce/0xf70
19
[ 1512.878189]  get_signal+0x139/0x7a0
20
[ 1512.878191]  do_signal+0x37/0x720
21
[ 1512.878193]  ? __bad_area_nosemaphore+0xd7/0x1b0
22
[ 1512.878195]  ? printk+0x52/0x6e
23
[ 1512.878196]  ? bad_area_access_error+0x6a/0xb0
24
[ 1512.878198]  ? __do_page_fault+0x1b4/0x4b0
25
[ 1512.878200]  exit_to_usermode_loop+0x73/0xd0
26
[ 1512.878201]  prepare_exit_to_usermode+0x83/0x90
27
[ 1512.878203]  ? page_fault+0x2f/0x50
28
[ 1512.878204]  retint_user+0x8/0x8
29
[ 1512.878205] RIP: 0033:0x7fe21fe2a354
30
[ 1512.878206] RSP: 002b:00007ffcfdb57080 EFLAGS: 00010206
31
[ 1512.878207] RAX: 000055be59680cc0 RBX: 000055be597f27e8 RCX: 0000000000000000
32
[ 1512.878208] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00007fe21fe6cc40
33
[ 1512.878208] RBP: 000055be599378a0 R08: 0000000000000002 R09: 0000000000000000
34
[ 1512.878209] R10: 0000000000000000 R11: 000055be597f2170 R12: 0000000000000004
35
[ 1512.878209] R13: 000000000000000d R14: 000055be597f22ec R15: 0000000000000000
36
[ 1512.878211] Disabling lock debugging due to kernel taint
37
[ 1512.878904] BUG: Bad page map in process clock-applet  pte:8000006e1bf818b3 pmd:21fa22067
38
[ 1512.878907] addr:00000000c29fb081 vm_flags:08100073 anon_vma:0000000093da3a82 mapping:          (null) index:55be59740
39
[ 1512.878909] file:          (null) fault:          (null) mmap:          (null) readpage:          (null)
40
[ 1512.878911] CPU: 2 PID: 1366 Comm: clock-applet Tainted: G    B      OE    4.15.0-151-generic #157-Ubuntu
41
[ 1512.878912] Hardware name: FUJITSU LIFEBOOK E746/FJNB292, BIOS Version 1.28 07/28/2020
42
[ 1512.878913] Call Trace:
43
[ 1512.878916]  dump_stack+0x6d/0x8b
44
[ 1512.878917]  print_bad_pte+0x222/0x2e0
45
[ 1512.878919]  _vm_normal_page+0x9c/0x100
46
[ 1512.878920]  follow_page_pte+0x1e2/0x6c0
47
[ 1512.878921]  follow_pmd_mask+0x209/0x640
48
[ 1512.878922]  follow_page_mask+0x17a/0x210
49
[ 1512.878923]  __get_user_pages+0x1ee/0x760
50
[ 1512.878925]  get_dump_page+0x4a/0x70
51
[ 1512.878927]  elf_core_dump+0x838/0xa50
52
[ 1512.878930]  do_coredump+0x8ce/0xf70
53
[ 1512.878932]  get_signal+0x139/0x7a0
54
[ 1512.878934]  do_signal+0x37/0x720
55
[ 1512.878936]  ? __bad_area_nosemaphore+0xd7/0x1b0
56
[ 1512.878938]  ? printk+0x52/0x6e
57
[ 1512.878939]  ? bad_area_access_error+0x6a/0xb0
58
[ 1512.878941]  ? __do_page_fault+0x1b4/0x4b0
59
[ 1512.878943]  exit_to_usermode_loop+0x73/0xd0
60
[ 1512.878944]  prepare_exit_to_usermode+0x83/0x90
61
[ 1512.878945]  ? page_fault+0x2f/0x50
62
[ 1512.878946]  retint_user+0x8/0x8
63
[ 1512.878947] RIP: 0033:0x7fe21fe2a354
64
[ 1512.878948] RSP: 002b:00007ffcfdb57080 EFLAGS: 00010206
65
[ 1512.878949] RAX: 000055be59680cc0 RBX: 000055be597f27e8 RCX: 0000000000000000
66
[ 1512.878949] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00007fe21fe6cc40
67
[ 1512.878950] RBP: 000055be599378a0 R08: 0000000000000002 R09: 0000000000000000
68
[ 1512.878950] R10: 0000000000000000 R11: 000055be597f2170 R12: 0000000000000004
69
[ 1512.878951] R13: 000000000000000d R14: 000055be597f22ec R15: 0000000000000000
70
[ 1512.910353] BUG: Bad page map in process clock-applet  pte:8000006e1bf818b3 pmd:21fa22067
71
[ 1512.910357] addr:00000000b011f245 vm_flags:08100073 anon_vma:0000000093da3a82 mapping:          (null) index:55be59680
72
[ 1512.910359] file:          (null) fault:          (null) mmap:          (null) readpage:          (null)
73
[ 1512.910361] CPU: 2 PID: 1366 Comm: clock-applet Tainted: G    B      OE    4.15.0-151-generic #157-Ubuntu
74
[ 1512.910362] Hardware name: FUJITSU LIFEBOOK E746/FJNB292, BIOS Version 1.28 07/28/2020
75
[ 1512.910362] Call Trace:
76
[ 1512.910366]  dump_stack+0x6d/0x8b
77
[ 1512.910369]  print_bad_pte+0x222/0x2e0
78
[ 1512.910371]  ? alloc_pages_current+0x6a/0xe0
79
[ 1512.910372]  _vm_normal_page+0x9c/0x100
80
[ 1512.910373]  unmap_page_range+0x53f/0xd00
81
[ 1512.910375]  unmap_single_vma+0x7d/0xf0
82
[ 1512.910377]  unmap_vmas+0x51/0xb0
83
[ 1512.910392]  exit_mmap+0xb5/0x1d0
84
[ 1512.910394]  mmput+0x57/0x140
85
[ 1512.910396]  do_exit+0x352/0xb90
86
[ 1512.910402]  do_group_exit+0x43/0xb0
87
[ 1512.910404]  get_signal+0x142/0x7a0
88
[ 1512.910406]  do_signal+0x37/0x720
89
[ 1512.910408]  ? __bad_area_nosemaphore+0xd7/0x1b0
90
[ 1512.910410]  ? printk+0x52/0x6e
91
[ 1512.910411]  ? bad_area_access_error+0x6a/0xb0
92
[ 1512.910412]  ? __do_page_fault+0x1b4/0x4b0
93
[ 1512.910414]  exit_to_usermode_loop+0x73/0xd0
94
[ 1512.910415]  prepare_exit_to_usermode+0x83/0x90
95
[ 1512.910417]  ? page_fault+0x2f/0x50
96
[ 1512.910418]  retint_user+0x8/0x8
97
[ 1512.910419] RIP: 0033:0x7fe21fe2a354
98
[ 1512.910420] RSP: 002b:00007ffcfdb57080 EFLAGS: 00010206
99
[ 1512.910421] RAX: 000055be59680cc0 RBX: 000055be597f27e8 RCX: 0000000000000000
100
[ 1512.910422] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00007fe21fe6cc40
101
[ 1512.910422] RBP: 000055be599378a0 R08: 0000000000000002 R09: 0000000000000000
102
[ 1512.910423] R10: 0000000000000000 R11: 000055be597f2170 R12: 0000000000000004
103
[ 1512.910423] R13: 000000000000000d R14: 000055be597f22ec R15: 0000000000000000
104
[ 1512.910431] BUG: Bad page map in process clock-applet  pte:8000006e1bf818b3 pmd:21fa22067
105
[ 1512.910433] addr:00000000c29fb081 vm_flags:08100073 anon_vma:0000000093da3a82 mapping:          (null) index:55be59740
106
[ 1512.910434] file:          (null) fault:          (null) mmap:          (null) readpage:          (null)
107
[ 1512.910435] CPU: 2 PID: 1366 Comm: clock-applet Tainted: G    B      OE    4.15.0-151-generic #157-Ubuntu
108
[ 1512.910435] Hardware name: FUJITSU LIFEBOOK E746/FJNB292, BIOS Version 1.28 07/28/2020
109
[ 1512.910436] Call Trace:
110
[ 1512.910437]  dump_stack+0x6d/0x8b
111
[ 1512.910438]  print_bad_pte+0x222/0x2e0
112
[ 1512.910439]  ? alloc_pages_current+0x6a/0xe0
113
[ 1512.910441]  _vm_normal_page+0x9c/0x100
114
[ 1512.910442]  unmap_page_range+0x53f/0xd00
115
[ 1512.910443]  unmap_single_vma+0x7d/0xf0
116
[ 1512.910445]  unmap_vmas+0x51/0xb0
117
[ 1512.910446]  exit_mmap+0xb5/0x1d0
118
[ 1512.910448]  mmput+0x57/0x140
119
[ 1512.910449]  do_exit+0x352/0xb90
120
[ 1512.910450]  do_group_exit+0x43/0xb0
121
[ 1512.910451]  get_signal+0x142/0x7a0
122
[ 1512.910453]  do_signal+0x37/0x720
123
[ 1512.910454]  ? __bad_area_nosemaphore+0xd7/0x1b0
124
[ 1512.910455]  ? printk+0x52/0x6e
125
[ 1512.910456]  ? bad_area_access_error+0x6a/0xb0
126
[ 1512.910458]  ? __do_page_fault+0x1b4/0x4b0
127
[ 1512.910459]  exit_to_usermode_loop+0x73/0xd0
128
[ 1512.910460]  prepare_exit_to_usermode+0x83/0x90
129
[ 1512.910461]  ? page_fault+0x2f/0x50
130
[ 1512.910462]  retint_user+0x8/0x8
131
[ 1512.910463] RIP: 0033:0x7fe21fe2a354
132
[ 1512.910463] RSP: 002b:00007ffcfdb57080 EFLAGS: 00010206
133
[ 1512.910464] RAX: 000055be59680cc0 RBX: 000055be597f27e8 RCX: 0000000000000000
134
[ 1512.910465] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00007fe21fe6cc40
135
[ 1512.910465] RBP: 000055be599378a0 R08: 0000000000000002 R09: 0000000000000000
136
[ 1512.910466] R10: 0000000000000000 R11: 000055be597f2170 R12: 0000000000000004
137
[ 1512.910466] R13: 000000000000000d R14: 000055be597f22ec R15: 0000000000000000
138
[ 1512.911670] BUG: Bad rss-counter state mm:000000000c1622b1 idx:1 val:2
139
[ 1513.132330] userif-3: sent link down event.
140
[ 1513.132336] userif-3: sent link up event.
141
[ 1522.847189] /dev/vmmon[0]: HostIFReadUptimeWork: detected settimeofday: fixed uptimeBase old 18445115985198574311 new 18445115985197187751 attempts 1
142
[ 1683.716496] EXT4-fs error (device sda3): ext4_lookup:1590: inode #2102212: comm dpkg: iget: checksum invalid
143
[ 1683.718105] Aborting journal on device sda3-8.
144
[ 1683.718637] EXT4-fs (sda3): Remounting filesystem read-only
145
[ 1683.720149] EXT4-fs error (device sda3): ext4_journal_check_start:61: Detected aborted journal
146
[ 1683.720152] EXT4-fs error (device sda3): ext4_journal_check_start:61: Detected aborted journal
147
[ 1683.727456] EXT4-fs error (device sda3): ext4_lookup:1590: inode #2102212: comm dpkg: iget: checksum invalid
148
[ 1683.898287] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-30]
149
[ 1683.898296] ecryptfs_writepage: Error encrypting page (upper index [0x000000000000003f])
150
[ 1689.018026] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-30]
151
[ 1689.018030] ecryptfs_writepage: Error encrypting page (upper index [0x0000000000000060])
152
[ 1692.339626] WARNING: CPU: 0 PID: 1915 at /build/linux-HN7Wi9/linux-4.15.0/fs/buffer.c:612 __set_page_dirty+0xbb/0xc0
153
[ 1692.339632] Modules linked in: vmnet(OE) vmw_vsock_vmci_transport vsock vmw_vmci vmmon(OE) rfcomm ccm cmac bnep snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic arc4 snd_soc_skl snd_soc_skl_ipc snd_hda_ext_core snd_soc_sst_dsp snd_soc_sst_ipc snd_soc_acpi snd_soc_core snd_compress ac97_bus snd_pcm_dmaengine snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep qcserial usb_wwan intel_rapl usbserial x86_pkg_temp_thermal intel_powerclamp coretemp snd_pcm cdc_mbim kvm_intel cdc_wdm cdc_ncm usbnet mii snd_seq_midi kvm snd_seq_midi_event irqbypass crct10dif_pclmul crc32_pclmul uvcvideo videobuf2_vmalloc videobuf2_memops ghash_clmulni_intel iwlmvm videobuf2_v4l2 intel_cstate videobuf2_core btusb mac80211 btrtl intel_rapl_perf snd_rawmidi btbcm btintel bluetooth videodev ecdh_generic media snd_seq
154
[ 1692.339730]  iwlwifi snd_seq_device snd_timer snd input_leds joydev cfg80211 serio_raw intel_wmi_thunderbolt soundcore shpchp mei_me mei mac_hid acpi_pad fujitsu_laptop sparse_keymap pcbc aesni_intel crypto_simd glue_helper cryptd aes_x86_64 dm_crypt sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq dm_mirror dm_region_hash dm_log i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ahci e1000e psmouse drm sdhci_pci ptp pps_core sdhci libahci wmi video
155
[ 1692.339814] CPU: 0 PID: 1915 Comm: HangWatcher Tainted: G    B      OE    4.15.0-151-generic #157-Ubuntu
156
[ 1692.339818] Hardware name: FUJITSU LIFEBOOK E746/FJNB292, BIOS Version 1.28 07/28/2020
157
[ 1692.339827] RIP: 0010:__set_page_dirty+0xbb/0xc0
158
[ 1692.339832] RSP: 0000:ffffb63fc2cd7ca8 EFLAGS: 00010046
159
[ 1692.339840] RAX: 0017ffffc0000071 RBX: ffffee71872aa1c0 RCX: 0000000000000000
160
[ 1692.339844] RDX: 0000000000000000 RSI: ffff8e2e50f1dd80 RDI: ffff8e2e50f1dd98
161
[ 1692.339849] RBP: ffffb63fc2cd7cd0 R08: 8000000000000825 R09: 00000000610aaf51
162
[ 1692.339853] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8e2e50f1dd80
163
[ 1692.339857] R13: ffff8e2e50f1dd98 R14: 0000000000000246 R15: 0000000000000001
164
[ 1692.339864] FS:  00007fad5f109700(0000) GS:ffff8e2eb2400000(0000) knlGS:0000000000000000
165
[ 1692.339868] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
166
[ 1692.339873] CR2: 00007fad5fe8c450 CR3: 00000001d3320004 CR4: 00000000003606f0
167
[ 1692.339877] Call Trace:
168
[ 1692.339894]  __set_page_dirty_buffers+0xa7/0xf0
169
[ 1692.339907]  set_page_dirty+0x5e/0xb0
170
[ 1692.339918]  filemap_page_mkwrite+0x9d/0xc0
171
[ 1692.339928]  do_page_mkwrite+0x35/0x90
172
[ 1692.339937]  do_wp_page+0x230/0x3f0
173
[ 1692.339948]  __handle_mm_fault+0xa21/0xff0
174
[ 1692.339960]  handle_mm_fault+0xe7/0x260
175
[ 1692.339972]  __do_page_fault+0x281/0x4b0
176
[ 1692.339985]  ? SyS_futex+0x13b/0x180
177
[ 1692.339996]  do_page_fault+0x2e/0xe0
178
[ 1692.340006]  ? page_fault+0x2f/0x50
179
[ 1692.340013]  page_fault+0x45/0x50
180
[ 1692.340021] RIP: 0033:0x559ce946d8cd
181
[ 1692.340025] RSP: 002b:00007fad5f108910 EFLAGS: 00010206
182
[ 1692.340030] RAX: 00007fad5fe8c450 RBX: 0000000000000000 RCX: 0000000000000001
183
[ 1692.340034] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000b6e01895a40
184
[ 1692.340038] RBP: 00007fad5f108940 R08: 00007fad5f1088bc R09: 0000000000000080
185
[ 1692.340042] R10: 00007fad5f108930 R11: 0000000000000001 R12: 0000000000000000
186
[ 1692.340045] R13: 0000000000000001 R14: 00000b6e01895a40 R15: 0000000000000001
187
[ 1692.340052] Code: 4c 89 f6 4c 89 ef e8 15 ca 70 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 48 8b 00 f6 c4 02 74 d2 48 89 df e8 5a 49 f7 ff 48 89 c6 eb c9 <0f> 0b eb 8d 90 0f 1f 44 00 00 55 48 89 e5 41 55 41 54 53 48 89 
188
[ 1692.340138] ---[ end trace 366cd2d96f68069e ]---
189
[ 1694.137869] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-30]
190
[ 1694.137935] ecryptfs_writepage: Error encrypting page (upper index [0x000000000000003f])
191
[ 1694.137955] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-30]
192
[ 1694.137982] ecryptfs_writepage: Error encrypting page (upper index [0x0000000000000060])
193
[ 1704.377530] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-30]
194
[ 1704.377549] ecryptfs_writepage: Error encrypting page (upper index [0x0000000000000002])
195
[ 1704.377649] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-30]
196
[ 1704.377657] ecryptfs_writepage: Error encrypting page (upper index [0x0000000000000003])
197
[ 1704.377743] ecryptfs_encrypt_page: Error attempting to write lower page; rc = [-30]
198
[ 1704.377750] ecryptfs_writepage: Error encrypting page (upper index [0x0000000000000013])

von Marcello E. (leto)


Lesenswert?

Ich vermute immer noch TPM als Schuldigen. Ich würde das System mit 
ausgeschalteten TPM nochmal aufsetzen. Also keine Verschlüsselung und 
TPM auf aus.

von Reinhard S. (rezz)


Angehängte Dateien:

Lesenswert?

Nano schrieb:
> Jack V. schrieb:
>> Wenn ein Schaden am SSD vermutet wird, so wäre ein Blick in die
>> SMART-Daten, sowie ein SMART-Selbsttest, anzuraten. Das Werkzeug hierfür
>> wäre ›smartctl‹.

Selbsttests werden demnach von der SSD nicht unterstützt. Im Anhang die 
Ausgabe von smartctl -x

> So sehe ich das auch und dann wäre noch ein Blick in die fstab sinnvoll
> um zu sehen, mit welchen Parametern die Linux Partition auf der SSD
> eingebunden wurde.

> UUID=xxxxx /  ext4    errors=remount-ro 0       1

von Reinhard S. (rezz)


Lesenswert?

Marcello E. schrieb:
> Ich vermute immer noch TPM als Schuldigen. Ich würde das System mit
> ausgeschalteten TPM nochmal aufsetzen. Also keine Verschlüsselung und
> TPM auf aus.

Da der Fehler mit ausgeschaltetem TPM auch auftrat seh ich das TPM da 
recht schuldfrei. Die Verschlüsselung vom home-Verzeichnis sollte ja 
unabhängig davon laufen.

von Marcello E. (leto)


Lesenswert?

Reinhard S. schrieb:
> Marcello E. schrieb:
>> Ich vermute immer noch TPM als Schuldigen. Ich würde das System mit
>> ausgeschalteten TPM nochmal aufsetzen. Also keine Verschlüsselung und
>> TPM auf aus.
>
> Da der Fehler mit ausgeschaltetem TPM auch auftrat seh ich das TPM da
> recht schuldfrei. Die Verschlüsselung vom home-Verzeichnis sollte ja
> unabhängig davon laufen.

Der Fehler kann auftauchen wenn keine Gesamtverschlüsselung des 
Laufwerks läuft.
Also nur das Home Verzeichnis verschlüsselt ist.

von Marcello E. (leto)


Lesenswert?

Aber die Sache könnte laut askubuntu auch an ner kaputten Platte usw 
liegen.

von Marcello E. (leto)


Lesenswert?

Also

apt-get install smartmontools
smartctl -a /dev/sda

von Jack V. (jackv)


Lesenswert?

Reinhard S. schrieb:
> Selbsttests werden demnach von der SSD nicht unterstützt.

Steht da nicht. Da steht, dass selektive Tests nicht unterstützt werden. 
Außerdem steht da, dass du ’ne sehr alte Version von smartctl nutzt (gut 
– ist ja auch ein sehr altes System), und dein SSD nicht in dessen 
Datenbank ist – die ist von 2016, das Gerät kam 2017 auf den Markt, wenn 
ich das auf die Schnelle richtig gesehen habe.

Ansonsten sieht die Textwüste oben, die ebenfalls viel besser in eine 
Textdatei gepasst hätte, danach aus, dass es zunächst ein Problem mit 
der Uhr gibt, was in Folge falsche Timestamps und Checksummen 
produziert. Ist durch das Quetschen in den Beitrag leider nicht ganz so 
gut lesbar, so dass ich nicht genauer geschaut habe.

: Bearbeitet durch User
von Jens G. (jensig)


Lesenswert?

>BUG: Bad page map in process clock-applet

Das Problem dürfte nicht das clock-applet selbst sein (ist sozusagen nur 
ein Opfer), sondern liegt mit rel. großer Wahrscheinlichkeit am Kernel, 
oder evtl. auch RAM-Problem.
Ich würde mal eine andere Linuxversion (bzw. anderen Kernel) 
installieren, und schauen, ob es immer noch auftritt.

von Marcello E. (leto)


Lesenswert?

Jens G. schrieb:
>>BUG: Bad page map in process clock-applet
>
> Das Problem dürfte nicht das clock-applet selbst sein (ist sozusagen nur
> ein Opfer), sondern liegt mit rel. großer Wahrscheinlichkeit am Kernel,
> oder evtl. auch RAM-Problem.
> Ich würde mal eine andere Linuxversion (bzw. anderen Kernel)
> installieren, und schauen, ob es immer noch auftritt.

Das Problem ist bei älteren Versionen bekannt. Ich denke der Königsweg 
(um alles auszuschliessen) ist:
TPM auf aus
Verschlüsselung auf aus
An besten aktuelle Version installieren (ab 20.04)

: Bearbeitet durch User
von Schlaumaier (Gast)


Lesenswert?

So ein ähnlichen Theater hatte ich neulich auch.

Da war plötzlich auch alles READ-Only, bei einen Zugriff von 
Außerhalb(Windows-System im lokalen Netzwerk). Irgendwie hat Samba den 
Zugang des Users gekillt.

Was mich auf den Gedanken bringt, das vielleicht die Rechteverwaltung 
ein Schuss weg hat. Einfach gesagt, du bist auf deinen Rechner nur der 
niedrigste aller Gäste. Es kann z.b. in der Mountdatei der Festplatte 
ein paar Fehler drin sein.

Ist aber nur so ein Gedanke.

Weil aus Erfahrung weiß ich, das es gewisse Dateien gibt, wenn die eine 
Datenstörung haben, das ganze System crasht. Bis Win-2000 habe ich z.b. 
immer ein PRG laufen, das jeden Morgen die Registry-Dateien gesichert 
hat.

Wenns nicht lief : Von Diskette starten, sicherheitscopy zurück und das 
System lief wie eine 1.

Das ganze kann bei JEDES OS auftreten. Also mein Tipp. Versuch dir mal 
einige der Dateien mal anzusehen. Wenn in einer Text-Datei plötzlich 
Hieroglyphen auftauchen, dann hast du mit 99% Wahrscheinlichkeit den 
Fehler gefunden.

IST ABER WIE GESAGT NUR SO EIN GEDANKE Ferndiagnosen sind immer 
Problematisch.  An ein Hardware-Defekt glaube ich aus Erfahrung NIE. 
Halb schwanger gibt es im PC-Bereich nicht. Und ein Ram-Fehler würde 
immer zu anderen Fehlern führen. Sobald ein Fehler reproduzierbar ist, 
liegt er sehr sehr sehr selten an der Hardware.

Ich hatte bei einigen 100 Rechnern noch NIE einen Hardware-Fehler wenn 
die Kiste es geschafft hat, mir den Start-Bildschirm des Bios 
anzuzeigen.

von Jack V. (jackv)


Lesenswert?

@TE: besser ’nen neuen Thread aufmachen. Du hast dir nun leider ’nen 
Schlaumaier eingtreten – der geht nicht wieder raus :(

von Marcello E. (leto)


Lesenswert?

Jack V. schrieb:
> @TE: besser ’nen neuen Thread aufmachen. Du hast dir nun leider ’nen
> Schlaumaier eingtreten – der geht nicht wieder raus :(

Bei einem muss ich (leider) Schlaumaier recht geben. Es ist meistens 
nicht die Hardware. Was ich schon vor der Mülltonne gerettet habe.

von M.M.M (Gast)


Lesenswert?

Reinhard S. schrieb:
> Der Fehler ist grad wieder aufgetreten, da ich aber die dmesg-Meldungen
> nicht mehr auf Platte speichern kann (read-only...) hier der Spaß:

Sieht nach Speicherfehler aus. Für den Anfang mal den/die Speicherriegel 
entfernen und wieder einstecken. Wenn mehrere Speicherriegel vorhanden 
sind, dann mal mit einzelnen Riegeln arbeiten.

Tritt der Fehler immer beim selben Prozess auf?

Versuchsweise auch mal mit einem anderen Kernel starten.

MfG

von Reinhard S. (rezz)


Lesenswert?

Jack V. schrieb:
> Reinhard S. schrieb:
>> Selbsttests werden demnach von der SSD nicht unterstützt.
>
> Steht da nicht. Da steht, dass selektive Tests nicht unterstützt werden.
> Außerdem steht da, dass du ’ne sehr alte Version von smartctl nutzt (gut
> – ist ja auch ein sehr altes System), und dein SSD nicht in dessen
> Datenbank ist – die ist von 2016, das Gerät kam 2017 auf den Markt, wenn
> ich das auf die Schnelle richtig gesehen habe.

Das ist halt die Version, die mir apt-get heute untergejubelt hat.

> Ansonsten sieht die Textwüste oben, die ebenfalls viel besser in eine
> Textdatei gepasst hätte,

War der Plan, aber wenn dein Dateisystem read-only ist kann man halt 
keine neuen Dateien anlegen und muss es so machen.

> danach aus, dass es zunächst ein Problem mit
> der Uhr gibt, was in Folge falsche Timestamps und Checksummen
> produziert.

Das ist richtig, aber ich denke, die Uhr war da halt nur der erste 
Leidtragende. Davor wars dpkg mit dem Paketspeicher oder auch sonstwas, 
was gerne schreiben will.

M.M.M schrieb:
> Tritt der Fehler immer beim selben Prozess auf?

Nicht, das ich das so mitbekomme. Der Fehler (Dateisystem plötzlich 
read-only) tritt einfach auf und irgendwas meckert dann halt zuerst.

> Versuchsweise auch mal mit einem anderen Kernel starten.

Kann ich probieren, die ganzen Vorgängerversionen sind ja auch noch 
installiert. Mach ich mir aber erstmal weniger Hoffnungen, die TB-SSD 
ist auch bereits bestellt.

Marcello E. schrieb:
> Also
>
> apt-get install smartmontools
> smartctl -a /dev/sda

Der Anhang von smartctl -x ist meinem Verständnis nach ausführlicher als 
smartctl -a.

: Bearbeitet durch User
von Jack V. (jackv)


Lesenswert?

Reinhard S. schrieb:
> Das ist halt die Version, die mir apt-get heute untergejubelt hat.

Du könntest es zum Anlass nehmen, mal auf eine aktuelle 
Betriebssystemversion zu wechseln.

Reinhard S. schrieb:
> War der Plan, aber wenn dein Dateisystem read-only ist kann man halt
> keine neuen Dateien anlegen und muss es so machen.

Da hätte es verschiedene Möglichkeiten gegeben: hochladen auf eine 
dieser pastebin-Seiten, speichern auf einem externen Datenträger 
(USB-Stick, o.ä.), via ssh auf einen anderen Rechner schreiben, 
versuchen, das lokale FS  wieder beschreibbar zu mounten (ggf. nach 
einem fsck), …

Reinhard S. schrieb:
> ich denke, die Uhr war da halt nur der erste
> Leidtragende.

Ich hätte derzeit zwei Favouriten (von denen man zumindest eins gut 
abklären kann):

a) RAM – lässt sich mit memtest86 prüfen, dauert nur etwas
b) Netzteil – Spannungsschwankungen können durchaus zu solchen 
Fehlerbildern führen. Prüfen ließe es sich am einfachsten, indem es 
testweise durch ein anderes Netzteil ersetzt wird.

Dass es das SSD ist, glaube ich nicht – das verursacht keine Segfaults 
bei Sachen, die damit grad nix zu tun haben. CPU/Microcode wäre möglich, 
aber dann wäre das Verhalten schon vorher zu beobachten gewesen.

von (prx) A. K. (prx)


Lesenswert?

Reinhard S. schrieb:
> Im Normalbetrieb meint es plötzlich nicht mehr schreiben zu können, da
> das Dateisystem read-only ist.

Das kann eine Linux-typische Notreaktion auf erkannte Fehler sein.

Ich hatte mit ein paar alten Servern gleichen Typs zu tun, bei denen 
nach vielen Jahren die Netzteile reihum Unterspannung auf 5V 
entwickelten. Diese Spannung wird seit langem praktisch nur noch im 
Storage-Bereich ernsthaft genutzt (und bei USB), der Rest vom Board 
nutzt grösstenteils 12V oder 3,3V.

Wenn es dann sporadische Probleme im I/O-Bereich gab, dann stellten die 
Windows-Server sehr vernehmlich den Betrieb ein. Die Linux-Kisten 
schienen jedoch seelenruhig weiter zu arbeiten, Ping OK, Webserver 
ansprechbar etc. Bloss war das Root-Filesystem auf read-only, um 
Schlimmeres zu verhindern.

Das soll nun keine neue Theorie dessen sein, was hier los ist, und dass 
es unbedingt das Netzteil sei. Möglich wärs aber auch.

: Bearbeitet durch User
Beitrag #6780043 wurde von einem Moderator gelöscht.
Beitrag #6780044 wurde von einem Moderator gelöscht.
von Nano (Gast)


Lesenswert?

Rudi Ratlos schrieb im Beitrag #6780044:
> Reinhard S. schrieb:
>> da das parallel installierte  Win7 wie immer läuft.
>
> Ich empfehle dir, von solchen Doppel-Vierfachboot-Konfigurationen
> Abstand zu nehmen. Das betrifft auch Linux-Distros. Das führt bei
> kleinsten Problemen zu noch viel mehr Problemen, oft unlösbaren
> Problemen.
>
> OneDisc - OneSystem
>
> -Ich- bringe verschiedene Systeme niemals in Berührung miteinander.

Quatsch!

Ich Dualboote schon seit über 20 Jahren und hatte nie nennenswerte 
Probleme.

Die Systeme kommen sich auch nicht ins Gehege, da die alle auf ihren 
eigenen Partitionen liegen.

Windows Systeme dürfen bei mir nie auf die ext* Partition des Linux 
Systems zugreifen. Wenn, dann nur Linux auf die NTFS Partition.
Also installiere ich auch keine ext* Treiber unter Windows.

Der einzige Punkt wo es mal früher ne Weile Probleme gab, war bei der 
Systemzeit. Das konnte ich aber lösen.

Sowie den Daten für den TV-Browser. Das war nur lösbar, in dem die Daten 
nicht geteilt genutzt werden.

Ein E-Mail Client wird bei mir nur unter Linux benutzt. Ein Austausch 
findet hier also nicht statt. Also gibt's da auch kein Problem.
Wenn ich mal unter Windows die Mails checken muss, geh ich ins 
Webinterface.

Für die Lesezeichen im Browser gibt es Firefox Sync.
Browsererweiterungen, PW, Cookies und offene Sitzungen werden bei mir 
über FF Sync nicht geteilt.
Also nur die Lesezeichen und Symbolleiste und funktioniert sehr gut über 
mehrere Rechner hinweg.


Eine weitere Linux Distribution nutze ich nicht. Würde ich es machen, 
dann würde sie ihre eigenen Partitionen für /, /usr, /var und /home 
bekommen.
Letzteres auch, weil Programmversionen sich unterscheiden können.
Da ist es nicht gut, wenn dann verschiedene Versionen auf die gleichen 
/home Daten zutreifen.

von Andreas B. (bitverdreher)


Lesenswert?

Rudi Ratlos schrieb im Beitrag #6780044:
> Ich empfehle dir, von solchen Doppel-Vierfachboot-Konfigurationen
> Abstand zu nehmen.
Warum? Weil Du mit Bootmanagern nicht umgehen kannst?

> Linux-Distributionen mit so einem DistroMüll noch abgibt, ist die Frage.
Weil Mint hervorragend funktioniert. Ich nutze es seit Mint15 und bin 
jetzt bei 20.2.

> -Ich- bringe verschiedene Systeme niemals in Berührung miteinander.
Schön für Dich. Es könnten ja Viren von der Win auf die Linux Partition 
überspringen, nicht?

Nano schrieb:
> Windows Systeme dürfen bei mir nie auf die ext* Partition des Linux
> Systems zugreifen.
Soweit kommts noch. ;-)
Ich selbst habe Win nur auf virtuellen Maschinen am laufen, falls ich 
mal was ausprobieren will.

Nano schrieb:
> Eine weitere Linux Distribution nutze ich nicht. Würde ich es machen,
> dann würde sie ihre eigenen Partitionen für /, /usr, /var und /home
> bekommen.
> Letzteres auch, weil Programmversionen sich unterscheiden können.
> Da ist es nicht gut, wenn dann verschiedene Versionen auf die gleichen
> /home Daten zutreifen.
Ja, da habe ich auch noch keine wirklich zufriedenstellende Lösung 
gefunden. Das einzige was mir dazu einfiel, eine extra Datenpartition 
einzurichten, die dann in das home als ein extra Verzeichnis gemountet 
wurde. Man muß dann halt immer eine Ebene tiefer gehen um an seine Daten 
dran zukommen.
Da andere Distris aber sowieso nur testweise laufen, mache ich das 
umgekehrt und mounte dort meine home Partition in ein home Verzeichnis 
der Testdistri.

von Nano (Gast)


Lesenswert?

Andreas B. schrieb:
> Da andere Distris aber sowieso nur testweise laufen, mache ich das
> umgekehrt und mounte dort meine home Partition in ein home Verzeichnis
> der Testdistri.

Distris die ich nur mal kurz ausprobieren will, kommen bei mir einfach 
in eine VM.

Beitrag #6780067 wurde von einem Moderator gelöscht.
Beitrag #6780070 wurde von einem Moderator gelöscht.
Beitrag #6780072 wurde von einem Moderator gelöscht.
von Dieter (Gast)


Lesenswert?

Reinhard S. schrieb:
> 8445115985197187751 attempts 1
> [ 1683.716496] EXT4-fs error (device sda3): ext4_lookup:1590: inode
> #2102212: comm dpkg: iget: checksum invalid
> [ 1683.718105] Aborting journal on device sda3-8.
> [ 1683.718637] EXT4-fs (sda3): Remounting filesystem read-only

Da tritt der Fehler auf.

von (prx) A. K. (prx)


Lesenswert?

Nano schrieb:
> Ein E-Mail Client wird bei mir nur unter Linux benutzt. Ein Austausch
> findet hier also nicht statt.

Bei POP3 ist das ein Problem.

Mit IMAP können auch mehrere Clients lesend aufs gleiche Postfach, ohne 
dass die sich gegenseitig Daten klauen. Seit Jahren kein Problem, bei 
Thunderbird (Windows/Linux), Evolution (Linux) sowie Nine und K-9 
(Android).

Es kann lediglich geschehen, dass ein paar Systemordner wie etwa für 
gesendete Mail in Clients und im Webinterface von Haus aus 
unterschiedlich sind.

: Bearbeitet durch User
von Nano (Gast)


Lesenswert?

(prx) A. K. schrieb:
> Nano schrieb:
>> Ein E-Mail Client wird bei mir nur unter Linux benutzt. Ein Austausch
>> findet hier also nicht statt.
>
> Bei POP3 ist das ein Problem.
>
> Mit IMAP können auch mehrere Clients lesend aufs gleiche Postfach, ohne
> dass die sich gegenseitig Daten klauen. Seit Jahren kein Problem, bei
> Thunderbird (Windows/Linux), Evolution (Linux) sowie Nine und K-9
> (Android).

Ja, ich nutze POP3.
Früher ging es nicht anders, heute mache ich es aus Gewohnheit.
Außerdem weiß ich auch nicht, ob GMX inzwischen IMAP für Freemails 
anbietet.

von (prx) A. K. (prx)


Lesenswert?

Nano schrieb:
> Distris die ich nur mal kurz ausprobieren will, kommen bei mir einfach
> in eine VM.

Eine bekannte Distro ist erstaunlicherweise zickig, auch heute noch. 
Manjaro oder Arch, weiss nicht mehr welche.

von Andreas B. (bitverdreher)


Lesenswert?

Nano schrieb:
> Außerdem weiß ich auch nicht, ob GMX inzwischen IMAP für Freemails
> anbietet.

Tut es, zumindest für die alten Accounts:
imap.gmx.net, port 143, StartTTLS nach verbinden
mail.gmx.net, port 587, StartTTLS nach verbinden

von (prx) A. K. (prx)


Lesenswert?

Manjaro ist es, in VMware. Da geht von Haus aus nichts in der VM

von (prx) A. K. (prx)


Lesenswert?

Nano schrieb:
> Außerdem weiß ich auch nicht, ob GMX inzwischen IMAP für Freemails
> anbietet.

Das taten die schon seit langer Zeit, obwohl es für Freemail nicht 
offiziell war. Ich hatte es einfach ausprobiert.

: Bearbeitet durch User
von Nano (Gast)


Lesenswert?

Andreas B. schrieb:
> Nano schrieb:
>> Außerdem weiß ich auch nicht, ob GMX inzwischen IMAP für Freemails
>> anbietet.
>
> Tut es, zumindest für die alten Accounts:
> imap.gmx.net, port 143, StartTTLS nach verbinden
> mail.gmx.net, port 587, StartTTLS nach verbinden

Danke für die Info.

Mal schauen. Für Windows würde es sich anbieten.
Den Mailclient unter Linux werde ich aber wohl mit POP3 so lassen wir er 
ist. Dann muss ich mir auch keine Gedanken darüber machen, dass mein GMX 
Postfach nicht überläuft.

Beitrag #6780120 wurde von einem Moderator gelöscht.
von (prx) A. K. (prx)


Lesenswert?

Nano schrieb:
> dass mein GMX Postfach nicht überläuft.

Wobei 3€ im Monat für GMX ProMail auch nicht arm machen. Da hast du dann 
auch mehr Platz.

: Bearbeitet durch User
Beitrag #6780190 wurde von einem Moderator gelöscht.
von Reinhard S. (rezz)


Lesenswert?

Jack V. schrieb:
> Reinhard S. schrieb:
>> Das ist halt die Version, die mir apt-get heute untergejubelt hat.
>
> Du könntest es zum Anlass nehmen, mal auf eine aktuelle
> Betriebssystemversion zu wechseln.

Mint 19.2 hat Support bis 2023. Insofern seh ich da noch keinen 
dringenden Handlungsbedarf. Auch wenn smartmontools von 2016 nicht für 
den Support sprechen, aber das ist eine andere Baustelle.

> Reinhard S. schrieb:
>> War der Plan, aber wenn dein Dateisystem read-only ist kann man halt
>> keine neuen Dateien anlegen und muss es so machen.
>
> Da hätte es verschiedene Möglichkeiten gegeben: hochladen auf eine
> dieser pastebin-Seiten, speichern auf einem externen Datenträger
> (USB-Stick, o.ä.), via ssh auf einen anderen Rechner schreiben,
> versuchen, das lokale FS  wieder beschreibbar zu mounten (ggf. nach
> einem fsck), …

Ok ok, es hätte also Möglichkeiten gegeben. Pastebin hab ich bisher 
allerdings nie benutzt und ein anderer Rechner war mir zu umständlich. 
Das lokale FS wieder schreibbar zu mounten klappt nach einem fsck, aber 
dazwischen lag bis jetzt halt immer ein Neustart...

> Reinhard S. schrieb:
>> ich denke, die Uhr war da halt nur der erste
>> Leidtragende.
>
> Ich hätte derzeit zwei Favouriten (von denen man zumindest eins gut
> abklären kann):
>
> a) RAM – lässt sich mit memtest86 prüfen, dauert nur etwas

Muss ich mal ausprobieren, wenn ich Zeit hab. Ist bei Mint ja 
praktischerweise gleich im Bootmenü auswählbar.

> b) Netzteil – Spannungsschwankungen können durchaus zu solchen
> Fehlerbildern führen. Prüfen ließe es sich am einfachsten, indem es
> testweise durch ein anderes Netzteil ersetzt wird.

Möchte ich ausschließen, da der Laptop meiner Erinnerung nach mindestens 
beim letzten Auftreten des Fehlers nicht am Netzteil hing.

> Dass es das SSD ist, glaube ich nicht – das verursacht keine Segfaults
> bei Sachen, die damit grad nix zu tun haben. CPU/Microcode wäre möglich,
> aber dann wäre das Verhalten schon vorher zu beobachten gewesen.

: Bearbeitet durch User
von Schlaumaier (Gast)


Lesenswert?

(prx) A. K. schrieb:
> Wobei 3€ im Monat für GMX ProMail auch nicht arm machen. Da hast du dann
> auch mehr Platz.

Ich habe GMX-pro schon seit grob geschätzt 20 Jahren. Wenn ich die 
E-Mails alle auf den Server lassen würde aus der Zeit wäre ich bei ca. 
3-400 GB. Das wird ein teurer Spass.

Meine Mobil-Teile machen alle imap und auf den PC wird via smtp alles 
abgerufen und von Server gelöscht. Und dank der Organisation / Funktion 
von THE-BAT kann ich zu alte Mails auslagern + mit einen einfachen 
Copy-Befehl wieder zuladen wenn ich das will.

*---------------

Wenn Fehler bei einen System plötzlich auftauchen, würde ich immer 
zuerst mein Augenmerk auf die Temperatur im Rechner lenken.

Speicher haben nicht plötzlich ohne Grund kein Bock. Ich habe auf meinen 
Mint ein kleinen PRG. laufen mit den ich die Last und die Temperatur 
einstellen kann. Ich würde empfehlen so was mal zu installieren.

Es würde schon reichen wenn ein Update ein Fehler im CPU-Treiber 
installiert hat, das AMD = Quiet and cool // Intel hat was ähnliches 
irgendwie "stört".

Also wenn das auftritt (ich hoffe es ist kein Laptop) einfach mal ein 
Temperatur-Laser-Messgerät rein halten und schauen was da an Hitze 
anfällt.


Auch wenn alle behaupten es gibt eine Viren unter Linux. So besteht auch 
die Möglichkeit das ein Linux-Sicherheitssystem so was  glaubt und 
einfach alles dicht macht.

von (prx) A. K. (prx)


Lesenswert?

Schlaumaier schrieb:
> auf den PC wird via smtp alles abgerufen und von Server gelöscht

Klar doch. Per SMTP abgerufen.

von Dieter (Gast)


Lesenswert?

(prx) A. K. schrieb:
> SMTP

SSMTP

von (prx) A. K. (prx)


Lesenswert?

Dieter schrieb:
>> SMTP
>
> SSMTP

Sendet, holt nicht ab.

von Dieter (Gast)


Lesenswert?

Es ist dennoch ein Ableben der SSD Zellen auszuschliessen. Es kann sein, 
dass die SSD zu lange benoetigt bis zum Feedback der Schattensegmente, 
die fuer defekte Segmente einspringen.

von Thomas K. (thomas2021)


Lesenswert?

Reinhard S. schrieb:
> Hat hier jemand hilfreiche Tips?

Windows installieren

von Dieter (Gast)


Lesenswert?

Dieter schrieb:
> SSD Zellen auszuschliessen

Sorry, sollte
nicht auszuschliessen
lauten.

von Marcello E. (leto)


Lesenswert?

Thomas K. schrieb:
> Reinhard S. schrieb:
>> Hat hier jemand hilfreiche Tips?
>
> Windows installieren

Hab hier schon mal gesagt. Der Lösungsweg ist Mit ausgeschaltetem TPM 
und Verschlüsselung ein aktuelles System neu aufsetzen.
Mehr sag ich jetzt nimmer.

von Schlaumaier (Gast)


Lesenswert?

(prx) A. K. schrieb:
> Dieter schrieb:
>>> SMTP
>>
>> SSMTP
>
> Sendet, holt nicht ab.

jojo. ich hab die Protokolle vertauscht. POP3 (Port 905) abholen, SMTP 
(port 465) abholen.  SORRY.

Aber darum geht es ja hier nicht wirklich.

von blank (Gast)


Lesenswert?

Vor einer Neuinstallation vielleicht doch mal ein SMART Selbsttest 
durchführen.
z.B. mit GSmartcontroll mit sudo aufrufen, Drive Datenbank updaten, ich 
würde einen "extended selftest" starten (ich schätze mal 1-2h) er zeigt 
dir aber vorher an wie lange das dauert. Geht alles auch mit smartctl 
das ist aber manchmal missverstäntlich/unübersichtlich.
Ansonsten: memtest über Nacht.

von Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)


Lesenswert?

Was spuckt den folgender Befehl aus?
sudo tune2fs -l /dev/sda3

Was dabei interessiert wäre:
1
Filesystem state:         clean
2
Errors behavior:          Continue
3
Reserved GDT blocks:      114
4
Mount count:              41
5
Lifetime writes:          1213 GB
6
Journal inode:            8
7
First orphan inode:       1972
8
Default directory hash:   half_md4
9
Journal backup:           inode blocks

von Bauform B. (bauformb)


Lesenswert?

Dieter D. schrieb:
> Errors behavior:          Continue

naja, die Einstellung "errors: remount-ro" hat schon was. Mit "continue" 
machst du doch unbemerkt immer mehr kaputt.

von Hmmm (Gast)


Lesenswert?

Schlaumaier schrieb:
> jojo. ich hab die Protokolle vertauscht. POP3 (Port 905) abholen, SMTP
> (port 465) abholen.  SORRY.

Immer noch falsch (995, und mit SMTP wird nichts abgeholt), aber egal,

Schlaumaier schrieb:
> darum geht es ja hier nicht wirklich.

von Reinhard S. (rezz)


Lesenswert?

Thomas K. schrieb:
> Reinhard S. schrieb:
>> Hat hier jemand hilfreiche Tips?
>
> Windows installieren

Ist ja bereits. Aber Win7 noch produktiv benutzen muss nicht sein.

Dieter D. schrieb:
> Was spuckt den folgender Befehl aus?
> sudo tune2fs -l /dev/sda3
>
> Was dabei interessiert wäre:
>
1
> Filesystem state:         clean
2
> Errors behavior:          Continue
3
> Reserved GDT blocks:      114
4
> Mount count:              41
5
> Lifetime writes:          1213 GB
6
> Journal inode:            8
7
> First orphan inode:       1972
8
> Default directory hash:   half_md4
9
> Journal backup:           inode blocks
10
>
1
tune2fs 1.44.1 (24-Mar-2018)
2
Filesystem revision #:    1 (dynamic)
3
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
4
Filesystem flags:         signed_directory_hash 
5
Default mount options:    user_xattr acl
6
Filesystem state:         clean
7
Errors behavior:          Continue
8
Reserved block count:     4246526
9
Free blocks:              6559265
10
Free inodes:              19355644
11
First block:              0
12
Block size:               4096
13
Fragment size:            4096
14
Group descriptor size:    64
15
Reserved GDT blocks:      1002
16
Inodes per group:         8192
17
Inode blocks per group:   512
18
Flex block group size:    16
19
Mount count:              4
20
Maximum mount count:      -1
21
Last checked:             Wed Aug  4 17:29:23 2021
22
Check interval:           0 (<none>)
23
Lifetime writes:          6403 GB
24
Journal inode:            8
25
First orphan inode:       8615373
26
Default directory hash:   half_md4
27
Journal backup:           inode blocks
28
Checksum type:            crc32c
29
Checksum:                 0x62699e3b

Ich hab jetzt auch mal memtest86+ 5.01 laufengelassen für 6 1/2 Stunden 
(mindestens 1 Pass ging durch), keine Fehler.

von Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)


Lesenswert?

Reinhard S. schrieb:
> Lifetime writes:          6403 GB

Reinhard S. schrieb:
> Auf der 317-GB-Partition sind laut
> Systemüberwachung 29 GB "frei" und 12 GB "verfügbar",

Wenn schon sehr lange nur noch so wenig Platz auf der SSD gewesen sein 
sollte, dann dürfte nun der Flash am Ende sein.


Reinhard S. schrieb:
> NAME      TYPE      SIZE USED PRIO
> /dev/dm-0 partition   2G 120K   -2

Da wird noch LVM bei Dir verwendet. Es ist Teil des Device Mapper im 
Kernel, der von LVM verwendet wird.

https://superuser.com/questions/131519/what-is-this-dm-0-device/131520

Mehr Infos bekommst Du über:
sudo dmsetup info /dev/dm-0
sblk --output NAME,KNAME,TYPE,SIZE,MOUNTPOINT

von Reinhard S. (rezz)


Lesenswert?

Dieter D. schrieb:
> Reinhard S. schrieb:
>> Lifetime writes:          6403 GB
>
> Reinhard S. schrieb:
>> Auf der 317-GB-Partition sind laut
>> Systemüberwachung 29 GB "frei" und 12 GB "verfügbar",
>
> Wenn schon sehr lange nur noch so wenig Platz auf der SSD gewesen sein
> sollte, dann dürfte nun der Flash am Ende sein.

Ja, der Speicherplatz ist schon länger so knapp. Haufen Gedöhns, eine 
Win7-VM und so... Deshalb wird die TB-SSD auch so eine gute Idee sein.

Die SSD hab ich übrigens im November 2019 gekauft, wie ich grad 
nachgeschaut hab. Da wäre verschlissener Flash meiner Meinung nach ein 
kleines Armutszeugnis. Ob ich da Mint neuinstalliert habe oder via dd 
von der alten (kleinen) SSD kopiert hab kann ich allerdings nicht mehr 
sagen.

Der Fehler ist übrigens grad wieder aufgetreten, diesmal hat 
systemd-journald viele Fehler wegen read-only-FS gebracht. Der fsck-Lauf 
war diesmal auch seeeehr lang.

: Bearbeitet durch User
Beitrag #6781124 wurde von einem Moderator gelöscht.
von Jack V. (jackv)


Lesenswert?

Reinhard S. schrieb:
> Da wäre verschlissener Flash meiner Meinung nach ein
> kleines Armutszeugnis.

Zumindest der SMART-Ausgabe nach deutet nix auf verschlissenen Speicher 
hin. Aber die smartctl-Version ist auch zu alt für das Gerät, und kann 
eine Handvoll Felder nicht interpretieren. Ich weiß nicht, ob eine 
aktuelle Version es könnte – aber es kostet dich nur wenige Minuten, mal 
ein aktuelles Livesystem (etwa grml, da gab’s grad eine neue Version) zu 
booten und damit mal zu schauen.

Rudi Ratlos schrieb im Beitrag #6781124:
> Aber das zu erkennen sind die meisten hierzu jung .

Linuxdistributionen haben weder was mit DOS, noch mit Win zu tun. Aber 
das zu erkennen, bist du wahrscheinlich zu blöd.

: Bearbeitet durch User
von M.M.M (Gast)


Lesenswert?

Dieter D. schrieb:
> Reinhard S. schrieb:
>> Auf der 317-GB-Partition sind laut
>> Systemüberwachung 29 GB "frei" und 12 GB "verfügbar",
>
> Wenn schon sehr lange nur noch so wenig Platz auf der SSD gewesen sein
> sollte, dann dürfte nun der Flash am Ende sein.

Das ist Quatsch, zeigt aber sehr schön, daß Du nicht verstanden hast, 
wie eine SSD funktioniert.

Beitrag #6781316 wurde von einem Moderator gelöscht.
Beitrag #6781319 wurde von einem Moderator gelöscht.
von Hmmm (Gast)


Lesenswert?

Und bevor noch schlaue Haarspalterei kommt: Ja, Windows 3.1 setzte auf 
MS-DOS auf. Aber den DOS-Prompt gab es auch darin schon, natürlich ohne 
Multitasking, weil sich MS-DOS nicht in das kooperative Multitasking von 
Win3.1 reinzwängen liess.

Aber mit Linux hat das alles exakt gar nichts zu tun.

von Andreas B. (bitverdreher)


Lesenswert?

Hmmm schrieb im Beitrag #6781319:
> hast Du nicht die geringste Ahnung.
Hast Du daran irgendwie gezweifelt? Sein Name ist Programm. Er geistert 
schon seit einiger Zeit hier im Forum herum und fällt mir seinem 
profunden Fachwissen auf.

Zum Thema:
Reinhard S. schrieb:
> Ja, der Speicherplatz ist schon länger so knapp. Haufen Gedöhns, eine
> Win7-VM und so...
Unter diesen Umständen würde ich mir eine neue SSD kaufen und ein 
aktuelles Mint 20.2 drauf machen.
Dann kannst Du die SSD ja immer noch als Zweitplatte mit unwichtigen 
Daten austesten.
Und das Netzteil mal testweise tauschen wenn das möglich ist.

: Bearbeitet durch User
Beitrag #6781331 wurde von einem Moderator gelöscht.
Beitrag #6781340 wurde von einem Moderator gelöscht.
Beitrag #6781343 wurde von einem Moderator gelöscht.
von (prx) A. K. (prx)


Lesenswert?

Das ist zwar völlig gaga und klingt mehr nach LSD als nach EDV, aber 
wenn ich den Faden im gleichen Schema aufnehme und weiter spinne, dann 
ist Windows von Version 3.1 seither nicht wirklich weg gekommen. Beweis: 
Bekanntlich ist der aktuelle Windows Server nur ein etwas anders 
parametrisiertes Windows 10. Und der Windows Server hat in seiner 
Core-Version keinerlei GUI, hat lediglich ein Kommandofenster mit 
Powershell. Das ist also ganz offensichtlich nicht anders als das DOS 
von Win 3.1, die unterste Ebene oberhalb des Maschinencodes. Auf das die 
optional installierbare Windows GUI oben draufgesetzt ist, bis hin zur 
sogenannten Desktop Experience. Nur halt in 64 statt 16 Bits.

: Bearbeitet durch User
von Jack V. (jackv)


Lesenswert?

Jaja, und Autos sind auch irgendwie nur Kutschen ohne Pferde – sieht man 
ja daran, dass dort die Räder ähnlich angeordnet, und ebenfalls unten 
sind.

Man kann dem Spinner durchaus 7/10 auf der Trollskala geben – er gibt 
sich viel Mühe mit seinen Beiträgen, und bleibt auch bei Widrigkeiten 
dran. Auch ist das erzeugte Echo sehr hoch, was diese hohe Punktzahl 
rechtfertigt. Leider stört dieser Spinner den Thread und macht’s 
schwierig, das eigentliche Problem zu verfolgen, weswegen er auf der 
Sympathie- und Achtungsskala mittlerweile im zweistelligen negativen 
Bereich angekommen ist. Mittlerweile läuft er sogar dem Schlaumaier den 
Rang in der Unbeliebtheits-Liste ab – wenngleich ich es nicht für 
ausgeschlossen halte, dass Rudibert Alexander Maier von einer Person 
dargestellt wird. Was mich zu der Frage bringt: was hat jemand davon?

: Bearbeitet durch User
von Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)


Lesenswert?

(prx) A. K. schrieb:
> die unterste Ebene oberhalb des Maschinencodes.

So kann das durchaus vereinfacht ausgedrückt werden, auch wenn das nun 
in einer höheren Programmiersprache geschrieben ist, ändert das 
insgesamt nichts wesentlich daran.

M.M.M schrieb:
> Das ist Quatsch, ...

Die SSD kann am Ende sein. Schließlich weiß keiner ob er eine NOR oder 
NAND SLC, MLC, TLC oder QLC hat, sowie welches Bad Block Management 
werkelt. Bei uns im Bereich der IT gibt es SSD, die im dritten Jahr 
ausgefallen sind.

https://www.compuram.de/blog/die-lebensdauer-einer-ssd-wie-lange-haelt-sie-und-was-kann-ich-ihr-gutes-tun/

Beitrag #6781508 wurde von einem Moderator gelöscht.
Beitrag #6781531 wurde von einem Moderator gelöscht.
Beitrag #6781568 wurde von einem Moderator gelöscht.
von Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)


Lesenswert?

Reinhard S. schrieb:
> ich überlege aber trotzdem, mir mal eine größere SSD zuzulegen.

Das wäre sinnvoll nicht nur zu überlegen, sondern zur Tat zu schreiten.
Insbesondere wie viel Zeit Dich das sonst noch kostet.

: Bearbeitet durch User
Beitrag #6781728 wurde von einem Moderator gelöscht.
Beitrag #6782036 wurde von einem Moderator gelöscht.
Beitrag #6782058 wurde von einem Moderator gelöscht.
Beitrag #6782128 wurde von einem Moderator gelöscht.
von Jack V. (jackv)


Lesenswert?

Dieter D. schrieb:
> Schließlich weiß keiner ob er eine NOR oder
> NAND SLC, MLC, TLC oder QLC hat

TLC NAND, im Falle des Geräts des TE. Trotzdem sollte die mit 6TB 
written noch nicht durch sein. Und wenn, dann würden die SMART-Werte 
auch anders aussehen. Nein, ich glaube weiterhin nicht daran, dass an 
diesem Fehlerbild das SSD schuld ist, sondern, nachdem die Salamischeibe 
„ist ’n Laptop“ nun endlich auch mal abgeschnitten und serviert worden 
ist, so dass das Netzteil vermutlich als Ursache ausscheidet, an RAM 
oder an CPU (auch die gehen manchmal kaputt).

Beitrag #6782139 wurde von einem Moderator gelöscht.
von gerhard (Gast)


Lesenswert?

Bauform B. schrieb:
> Dieter D. schrieb:
>> Errors behavior:          Continue
>
> naja, die Einstellung "errors: remount-ro" hat schon was. Mit "continue"
> machst du doch unbemerkt immer mehr kaputt.

Ja. Völlig sinnvoll. In /etc/fstab kann man das einstellen.

Wenn die Reifen kaputt sind, kann man natürlich auf auf der Felge 
weiterfahren.

Gerhard

von Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)


Lesenswert?

Jack V. schrieb:
> Salamischeibe ...

Gutes Stichwort, weil es werden noch ein paar Salamischeiben benötigt, 
siehe folgender Postauschnitt (bei dem fehlte ein Buchstabe):

Dieter D. schrieb:
> Mehr Infos bekommst Du über:
sudo dmsetup info /dev/dm-0
lsblk --output NAME,KNAME,TYPE,SIZE,MOUNTPOINT

Die LVM-Swap-Partition würde ich mal genauer ansehen.

Im Betrieb würde ich auch einmal versuchen den Firefox mit 50-100 Tabs 
so richtig aufzupumpen um den Hauptspeicherbereich zu sprengen.

von Reinhard S. (rezz)


Lesenswert?

Dieter D. schrieb:
> Gutes Stichwort, weil es werden noch ein paar Salamischeiben benötigt,
> siehe folgender Postauschnitt (bei dem fehlte ein Buchstabe):
>
> Dieter D. schrieb:
>> Mehr Infos bekommst Du über:
> sudo dmsetup info /dev/dm-0

Spuckt mir aus:
Name:              cryptswap1
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        2
Event number:      0
Major, minor:      253, 0
Number of targets: 1
UUID: CRYPT-PLAIN-cryptswap1

> lsblk --output NAME,KNAME,TYPE,SIZE,MOUNTPOINT

NAME         KNAME TYPE    SIZE MOUNTPOINT
loop0        loop0 loop      2G
└─cryptswap1 dm-0  crypt     2G [SWAP]
sda          sda   disk  447,1G
├─sda1       sda1  part    100M
├─sda2       sda2  part    123G
└─sda3       sda3  part    324G /

> Im Betrieb würde ich auch einmal versuchen den Firefox mit 50-100 Tabs
> so richtig aufzupumpen um den Hauptspeicherbereich zu sprengen.

Boa, da muss ich den ja benutzen.

von Reinhard S. (rezz)


Lesenswert?

Dieter D. schrieb:
> Im Betrieb würde ich auch einmal versuchen den Firefox mit 50-100 Tabs
> so richtig aufzupumpen um den Hauptspeicherbereich zu sprengen.

Sind nur 29 Tabs geworden, aber hat für eine neue Fehlermeldung 
gereicht:
1
[   43.135117] RIP: unmap_page_range+0x8ae/0xd00 RSP: ffffadd14251bc60
2
[   43.135119] ---[ end trace a9446e782331409e ]---
3
[   43.135121] Fixing recursive fault but reboot is needed!
4
[   43.203599] IPv6: ADDRCONF(NETDEV_CHANGE): wlp2s0: link becomes ready
5
[   43.228851] wlp2s0: Limiting TX power to 20 (20 - 0) dBm as advertised by 38:10:d5:bc:84:e2
6
[   43.404070] userif-2: sent link down event.
7
[   43.404075] userif-2: sent link up event.
8
[   44.756157] userif-2: sent link down event.
9
[   44.756163] userif-2: sent link up event.
10
[   68.764607] Valid eCryptfs headers not found in file header region or xattr region, inode 8599874
11
[   71.524868] TCP: wlp2s0: Driver has suspect GRO implementation, TCP performance may be compromised.
12
[  118.529234] Valid eCryptfs headers not found in file header region or xattr region, inode 8599840
13
[  118.597890] Valid eCryptfs headers not found in file header region or xattr region, inode 8599872
14
[  119.883473] Valid eCryptfs headers not found in file header region or xattr region, inode 8599868
15
[ 1020.554627] BUG: Bad page map in process mate-system-mon  pte:8000006e1bf818b3 pmd:2230bc067
16
[ 1020.554631] addr:000000007b642270 vm_flags:08100073 anon_vma:00000000d1886d29 mapping:          (null) index:7f347c040
17
[ 1020.554632] file:          (null) fault:          (null) mmap:          (null) readpage:          (null)
18
[ 1020.554634] CPU: 2 PID: 2833 Comm: mate-system-mon Tainted: G      D    OE    4.15.0-151-generic #157-Ubuntu
19
[ 1020.554635] Hardware name: FUJITSU LIFEBOOK E746/FJNB292, BIOS Version 1.28 07/28/2020
20
[ 1020.554636] Call Trace:
21
[ 1020.554640]  dump_stack+0x6d/0x8b
22
[ 1020.554643]  print_bad_pte+0x222/0x2e0
23
[ 1020.554645]  ? vsnprintf+0xfb/0x510
24
[ 1020.554647]  _vm_normal_page+0x9c/0x100
25
[ 1020.554649]  smaps_pte_range+0x2af/0x620
26
[ 1020.554651]  __walk_page_range+0x489/0x760
27
[ 1020.554652]  walk_page_vma+0x4a/0x60
28
[ 1020.554654]  show_smap.isra.31+0x346/0x450
29
[ 1020.554655]  ? gather_pte_stats+0x3a0/0x3a0
30
[ 1020.554657]  ? gather_hugetlb_stats+0x80/0x80
31
[ 1020.554659]  show_pid_smap+0xe/0x10
32
[ 1020.554661]  seq_read+0xe5/0x450
33
[ 1020.554663]  __vfs_read+0x1b/0x40
34
[ 1020.554664]  vfs_read+0x8e/0x130
35
[ 1020.554666]  SyS_read+0x5c/0xe0
36
[ 1020.554668]  do_syscall_64+0x73/0x130
37
[ 1020.554670]  entry_SYSCALL_64_after_hwframe+0x41/0xa6
38
[ 1020.554671] RIP: 0033:0x7f16f309b184
39
[ 1020.554673] RSP: 002b:00007ffe57905a10 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
40
[ 1020.554674] RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007f16f309b184
41
[ 1020.554675] RDX: 0000000000000400 RSI: 000055cab8481ff0 RDI: 000000000000000d
42
[ 1020.554676] RBP: 000055cab8481ff0 R08: 0000000000000000 R09: 0000000000000000
43
[ 1020.554677] R10: 000055cab84823d9 R11: 0000000000000246 R12: 0000000000000400
44
[ 1020.554678] R13: 00007f16f33732a0 R14: 0000000000000017 R15: 0000000000000000
45
[ 1020.781978] BUG: unable to handle kernel paging request at 0000006e1bf819a3
46
[ 1020.781983] IP: show_smap.isra.31+0x320/0x450

von Reinhard S. (rezz)


Angehängte Dateien:

Lesenswert?

Jack V. schrieb:
> Reinhard S. schrieb:
>> Da wäre verschlissener Flash meiner Meinung nach ein
>> kleines Armutszeugnis.
>
> Zumindest der SMART-Ausgabe nach deutet nix auf verschlissenen Speicher
> hin. Aber die smartctl-Version ist auch zu alt für das Gerät, und kann
> eine Handvoll Felder nicht interpretieren. Ich weiß nicht, ob eine
> aktuelle Version es könnte – aber es kostet dich nur wenige Minuten, mal
> ein aktuelles Livesystem (etwa grml, da gab’s grad eine neue Version) zu
> booten und damit mal zu schauen.

Hab mir grad mal grml runtergeladen, aber smartctl von Dezember 2020 
kann mit der SSD scheinbar auch nicht so viel anfangen.

von Nop (Gast)


Lesenswert?

Walter K. schrieb:

> Im übrigen war es schon immer eine gute Idee, wenn man 5 bis 10% einer
> SSD gar nicht erst nutzt - also beim anlegen der Partitions außen vor
> lässt.

Das ist aus zwei Gründen längst veraltet.

1) SSDs haben von sich aus bereits eine entsprechende Reserve, d.h. die 
100%, die Du als Kunde siehst, sind weniger als die tatsächlich 
vorhandenen 100%.

2) Seit TRIM weiß die SSD, welche Blöcke ungenutzt sind, und kann die 
für wear levelling genauso heranziehen wie eine unallozierte Reserve.

von blank (Gast)


Lesenswert?

Reinhard S. schrieb:
> Hab mir grad mal grml runtergeladen, aber smartctl von Dezember 2020
> kann mit der SSD scheinbar auch nicht so viel anfangen.


Ich habe dank smartctl 7.1
Gerade nur noch nur die smartctl Datenbank aktualisiert:
sudo /usr/sbin/update-smart-drivedb

Was deiner SSD am nächsten kommt ist:

MODEL REGEXP:       OCZ-TRION1[05]0|TOSHIBA-TR150|TOSHIBA Q300( Pro\.)?
FIRMWARE REGEXP:    .*
MODEL FAMILY:       OCZ/Toshiba Trion SSDs
ATTRIBUTE OPTIONS:  167 SSD_Protect_Mode
                    168 SATA_PHY_Error_Count
                    169 Bad_Block_Count
                    173 Erase_Count
                    192 Unexpect_Power_Loss_Ct
                    241 Host_Writes

von Reinhard S. (rezz)


Lesenswert?

Dieter D. schrieb:
> Was spuckt den folgender Befehl aus?
> sudo tune2fs -l /dev/sda3
>
> Was dabei interessiert wäre:
>
1
> Lifetime writes:          1213 GB
2
>

Die neue SSD ist da, das System vom Juni-Backup zurückgespielt. Bis 
jetzt läufts, wenn auch nicht sofort auf Anhieb.

Aber die "Lifetime writes" ist weiterhin bei 6,7TB. :)

Beitrag #6783433 wurde von einem Moderator gelöscht.
Beitrag #6783444 wurde von einem Moderator gelöscht.
Beitrag #6783468 wurde von einem Moderator gelöscht.
von Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)


Lesenswert?

Reinhard S. schrieb:
>> Dieter D. schrieb:
>>> Mehr Infos bekommst Du über:
>> sudo dmsetup info /dev/dm-0
>
> Spuckt mir aus:
> Name:              cryptswap1
> State:             ACTIVE
....
> NAME         KNAME TYPE    SIZE MOUNTPOINT
> loop0        loop0 loop      2G
> └─cryptswap1 dm-0  crypt     2G [SWAP]
> sda          sda   disk  447,1G

Die letzten Tage war ich unterwegs und voll beschäftigt.

Mit dieser Verschachtelung & Verkettung der Swap bin ich jetzt wenig 
bewandert. So wie es aussieht hast Du eine Crypt-Swap das auf einer 
Datei aufsetzt, das selbst ein LVM-Image darstellt, das aus einer oder 
mehreren Dateien bestehen kann um dynamisch mitzuwachsen. Das kann man 
zurückverfolgen über die "mount", bzw. als "mount -o loop ..." verkettet 
wurde.

Reinhard S. schrieb:
> Sind nur 29 Tabs geworden, aber hat für eine neue Fehlermeldung
> gereicht:

Mit den vielen Tabs sollte auch was auf Swap auszulagern erzwungen 
werden. Nach der Fehlermeldung scheint es sich dabei verheddert zu 
haben. Wenn Trim einspringen muss oder andere Fehlerbehebungen, gibt es 
zeitliche Verzögerungen, die crypt-Prozeduren aussteigen lassen können. 
Da komme ich auch nicht mehr weiter, außer etwas zu probieren, zum 
Beispiel dieses swap ganz raus zu werfen, dann ein alte HD als 
swap-Partition mißbrauchen und swap dann ganz neu einzurichten.

Reinhard S. schrieb:
> Aber die "Lifetime writes" ist weiterhin bei 6,7TB. :)

Sogar die Database des Journals auf die tune2fs zurückgreift wurde 
mitkopiert. :)

Beitrag #6785369 wurde von einem Moderator gelöscht.
Beitrag #6785373 wurde von einem Moderator gelöscht.
Beitrag #6785378 wurde von einem Moderator gelöscht.
Beitrag #6785424 wurde von einem Moderator gelöscht.
von Mw E. (Firma: fritzler-avr.de) (fritzler)


Lesenswert?

Bin ich auch dafür diese Typen wie schlaumeier und rudi endlich mal zu 
entsorgen.

von Rudi Ratlos (Gast)


Lesenswert?

Mw E. schrieb:
> diese Typen wie schlaumeier und rudi endlich mal zu entsorgen.

Am Besten wird wohl sein, dieses ganze Forum zu entsorgen.
Eigentlich braucht man es gar nicht entsorgen, das entsorgt sich schon 
länger von selbst. !

Ich
verkehre da (gelegentlich) schon viele, viele Jahre -
mehr als traurig hier geworden.

von Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)


Lesenswert?

Rudi Ratlos schrieb:
> Am Besten wird wohl sein,

Alles war nicht so verkehrt. Es hätte eigentlich in einen eigenen Thread 
gehört. Hier hättet Ihr solche Abschweifungen ganz kurz halten müssen. 
Vielleicht kennt Ihr die Science Busters 
(https://de.m.wikipedia.org/wiki/Science_Busters). Ein paar Beiträge von 
Euch mit µC&Desktop Busters Inhalten wurden hier dann doch einigen zu 
viel.

Beitrag #6786523 wurde von einem Moderator gelöscht.
Beitrag #6786559 wurde von einem Moderator gelöscht.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.