systemd-journald failed to write entry - boot problems

[AllardK]

Hi all,

I'm using Mint on an old Aspire laptop, and I've been having a recurrent problem. It was already happening when I was running LM 19.1 Tessa, but it has persisted after upgrade to LM20 Ulyana. The problem is a two step thing: when logging out, or also when switching user, the screen goes into a terminal-like output with continuous writing of the message:

Code: Select all

{some number} systemd_journald [323]: failed to write entry (22 items, 748 bytes), ignoring: read-only file system

This goes on for a long time, so I power down and restart. Sometimes, that works. Sometimes however, that doesn't work. During boot, I then get an error about file system errors that require a manual fsck. When I run fsck there are then errors that are repaired and afterwards I can boot just normal.

The file system errors on boot always happen after the systemd errors, but not all the systemd errors lead to boot problems. I read this topic: viewtopic.php?t=287086 , but it seems to be different and I didn't get anything useable from the suggested disk check.

Any ideas?

[SMG]

You did an upgrade to LM20 or you did a fresh install?

Please give us information about your install by entering this command in a terminal: inxi -Fxxxrz
Click </> from the mini toolbar above the textbox where you type your reply and then place your cursor between the code markers and paste the results of the command between the code markers [code]Results[/code]. This will let us know how Mint sees your hardware.

[AllardK]

You did an upgrade to LM20 or you did a fresh install?

Please give us information about your install by entering this command in a terminal: inxi -Fxxxrz
Click </> from the mini toolbar above the textbox where you type your reply and then place your cursor between the code markers and paste the results of the command between the code markers [code]Results[/code]. This will let us know how Mint sees your hardware.

Hi SMG, thanks for taking interest. Here's the result of inxi. Perhaps of note: I ran the update manager in between my post and this reply, before update I had the 5.4.0-058 kernel, but since this problem has persisted over many months of updates it may not be of importance.
I upgraded to LM20 indeed, not a complete fresh install.

Code: Select all

Kernel: 5.4.0-60-generic x86_64 bits: 64 compiler: gcc v: 9.3.0 
  Desktop: Cinnamon 4.6.7 wm: muffin 4.6.3 dm: LightDM 1.30.0 
  Distro: Linux Mint 20 Ulyana base: Ubuntu 20.04 focal 
Machine:
  Type: Laptop System: Acer product: Aspire 7739 v: V1.04 serial: <filter> 
  Mobo: Acer model: HMA71_CP v: Type2 - Board Version serial: <filter> 
  BIOS: Insyde v: 1.04 date: 10/11/2011 
Battery:
  ID-1: BAT0 charge: 37.5 Wh condition: 42.3/48.4 Wh (87%) volts: 11.9/11.1 
  model: AS10B75 type: Li-ion serial: <filter> status: Discharging 
CPU:
  Topology: Dual Core model: Intel Core i3 M 380 bits: 64 type: MT MCP 
  arch: Nehalem rev: 5 L2 cache: 3072 KiB 
  flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 20266 
  Speed: 1302 MHz min/max: 933/2533 MHz Core speeds (MHz): 1: 1467 2: 1467 
  3: 1467 4: 1467 
Graphics:
  Device-1: Intel Core Processor Integrated Graphics 
  vendor: Acer Incorporated ALI driver: i915 v: kernel bus ID: 00:02.0 
  chip ID: 8086:0046 
  Display: x11 server: X.Org 1.20.9 driver: modesetting unloaded: fbdev,vesa 
  resolution: 1600x900~60Hz 
  OpenGL: renderer: Mesa DRI Intel HD Graphics (ILK) v: 2.1 Mesa 20.2.6 
  direct render: Yes 
Audio:
  Device-1: Intel 5 Series/3400 Series High Definition Audio 
  vendor: Acer Incorporated ALI driver: snd_hda_intel v: kernel 
  bus ID: 00:1b.0 chip ID: 8086:3b56 
  Sound Server: ALSA v: k5.4.0-60-generic 
