As part of my continuing efforts to pull all my data off of Amazon Web Services, I’ve had to create a new Amazon EC2 instance so that I can download all the data off of my two existing Amazon EBS volumes. Using the command line (and SSH), I was able to mount one volume fine and then download the data, so, good. But, the other volume is giving me a headache.
See, the first volume (the 8 GiB one) was mounted at root on an old EC2 instance (that’s too old to run anymore, hence why I had to make a new EC2 instance). That one mounts fine to the new instance (where I have it mounted at /mnt/me). But the second volume (the 19 GiB one), when I try to mount it, I get the following error message:
mount: /mnt/hp: wrong fs type, bad option, bad superblock on /dev/nvme2n1, missing codepage or helper program, or other error.
(/mnt/hp is the mountpoint I intended to use—yes, the directory exists and is appropriately empty—while /dev/nvme2n1 is the volume in I’m trying to mount.)
Here’s where the mystery begins. I don’t really know what’s on that volume. It could be something super important; it could be, for all I know, empty. I don’t know what filesystem it uses; it’s probably ext4, since that’s what the other volume uses (and I don’t see why I would’ve used anything else when I created the volume 14 years ago). But, when I specify -t ext4 (or, for that matter, -t ext3, -t ext2, or -t xfs), I get the same error message.
Trying to figure out what the problem is, I came upon this page. Following its suggestion, I tried running sudo blkid /dev/nvme2n1, which yielded no response. I then tried sudo blkid --info /dev/nvme2n1, and got the following response:
/dev/nvme2n1: MINIMUM_IO_SIZE="4096" OPTIMAL_IO_SIZE="4096" PHYSICAL_SECTOR_SIZE="512" LOGICAL_SECTOR_SIZE="512"
Well! That’s… something, I guess. I also tried looking at the results of dmesg, and found that every time I try to mount that volume, the following is added to the log:
zonefs (nvme2n1) ERROR: Not a zoned block device
That’s… also something, I guess. It might be a red herring, considering that it seems that the system is at least trying to mount the volume as a zonefs device (though I doubt I would’ve chosen that filesystem 14 years ago, as I’m not familiar with it now and I doubt I was then).
The other thing I’ve tried is lsblk --fs, which yields the following result:
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
zram0
[SWAP]
nvme0n1
│
├─nvme0n1p1
│ xfs / c8063cb4-92b1-42bd-8a7b-ae70c8e05dca 6.1G 22% /
└─nvme0n1p128
vfat FAT16 3939-EA90 8.6M 14% /boot/efi
nvme1n1
ext4 1.0 cloudimg-rootfs
17f73b82-6c94-44a7-a5de-14dd0758696a 3.3G 51% /mnt/me
nvme2n1
Yep, it yields information on the root device (nvme0n1) and the first of the two original EBS volumes (the one that works, nvme1n1), but nothing on the second, the one I’m trying to mount (nvme2n1).
Anyway, I’m really at a loss, here. I can’t remember what I created the second EBS volume for or what the filesystem is (though it’s probably ext4), and mount refuses to mount it and won’t really say why. How do I go about trying to figure out what this thing’s deal is? At the very least, is there any way to pull the data as a disk image and figure out what its deal is after I’ve downloaded it? (That wouldn’t be the preferable option, as I figure that, as hard as it is to figure out what this unknown volume is, it would be even harder to figure out how to access the data on a disk image of an unknown volume… but yeah, I want to get the data off this volume so I can shut down my AWS account and be done with all this.) I’d appreciate any way to get information about this volume, including whether or not it actually has data on it and if so, how to mount it properly. Where do I start? Where do I go from here?
(Oh, and for the record, the new EC2 instance that I’m SSH-ing into is running “Amazon Linux 2023 AMI 2023.12.20260817.0 arm64 HVM kernel-6.18,” AMI ID ami-0c9da9b2b7758f931.)
(Also, while the AWS console doesn’t seem to give much useful information about the volume, it does note that the volume is unencrypted. So, as far as I can tell, you can scratch that possibility—that encryption is causing this problem—off the list.)
