1

This is about duplicating the file system and has nothing to do with the files therein.

I'm trying to attach an empty ebs volume to my ec2 instance. I've done this before on this instance, a long time ago, but something has changed since then. I've checked the AWS documentation and can see no reason for my problem.

The problem is that when I go to mount the volume

sudo mount /dev/xvdg /target

I get the spectacularly uninformative error message

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

dmesg says

EXT4-fs (xvdg): couldn't mount RDWR because of unsupported optional features (400)

The filesystem was created with a

sudo mkfs -O ^64bit -t    ext4 /dev/xvdg

command. (I have also done this without disabling the 64bit option - it makes no difference.) So mkfs is making a filesystem which then can't be mounted. Great.

Using file to compare xvdg to an old volume, xvdp, which will mount gives:

/dev/xvdp: sticky Linux rev 1.0 ext4 filesystem data, UUID=e9c54688-255f-4f7a-9446-f7215ed9142b (needs journal recovery) (extents) (large files) (huge files)

/dev/xvdg: sticky Linux rev 1.0 ext4 filesystem data, UUID=9bf21e70-3d97-472a-b24f-cfe1ac500eb3 (extents) (large files) (huge files)

So except for the unimportant warning about journals on the working volume they would seem to be the same.

I can see several ways forward but have no idea how to do any of them:

  1. Get a better error message as to exactly what option is unsupported.
  2. Get a readout of all options used to create xdvp such that they can be applied to a call to mkfs.ext4: which is what's under the hood of mkfs.
  3. Zap the unmounted xdvg with a bit-for-bit copy of the xdvp filesystem. This would be preferably without wasting time copying the files themselves, as they'll just be deleted as soon as the volume is mounted, but this would be OK if necessary. I don't think dd or rsync will do this but I could be wrong.

This is a debian 9.0 system if that helps. Probably more information than that is needed to look into the problem but, of course, much of my problem is that I don't know which configuration data I'm missing or how to get it. For example, if it's a superblock problem I don't even know what a superblock is.

  • 2
    Copying the entire filesystem would replace all of the files as well. Run tune2fs -l on each to see all of the options and see if any are different. – psusi Oct 12 '17 at 23:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.