Network:
  Device-1: Qualcomm Atheros AR9485 Wireless Network Adapter vendor: Lite-On 
  driver: ath9k v: kernel port: 3000 bus ID: 02:00.0 chip ID: 168c:0032 
  IF: wlp2s0 state: up mac: <filter> 
  Device-2: Qualcomm Atheros AR8152 v2.0 Fast Ethernet 
  vendor: Acer Incorporated ALI driver: atl1c v: 1.0.1.1-NAPI port: 2000 
  bus ID: 03:00.0 chip ID: 1969:2062 
  IF: enp3s0 state: down mac: <filter> 
Drives:
  Local Storage: total: 465.76 GiB used: 219.31 GiB (47.1%) 
  ID-1: /dev/sda vendor: Seagate model: ST9500325AS size: 465.76 GiB 
  speed: 3.0 Gb/s rotation: 5400 rpm serial: <filter> rev: SDM1 scheme: MBR 
Partition:
  ID-1: / size: 191.25 GiB used: 121.75 GiB (63.7%) fs: ext4 dev: /dev/sda1 
  ID-2: /home size: 214.48 GiB used: 97.57 GiB (45.5%) fs: ext4 
  dev: /dev/sda4 
  ID-3: swap-1 size: 9.77 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sda2 
Sensors:
  System Temperatures: cpu: 45.0 C mobo: N/A 
  Fan Speeds (RPM): N/A 
Repos:
  No active apt repos in: /etc/apt/sources.list 
  Active apt repos in: /etc/apt/sources.list.d/official-package-repositories.list 
  1: deb https://mirror.koddos.net/linuxmint/packages ulyana main upstream import backport
  2: deb http://ftp.tudelft.nl/archive.ubuntu.com focal main restricted universe multiverse
  3: deb http://ftp.tudelft.nl/archive.ubuntu.com focal-updates main restricted universe multiverse
  4: deb http://ftp.tudelft.nl/archive.ubuntu.com focal-backports main restricted universe multiverse
  5: deb http://security.ubuntu.com/ubuntu/ focal-security main restricted universe multiverse
  6: deb http://archive.canonical.com/ubuntu/ focal partner
  Active apt repos in: /etc/apt/sources.list.d/skype-stable.list 
  1: deb [arch=amd64] https://repo.skype.com/deb stable main
Info:
  Processes: 197 Uptime: 8m Memory: 7.45 GiB used: 1.45 GiB (19.4%) 
  Init: systemd v: 245 runlevel: 5 Compilers: gcc: 9.3.0 alt: 7/9 
  Shell: bash v: 5.0.17 running in: gnome-terminal inxi: 3.0.38 

[SMG]

Yes, I guessed you upgraded since it sounds like that type of error would not be fixed by upgrading. I presume you checked the disk health as indicated in the other thread and the disk checked out as okay? If that is the original, it may be nearing the end of its life.

You could test whether a fresh install might help by booting to an LM20 live session.

I've helped a number of people who have upgraded and sometimes we get lucky and their issue is resolved, but usually it is best to do a fresh install. However, if the disk is the issue, a reinstall will not help.

[AllardK]

The disk is OK according to the analysis, 609 bad sectors.

I could try a fresh install of 20.1 but everything is set up now that both kids know how to log in and which icons to click so they can do their homeschooling work... I won't start messing with this system until schools open again here in NL (at least 3 more weeks).

In the mean time, is there a way to do some mitigation? It seems that the system detects that sn fsck -a is not enough and a manual fsck run is necessary on startup when this error occurs. Is there any way to force an " fsck -y /dev/sda1 " command when that occurs? Seems like a simple 'if' statement but I have no idea where to put that....

[SMG]

In the mean time, is there a way to do some mitigation? It seems that the system detects that sn fsck -a is not enough and a manual fsck run is necessary on startup when this error occurs. Is there any way to force an " fsck -y /dev/sda1 " command when that occurs? Seems like a simple 'if' statement but I have no idea where to put that....

The file system check and corrections can only be done on an unmounted partition, so it can not be done after the operating system has taken control of the disk.

Maybe someone else will have some ideas that could help until you can do a fresh install.