The context: a desktop PC with two disks, an SSD for the OS and an HDD for data (/home). Linux is in a partition formatted as EXT4 on the SSD, whereas /home is formatted as XFS. The machine gets through grub and I get the screen from which to choose the OS. The machine boots into Linux but only gets as far as a command line interface (I don’t know whether runlevel 1, 2 or 3). The feedback is:
EXT4-fs: (loop 10): error loading journal
You are in emergency mode.
After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" or "exit" to boot into default mode.
After providing the root password I can do dmesg|tail and find:
JB2: no valid journal superblock found
EXT4-fs: (loop 10): error loading journal
lsblk shows that loop 0 to loop 9 are all /snap but there is no loop 10. The root partition / and the /home partition are both mounted and their contents can be listed with ls, so there is a running Linux system of some sort.
My question is simple: How do I fix this so that Linux doesn’t drop into emergency mode but instead carries on to runlevel 5?
For me the problem here lies in the fact that neither the X nor the # are specified by the error.
Thus when there are more ext4 file systems on the system …
Also, when this problem is with the root file system, then you can not fsck from the running system. You must boot a rescue system of some kind to execute the fsck from there.
@marel Yes I saw that post, but I took note of the comment below it (“Please don’t blindly run fsck on a broken disk or file system …”) so decided against trying it. I just don’t know enough about file systems to know which post is right. @hcvv That hadn’t occurred to me. You are right to raise it because there are two other partitions formatted as EXT4 on that SSD (so that I could do a clean install should an upgrade ever go badly wrong). I could boot from the rescue system on the openSUSE DVD, of course, but if I don’t know which file system is broken I still have a problem.
Is there some way to check the file systems without trying to fix them in order to identify the broken one?
And if I find the broken file system is fsck.ext4 -Dcfy -C 0 /dev/sdX# safe?
Option “y” says assume Yes to all questions. I don’t consider such an option “safe”. However, it may be better than having no clue whether yes or no is the appropriate answer to any given question.
I would not use so much options.
Why the -D? Repairing is the main goal here, not reorganizing.
And yes, why -y? Better see what is asked and eventualy ask here when in doubt then a blind “yes” to everything.
I also have no idea if “checking for bad sectors” is something to start with. Same for the -f. Fir st just do a fsck. See what happens and act accordingly (could be doing a -f later).
But yes, findfing out which file system is broken is the first thing to do. You could check what is mounted and what not, that may tell you which one is the problem.
Good you checked the Internet before posting here, not bad if you had indicate this concern in your opening post.
fsck without -y will not do things without asking so I would execute it till it is asking me. Then I review the question and either stop or say yes. When I run it I did only say yes until now and sometimes stop it (Ctrl-C) and restart it with ‘-y’ as it is asking too many questions. You could run fsck (without -y) till the first question and post it here.
Do I know the exact consequences of the choices? No but I do not know another option and if things go really bad I know how to reinstall things. Good to read you have a setup with a separate home partition, that makes reinstalling things quite easy in my opinion.
SOLVED: The short answer is that the Dropbox file which is actually a self-contained EXT4 file system in each user’s account was the problem. I removed those from /etc/fstab and the machine booted into runlevel5. Since I don’t use Dropbox any more this isn’t a big loss.
The longer story of how I got to that solution is:
I started by investigating using the openSUSE rescue disk. Following this blog I used
fdisk -l
to identify all the partitions, then
fsck.ext4 -v /dev/sdaX
to check the EXT4 partitions. First, it turns out there are only two EXT4 file systems on that SSD, the third file system is XFS. Interestingly when fsck.ext4 is used to check an XFS file system it prints out lots of dire warnings and then says actually its XFS not EXT4 anyway. The result of checking the two EXT4 partitions was that both are “clean” (no issues raised), which didn’t get me any further.
Following @hcvv’s suggestion, I mounted each partition in turn and they all mounted and all could be examined with ls. But I already knew that from when the boot process dumped me into “emergency” mode.
Since that XFS partition on the SSD isn’t normally mounted I booted from the SSD and was dropped into emergency mode again. I checked and the two EXT4 partitions are mounted and can be examined, and the /home partition on the HDD is mounted and can be examined. I mounted the (unused) XFS partition on the SSD and it mounted and ls showed it is empty.
Looking at the error messages in my original post, it is the non-existent (or at least not yet mounted) loop 10 that causes the problem. The others (loop 0 to loop 9) are /snap which uses squashfs and not EXT4 anyway.
To try to guess what might this loop 10 be I did lsblk on the machine I am currently using and it gave only one: loop 0 is the Dropbox file (actually a self-contained EXT4 file system). That was the “ah-ha” moment, so I went back to the broken machine and modified fstab to remove the users’ Dropboxes.
Thank you all for your advice, it was much appreciated.