Ask Your Question

Filesystem problems every time there is a kernel update

asked 2017-06-15 11:32:24 +0000

alchimista gravatar image

On Fedora 25, after a kernel update, on the first time the system reboots goes to emergency mode and i'm forced to perform fsck. It's happening consistently on the past 5 or 6 kernel updates, and only when a kernel update took place. I've done several disk tests, and they all seemed fine, no disk problems are pointed out, is there any other way of preventing this? My SysInfo log

edit retag flag offensive close merge delete


I see disk errors logged in your Sysinfo log

fcomida ( 2017-06-15 23:01:19 +0000 )edit

2 answers

Sort by » oldest newest most voted

answered 2017-06-16 00:24:11 +0000

Try opening up GNOME Disks (installed by default.) Select your disk, click the overflow menu button (the “hamburger button”) and choose SMART Data and Self-Test. Click Start Test and choose Extended.

This will help provide insights about the health of your disk. Is it old? Flash or spinning?

edit flag offensive delete link more


The HD is a spinning, with 3 or 4 years old. Gnome Disks diagnose says the disk is good, with 160 damage sectors. All individual tests evaluation gives a good status. One thing i haben't mentioned is that the error happens on /dev/mapper/fedora-home

alchimista ( 2017-06-17 11:17:12 +0000 )edit

answered 2017-06-19 04:09:20 +0000

cmurf gravatar image
 [ 1177.395245] ata1.00: status: { DRDY ERR }
 [ 1177.395247] ata1.00: error: { UNC }

This is an uncorrectable read error, it is almost certainly a bad sector. The only way to fix it is to write over the sector, or sectors. Of course this means some form of data loss. It's possible the problem is intermittant which is why it sometimes doesn't happen. The simplest but longest option is to backup /home, and then just do a clean install of the OS and then restore /home. During normal writes, the bad sector will get written to, and if that fails the drive firmware will automatically correct and remap to a reserve sector.

More complicated is explaining the fast method. The gist is, find the address of the bad sector which should be in dmesg, and also learn if this is a 512 byte or 4096 byte sector drive. Use

blockdev  --getpbsz

If it's 512 bytes, you can just write a single block of zeros using dd

seek=address count=1

If it's a 4096 byte physical sector drive you have to convert the address to 4096 byte address and use

seek=address bs=4096 count=1

And then iterate with fsck -fv. If dmesg shows any UNC type errors with sector addresses, you'll need to nuke that sector and rerun fsck. Chances are, if fsck does not complain about a sector erasures, the erasure was data not file system metadata. So you might have other problems if that sector was e.g. part of some kind of system binary that's needed, you could get a crash. But chances are there are other problems anyway because UNC just ends up being an I/O error preventing it from being read anyway.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

[hide preview]

Use your votes!

  • Use the 30 daily voting points that you get!
  • Up-vote well framed questions that provide enough information to enable people provide answers.
  • Thank your helpers by up-voting their comments and answers. If a question you asked has been answered, accept the best answer by clicking on the checkbox on the left side of the answer.
  • Down-voting might cost you karma, but you should consider doing so for incorrect or clearly detrimental questions and answers.

Question Tools

1 follower


Asked: 2017-06-15 11:32:24 +0000

Seen: 62 times

Last updated: Jun 19