2

I created an ext4 partition on Ubuntu 18.04.4 LTS in order to transfer a large amount of data to a production server. The server is running CentOS 6.10 with kernel 2.6.32. The Ext4 Howto states that "Ext4 was released as a functionally complete and stable filesystem in Linux 2.6.28" so I assumed I was going to be able to just mount the partition.

However when trying to mount the partition on the server I get the errors:

localhost kernel: EXT4-fs (sdd1): couldn't mount RDWR because of unsupported optional features (400)
localhost kernel: JBD: Unrecognised features on journal
localhost kernel: EXT4-fs (sdd1): error loading journal

I have full root access to the server, but I am unable to upgrade any of the operating system components due to compatibility issues with the running software.

Initial Googling suggested that the issue was due to the metadata checksum feature, so I downloaded and compiled the latest e2fsprogs (1.46-WIP (20-Mar-2020)) and used those to disable the feature:

sudo /home/user/bin/e2fsck -f /dev/sdd1
sudo /home/user/bin/tune2fs -O ^metadata_csum /dev/sdd1

However the partition still fails to mount, although I don't get the "unsupported optional features (400)" message any more:

$ sudo mount /dev/sdd1 /mnt/disk1
mount: wrong fs type, bad option, bad superblock on /dev/sdd1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

$ sudo tail /var/log/messages
Jul 20 08:01:21 localhost kernel: JBD: Unrecognised features on journal
Jul 20 08:01:21 localhost kernel: EXT4-fs (sdd1): error loading journal

Is there some way I can access the data on this partition without rebooting the server or changing any of the system software? There seem to be two options: either I use mount the partition as is (using FUSE, or compiling my own mount.ext4 binary), or I use tune2fs to remove the remaining incompatible features (how do I find out what they are?)

I should mention that due to COVID-19 lockdown measures, there's a two to three week wait for someone to physically unplug the drive from the server and plug it into a different machine. I need to find a solution which I can implement quicker than that.

Improve this question
1
  • Run a VM in it and use USB pass-through to access the disk in the VM directly?
    – muru
    Jul 20, 2020 at 7:18

2 Answers 2

Reset to default
6

First try running

sudo e2fsck -f -v -C 0 -t /dev/sdd1

An e2fsck run may be required to complete the removal of the feature.

If it still doesn't help, try removing and recreating the journal:

sudo /home/user/bin/tune2fs -O '^has_journal,^64bit' /dev/sdd1
sudo /home/user/bin/resize2fs -s /dev/sdd1
sudo /home/user/bin/tune2fs -j /dev/sdd1

Lastly if it's still unmountable, compare the flags being used for sudo dumpe2fs /dev/existing_parition and sudo dumpe2fs /dev/sdd1 and remove the ones which are not present for your already existing partitions.

For future reference, if you format the filesystem on the old system instead of on the new system, it should always be usable by the new kernel. If you need to format on the new system, you could use mke2fs -t ext4 -O '^metadata_csum,^64bit' to avoid some of the newer features (though this may be a moving target), or mke2fs -t ext3 (though this may be somewhat slower than ext4 as a result, but is very safe compatibility wise).

Improve this answer
5
  • Extents as well, perhaps (after disabling 64-bit). tune2fs tries to be explicit when e2fsck and/or resize2fs are needed to complete feature changes (disabling 64-bit in particular typically needs both).
    – Stephen Kitt
    Jul 20, 2020 at 11:29
  • I assume that should be a lower-case V in the e2fsck command line? Removing the journal was the solution (64 bit didn't help, nor did re-running e2fsck). It had not occurred to me that the easiest way to deal with unsupported features in the journal was just to remove the journal entirely!
    – nickcrabtree
    Jul 21, 2020 at 5:12
  • Yes, it should have been lower case -v. I've corrected the answer. Sorry for the confusion.
    – Artem S. Tashkinov
    Jul 21, 2020 at 6:08
  • The extents feature has always been part of ext4, so no need to disable that. I think once the journal has been removed (and recreated, I'll add that to the answer), it should be fine again.
    – LustreOne
    Jul 21, 2020 at 8:53
  • Unfortunately, no! Event formatting on an older kernel doesn't work. I format a device with an old kernel, but after inserting the device on another system with a newer kernel; the device becomes unmountable for the old kernel! New kernel adds new journal features to the device when mounted!
    – hedayat
    Apr 13, 2021 at 21:52
1

I needed to use an old rescue environment (~2014?) to fix the grub bootloader on a modern system and had the same problem. The solution for me was to mount the filesystem without the journal at all:

# mount -o ro,noload /dev/sda1 /mnt

The "noload" argument does not seem to be (IMO properly) documented, but it does appear in the mount(8) man-page under --read-only:

   -r, --read-only
          Mount the filesystem read-only.  A synonym is -o ro.

          Note that, depending on the filesystem type, state
          and kernel behavior, the system may still write to the device.
          For example, ext3 and ext4 will replay the journal if the
          filesystem is dirty.  To prevent this kind of write access,
          you may want to mount an ext3 or ext4 filesystem with the
 [look->] ro,noload mount options or set the block device itself to
          read-only mode, see the blockdev(8) command.

You can mount read-write as well, but I only needed read-only.

Improve this answer

You must log in to answer this question.

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