I have 2x 4TB HDDs that were put in an LVM group last year, ended up not really using this server due to huge issues around installing nextcloud. At some point it started giving me boot problems so I deleted the LVM Volume and Group.

Recently I've cleanly re-installed Ubuntu 18.04 on this system, but can't get these HDDs to work in LVM2 again. I'm using KVPM to make them LVM2 PVs, then Group and Volume. I cannot mount them as the final step.

sudo mke2fs -n /dev/mapper/lvmgroup-lvmvol
mke2fs 1.44.1 (24-Mar-2018)
Creating filesystem with 1953507328 4k blocks and 244191232 inodes
Filesystem UUID: 278308bd-878e-4dde-8bac-420ddb858636
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
    102400000, 214990848, 512000000, 550731776, 644972544, 1934917632

Some guides suggested that fsck could clear these blocks:

$ sudo e2fsck -b 32768 /dev/lvmVolGroup/lvmVGVol
e2fsck 1.44.1 (24-Mar-2018)
e2fsck: Bad magic number in super-block while trying to open /dev/lvmVolGroup/lvmVGVol

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/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>
    e2fsck -b 32768 <device>

Found a gpt partition table in /dev/lvmVolGroup/lvmVGVol

but I've tried quite a few of the listed bad blocks and they all just complain about 8193 and 32768. Yes I've tried those exact blocks too, same message.

So I tried removing/deleting all LVM steps, and completely reformatting both drives using gparted, and starting over. This did not work and I still get the exact same issues.

There was some data transferred into the LVM last time to test it was working, and I don't really care about preserving any existing data because I have other backups. I just need the LVM to be functional again. The drives themselves should still be working because they were bought brand new and tested individually, then just left sitting in a system that's been shut off for half a year.

Does anyone know what I could do?

  • 1
    After creating a new LVM logical volume, have you run mkfs without the -n option on it? What error messages are you getting when trying to mount it? Can you see any I/O error messages in sudo dmesg output after any attempts to mount or otherwise access the disks? – telcoM Jun 15 at 7:49
  • oh my god that was it. mkfs fixed it completely. none of the guides I've found mentioned this, and KVPM doesn't prompt you so I didn't think of it either. Could you please put that in as a properly reply so I can accept as answer? – Larry Cai Jun 15 at 8:48

After creating a new LVM logical volume, have you run mkfs without the -n option on it?

You should think of storage as a multi-layered cake: at the bottom is hardware, then there are various optional layers like partitioning, disk encryption, software RAID or LVM, and any number of them can be applied in basically any order (although not all orderings may make sense). At the top is usually the filesystem.

When you reinitialize one of the middle layers, you should generally assume that everything "above" that layer will be lost and need to be re-done, as a matter of course. So in this case, when you reinitialize the LVM PVs, recreate the volume group and the LV, you should assume that the filesystem on top of the LV will be lost.

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.