Can't mount ext4 SSD: `JBD: no valid journal superblock found`

Question

I am trying to read excel file using python to do some data analysis. The data file is located in the same folder as the python program. However, the code is giving a syntax error. Do not know why. Appreciate your help.

import pandas as pd

dataIn_df = pd.read_excel(r 'C:\Users\Jon\AppData\Local\Programs\Python\data\InputData.xlsx', sheet_name='InputData')

File "C:\Users\Jon\AppData\Local\Programs\Python\data\RateRegulator.py", line 54
    dataIn_df = pd.read_excel(r 'C:\Users\Jon\AppData\Local\Programs\Python\data\InputData.xlsx', sheet_name='InputData')
                                                                                                    ^
SyntaxError: invalid syntax

Solution 1

Just perform:

mke2fs -t ext4 -O ^has_journal /dev/sdX

(in your case sdX is sda1) to recreate the ext4 partition with the journal enabled. Or to reformat the partition:

mke2fs -F -L "PartitionLabel" -t ext4 -O ^has_journal /dev/sdX

Solution 2

Have you tried running fsck on it?

From the live boot, try something like:

fsck.ext4 -Dcfy -C 0 /dev/sdX#

That will:

-D - Optimize directories
-c - Check for bad sectors
-f - Force a check
-y - Assumes 'yes' to all questions
-C 0 - Prints info to stdout

You would just need to make sure, without mounting I believe, that you run it on X (the SSD) and each partition (only do EXT4 partitions).

That should fix system known issues, report back if you don't mind and I can update if I find other options.

---

Also found a link talking about the 'superblock' that may be worth checking though I am not familiar with this, but it uses similar commands:

sudo fsck.ext4 -v /dev/sdX

Output for a bad superblock should look like:

fsck /dev/sda5
fsck 1.41.4 (27-Jan-2009)
e2fsck 1.41.4 (27-Jan-2009)
fsck.ext4: **Group descriptors look bad**... trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/sda5

The superblock could not be read or does not describe a correct ext4
filesystem.  If the device is valid and it really contains an ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>

Then check for location of superblock backups:

sudo mke2fs -n /dev/sdX

It should tell you the superblock backups are stored on blocks: # # #

Finally restore the backups (if they exist):

sudo e2fsck -b block_number /dev/sdX

Again, I haven't tried this and cannot speak to it's validity - hopefully someone else may know a bit more about this method. Source

Comments

[user]

Please don't blindly run fsck on a broken disk or file system: it can very easily take things from bad to worse in a hurry, particularly when using -y. Even in 2013, when this question was current, 32 GB was a comparatively trivial amount of storage space; common advice would be to make a sector-level copy (perhaps even two in this case, only touching one of them) and work on the copy, and see if you can get the filesystem back to a stable state, then either restore the fixed copy over the original, or simply extract the data from the fixed copy onto new media.

[Sergio Pulgarin]

@ijlalShah If the answer works for you, please mark this answer as accepted.