1

My system is running on Ubuntu 18.04 is stuck on fsckd check, I am not able to cancel this check and also not able to see any progress of the check after the prompt bellow.

fsckd-cancel-msg:Press Ctrl+C to cancel all filesystem checks in progress

Screenshot of the check

I have tried skipping the check, but no luck.

I want to find out what's the actual problem here as it's taking long time for the filesystem check and the reason for starting this filesystem check process at the first place.

Is skipping this check is a good option here? if so, can you guide me through what needs to be done exactly. If skipping the check is not a good option then what needs to be done.

Any help will be much appreciated.

Kulfy
  • 17,696
Karthik
  • 13

3 Answers3

3

I had a similar issue, not after upgrading from 18 to 20.04, but after running sudo apt upgrade. For me for some reason the nvidia driver it updated to is unable to use the laptop inbuilt screen. It showed the computer booting normally, but after the filesystem check line, it appeared to be stuck on that screen. Everything worked fine on a monitor connected to the HDMI port though.

Without an external monitor I could not access the virtual terminals or anything, it just appeared to be stuck on the filesystem check. The way I got it somewhat working without access to an external monitor was to boot into "safe mode". After booting from the safe mode I was able to access the virtual terminal and could switch to the integrated graphics with sudo prime-select intel. Obviously can not use the external monitor with the integrated driver selected.

The NVidia driver version causing issues for me was 470.

Just writing this here, probably not something a lot of people will run into, but it is superficially presenting with the exact same symptoms.

Reverted back to using the newest Nvidia driver (470.63.01) and using kernel 5.11.0-34-generic. Needed to select the "discrete graphics" instead of "hybrid graphics" from BIOS to get the inbuilt screen to work.

MRFalcon
  • 31
1

Let's check the basics first, by performing a manual fsck...

  • boot to a Ubuntu Live DVD/USB
  • open a terminal window
  • type sudo fdisk -l
  • identify the /dev/XXXX device name for your "Linux Filesystem"
  • type sudo fsck -f /dev/XXXX # replacing XXXX with the number you found earlier
  • repeat the fsck command if there were errors
  • type reboot

Update #1:

Ah, you've partitioned your disks slightly out of the ordinary, so we'll have to fsck the other partitions also.

  • boot to a Ubuntu Live DVD/USB
  • open a terminal window
  • type the following commands...
    • sudo fsck -f /dev/sda4
    • sudo fsck -f /dev/sda1
    • sudo fsck -f /dev/sdb1
    • sudo fsck -f /dev/sda5

Update #2:

We're investigating high read/seek/ECC error rates on sdb (HDD).

There may also be a Ubuntu software issue, or sda (SSD) firmware issue.

Update #3:

In looking at gparted for sda (SSD) I see /var is full.

I'd recommend:

  • full backup of important files from /home/username from sdb (HDD)
  • perform firmware update on sda (SSD) if required
  • wipe sda (SSD) and install fresh Ubuntu WITHOUT separate /var or /home
  • do not install anything on sdb and we'll do a bad block scan, and see if fsckd problem is gone

Update #4:

Bad block scan on sdb...

If sdb is not empty, use the appropriate partition number (probably sdb1 in your case) for the sdXX parameter below. If sdb is empty, assure that there's at least one large ext4 partition, which will probably be sdb1, and then use that for sdXX.

Note: do NOT abort a bad block scan!

sudo e2fsck -fcky /dev/sdXX # read-only test

or

sudo e2fsck -fccky /dev/sdXX # non-destructive read/write test (recommended)

The -k is important, because it saves the previous bad block table, and adds any new bad blocks to that table. Without -k, you loose all of the prior bad block information.

The -fccky parameter...

   -f     Force checking even if the file system seems clean.

   -c     This option causes e2fsck to use badblocks(8) program  to  do  a
          read-only  scan  of  the device in order to find any bad blocks.
          If any bad blocks are found, they are added  to  the  bad  block
          inode  to  prevent them from being allocated to a file or direc‐
          tory.  If this option is specified twice,  then  the  bad  block
          scan will be done using a non-destructive read-write test.

   -k     When combined with the -c option, any existing bad blocks in the
          bad blocks list are preserved, and any new bad blocks  found  by
          running  badblocks(8)  will  be added to the existing bad blocks
          list.

   -y     Assume  an answer of `yes' to all questions; allows e2fsck to be
          used non-interactively.  This option may not be specified at the
          same time as the -n or -p options.

Update #5:

Bad blocking completed. SMART Data indicates that read/ECC errors are now zero! If read/seek/ECC errors return, suspect a bad SATA cable or SATA port. Monitor SMART Data for sdb.

Reinstall Ubuntu with no special partitioning, except for /home on ext4 sdb1, and possibly a sdb2 NTFS partition if you share files with Windows.

heynnema
  • 70,711
0

In my case the fsck could not complete because the root partition was full. Booting from a liveUSB and making up space (e.g. deleting systemd logs) fixed the issue.

Bobisnotyouruncle
  • 1