Linux Labs
Linux Labs
EN

Inside the system: resources, kernel, processes / Stage 8 of 12

dmesg and the kernel log

Not running Starting usually ~20 s
Leave the lesson

Step 3 of 8 · theory · 5 min

The ext4 error line

Three kernel lines explain everything you saw in the archive: what is broken, who ran into it and what the kernel did.

EXT4-fs error (device loop0): ext4_lookup:1864: inode #19: comm cat:
  iget: checksum invalid
Aborting journal on device loop0-8.
EXT4-fs (loop0): Remounting filesystem read-only

EXT4-fs error (device loop0) is an error in the ext4 filesystem on the loop0 device, that is, in the archive. inode #19 is the inode number of orders-07.csv, and comm cat is the process that ran into it. checksum invalid means the checksum of the inode record did not match: the data on disk is damaged, and the kernel does not hand it to the program. Hence Bad message for cat.

What to do on an error is stored in the filesystem itself: for the archive it is remount-ro (sudo dumpe2fs -h /dev/loop0 | grep Errors). The kernel stopped the journal and writing, and from then on any write gets Input/output error. The line calls this “Remounting filesystem read-only”, but in Ubuntu 24.04 the mount options stay the same — findmnt showed you rw (see filesystems).

e2fsck repairs the filesystem, and only an unmounted one: on a mounted filesystem it refuses: Cannot continue, aborting.

bash 
sudo umount /mnt/archive
sudo e2fsck -f /dev/loop0    # -y — answer “yes” to every question
sudo mount /dev/loop0 /mnt/archive

Mounting without a check brings writing back, but the error stays recorded: dumpe2fs shows clean with errors, and on mount the kernel advises a check: running e2fsck is recommended.

Check yourself 1 question

Writing to the archive fails with Input/output error again, and the kernel buffer has EXT4-fs error (device loop0). What will you do to get writing back?

  • e2fsck refuses: /dev/loop0 is mounted. e2fsck: Cannot continue, aborting. Repairs on a mounted filesystem can break it further.

  • A reboot drops the mount and the loop device but leaves the error in the filesystem: only e2fsck repairs it.

  • The command succeeds, but writing stays off: ext4 stopped it internally, and touch gets Input/output error again.

e2fsck works only on an unmounted filesystem: it repairs the damage and clears the error mark. After mounting, writing works again, and sudo dumpe2fs -h /dev/loop0 shows the state clean.

Key points

  • The EXT4-fs error (device …) line names the device, the inode and the process (comm) that ran into the damage.
  • After an error, ext4 with the remount-ro behaviour switches writing off: programs get Input/output error, while findmnt shows rw.
  • e2fsck -f on the unmounted device repairs the filesystem; remount,rw does not bring writing back.

Found an inaccuracy? Report an error in the lesson

Ubuntu 24.04
Loading…