Tag Info

New answers tagged

0

Make sure your "/boot/grub/grub.cfg" lists the correct VG and LV. In my case, the VG is named "ssd_vg" and the LV is named "root_lv", so the grub.cfg file needs to reference "/dev/mapper/ssd_vg-root_lv" (note use of slashes and dashes!).


1

If you hadn't blown away the old ext4, there might have been some hope for fsck to do some repairs and find some intact directory structures. There might actually still be hope for that, by using an alternate superblock that was in the part of the disk you didn't mess up with mkfs. Or if your old FS had a different number of backup superblocks than your ...


2

You can't fix LVM by growing size back to original size, unless you were very lucky and the LV had no fragmentation whatsoever due to previous resizes. Chances are the new LV will have the first 20G or so of your original filesystem but the remaining 780G (or whatever) are scrambled eggs (wrong data, wrong offset, wrong order). And that's assuming you're ...


0

The following Debian Forum topic and blog post based on it has the missing information. Outline -1) Back up your LVM configuration and have a like CD ready. 0) Make sure you have a separate /boot partition (your cached root will only be available later). This can be a 200MB partition and can be part of the same VG as your cached root. 1) You need ...


2

I don't suppose there's a way I can skip having LVM running in the guest and just lvextend on the host then resize2fs in the guest? There's absolutely no requirement to use LVM inside a guest. You can just use the block device directly. Using LVM inside the guest gets you almost nothing (since you're already using LVM on the host to manage your ...



Top 50 recent answers are included