0

In late November 2020, I installed Ubuntu 20.04 on an external hard drive, and I was using it with no significant problems. Then when I tried to boot it and log in (via the usual way) on Dec 21, it failed. Instead of giving me the usual login screen, it displayed messages about problems with inodes. I turned off the computer, and tried to boot again. This time, it came up with a screen that displayed the following output:

[   0.159360 ipmi:dmi: Base address is zero, assuming no IPMI interface
/dev/sdc2 contains a file system with errors, check forced.
/dev/sdc2:
Inode 131169 seems to contain garbage.

/dev/sdc2: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
        (i.e., without -a or -p options)
fsck exited with status code 4
The root filesystem on /dev/sdc2 requires a manual fsck

BusyBox v1.30.1 (Ubuntu 1:1.30.1-4ubuntu6.2) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs)

Multiple attempts to boot Ubuntu all yielded the same output as shown above.

I did plenty of research (using another computer to search for relevant web sites, then carefully reading them), and made several attempts to fix the problem, without success. I'm hoping that someone is familiar with this situation, so that they can explain why my Ubuntu 20.04 system is failing, and can offer a step-by-step procedure to fix whatever is broken.

Ideally, I'll be able to fully restore the system, so that booting it will lead to the familiar login screen, and all my data will be available. But even if Ubuntu is broken and I must re-install it (not a big problem), I would really like to be able to recover whatever data I can. I had updated some files in recent days, and I don't back up my data every time I use the computer, so I'd hate to lose these recent changes.

To try to fix the problem, I entered "fsck -y /dev/sdc2" at the (initramfs) prompt (based on advice that I found on several web sites). Then I entered "reboot" (at the (initramfs) prompt), but it had no effect, so I entered "exit". The screen went blank, and then nothing happened for ~10 minutes, so I manually powered down the computer. When I turned the computer back on and tried to boot Ubuntu, this time the screen displayed the following two lines:

/dev/sdc2: recovering journal
/dev/sdc2: clean, 471037/4890624 files, 6056765/19531250 blocks

But then nothing more happened. So after ~10 minutes, I manually powered down the computer. Then I turned it on again, and opted to go into recovery mode ("Ubuntu, with Linux5.4.0-58-generic (recovery mode)". Many lines of output quickly flew past on the screen, and it eventually showed:

         Starting GNOME Display Manager...
[***   ] (1 of 2)  A start job is running for Login Service (56s / 1 min 30s)

But soon after that, it displayed:

[FAILED]  Failed to start GNOME Display Manager.

And then it seemed to be stuck in an infinite loop that repeated every few minutes, first displaying "Starting GNOME Display Manager" and then displaying "Failed to start GNOME Display Manager". So I manually powered down the computer, tried again to boot Ubuntu 20.04 (this time in the normal way, not recovery mode), and the screen was blank except for the following two lines near the top (very similar to what I saw before, but with slightly different numbers):

/dev/sdc2: recovering journal
/dev/sdc2: clean, 471039/4890624 files, 6060864/19531250 blocks

This time, I just left it to see if anything would happen. It stayed like that for over 6 hours, so I gave up, and turned off the computer.

This morning, I tried again to boot Ubuntu 20.04 (in the normal way, not recovery mode). As usual, the "GNU GRUB version 2.04" screen appears for a minute or two, and then automatically disappears. The screen went totally blank for ~60 seconds, then briefly displayed "Ubuntu 20.04" in small font in the center of the screen, and then displayed the following one line of output at the top of the screen (this time with no mention of "recovering journal"):

/dev/sdc2: clean, 471032/4890624 files, 6064956/19531250 blocks

After more than two hours, the screen continues to display only the above line of output. A light on the external hard drive occasionally blinks, which I suppose might indicate that it is doing something (but what?!?).

What do those numbers in the numerators (471032 for files, 6064956 for blocks) indicate? And what do the numbers in the denominators (4890624 for files, 19531250 for blocks) indicate? Why do they change slightly on each attempt to boot? If I leave the computer running, will it make progress and eventually come to the usual login screen?

Here are some details about my system configuration. My computer is a Dell Inspiron laptop with Windows 7 on it, and it's ~8 years old (so somewhat old, but still quite usable). I installed Ubuntu 20.04 on a 80 GB partition that I created on a new Seagate external hard drive (with total capacity 1 TB). I like having the option to use Windows 7 (it's stable, and supports some apps that I like) or Ubuntu (a great OS!). For ~8 years, I've been using this same arrangement to boot Ubuntu 12.04 from another external hard drive (never with any problems), so I figured the same procedure should work fine for Ubuntu 20.04. When I want to use Ubuntu (20.04, or 12.04), I plug in the external hard drive to a USB port on the computer, then push the computer's power button, then hit the F12 key (for Boot Options), and then select the "USB Storage Device" option. Then the computer's screen displays the usual "GNU GRUB version 2.04" screen, and then automatically proceeds to boot Ubuntu and take me to the login screen (except for when the filesystem has failed - like the situation I'm in now!).

In case it might help, here are the last lines displayed in the output from the "fsck -y /dev/sdc2" command (most of the output went flying by so fast that I didn't have time to read it or make note of it):

Free blocks count wrong for group #108 (11074, counted=11124).
Fix? yes

Free blocks count wrong for group #171 (5910, counted=6084).
Fix? yes

Free blocks count wrong (13471083, counted=13474145).
Fix? yes

Inode bitmap differences: -(131169--131184) -(131201--131232) -(131521--131535)
 -(131537--131552)
Fix? yes

Free inodes count wrong for group #16 (82, counted=161).
Fix?  yes

Free inodes count wrong (4419514, counted=4419593).
Fix?  yes

/dev/sdc2: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdc2: 471031/4890624 files (0.2% non-contiguous), 6057105/19531250 blocks
(initramfs)

Before I ran the fsck command, I first entered 'ls' (at the initramfs prompt) and it displayed the following output (for the various directories under /, I guess): dev bin init lib64 sbin var tmp root conf lib libx32 scripts sys kernel etc lib32 run usr proc

I was concerned that I did not see 'home' in that collection. It makes me worry that my home directory and everything under it have been lost.

After I ran the fsck command, I entered 'ls' again, and exactly the same output appeared (with no 'home' in the collection, so I remain very worried).

Several web pages stated that "fsck -y <failed_partition>" followed by "reboot" would work, but in my case "reboot" did nothing. The (initramfs) prompt merely returned, with no obvious change from before. So I'm wondering what prevents Ubuntu from rebooting.

And then when I tried to go into recovery mode, even that failed (because of the "Failed to start GNOME Display Manager" errors, described above). So it looks like Ubuntu is in very bad health.

Thank you very much to anyone who can offer helpful information and/or suggestions. If you can help me restore my Ubuntu 20.04 installation to full health, then you will make this holiday season a very happy one for me. Or if you can at least help me recover my data, then that would still be a big help.

1 Answer 1

1

The one time that I had this problem, I did not fix it from initramfs, but instead from a bootable USB - You could try that. Also, There is a -f option which you should use for fsck:

fsck -f /dev/sdc2

Finally, use lsblk to ensure that you are checking all of your block devices.


  • The -f option gets passed to e2fsck, and forces a file system check even if the file system reports that it is clean.
  • You mention /dev/sdc2 specifically, so I am assuming there is a /dev/sdc1
9
  • Thanks for those tips! Re "a bootable USB", I currently have the following options: 1) ubuntu-20.04-desktop-amd64.iso file on DVD-ROM disc (used it to install). 2) Ubuntu 12.04 on another external hard drive (so it's ~8 years old). Would either of those work?
    – JohnKeen
    Dec 27, 2020 at 6:00
  • For #1, could I boot from the CD/DVD-ROM tray, choose "test drive" mode, and open a terminal window for running commands to repair /dev/sdc2? For #2, I could plug it into another USB port and boot from it. But would this old 12.04 version lack any valuable enhancements to the commands (fsck, etc.)? I'm not familiar with the 'lsblk' command, but could give it a try. Will it assess the health of all partitions on the external hard drive? And also look at other disks in the system?
    – JohnKeen
    Dec 27, 2020 at 6:00
  • That hard drive actually has four partitions on it. The /dev/sdc1 partition is of size ~56 GB, and hold misc files from the manufacturer. The /dev/sdc2 bootable partition is of size ~80 GB, and holds Ubuntu 20.04. The third partition (size ~20 GB) serves as swap space for Ubuntu. The fourth partition (size ~600 GB) serves as an 'Archive' area for backing up files from Windows 7. This 'Archive' partition seems to be in good health.
    – JohnKeen
    Dec 27, 2020 at 6:01
  • @JohnKeen Booting from the USB or CDRom in the 'test' mode is exactly what I was referring to. Sorry I was offline yesterday, how is the health of your disk today? Dec 29, 2020 at 2:07
  • Thank you for the follow-up. Sorry for the delayed response time from my end. Today, I finally found a large enough chunk of time to try your suggestions. Here is what I did: - Booted from the ubuntu-20.04-desktop-amd64.iso DVD-ROM. - At the "Install" screen, chose the "Try Ubuntu" option . - Opened up a terminal window. - Plugged in the Seagate external hard drive. - Entered the "df" and "lsblk" commands, to confirm /dev/sdc2 is visible. - Entered the "fsck -k /dev/sdc2" command.
    – JohnKeen
    Dec 30, 2020 at 2:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .