On Sun, Jul 10, 2016 at 4:13 PM, Morgan Read <mstuff@xxxxxxxxxxx> wrote: > Hmm, after trying to reboot and falling into emergency recovery, this > doesn't look good. And, after booting from live media and attempting > the following, this looks very bad indeed... I'm not sure > system-storage-manager should have allowed this... bugs, bugs, > bugs.... And more bugs, serious bugs Why the first resizes resulted in exactly no messages at all? I can't reproduce that with system-storage-manager-0.4-10.fc24.noarch. It asks about the mounted volume, whether to umount it first. But it does seem clear in your case the file system was not resized. I would say this part is improper design and a valid bug to file: [root@morgansmachine ~]# ssm resize -s-3G /dev/fedora_morgansmachine/home WARNING: Reducing active and open logical volume to 192.73 GiB. THIS MAY DESTROY YOUR DATA (filesystem etc.) Do you really want to reduce fedora_morgansmachine/home? [y/n]: y Size of logical volume fedora_morgansmachine/home changed from 195.73 GiB (50107 extents) to 192.73 GiB (49339 extents). Logical volume home successfully resized. By definition this is going to destroy data, not merely it may destroy data. It should have all available information to know the file system is size X, and that this operation will make the LV size X - 3G, which *will* with 100% certainly obliterate the file system. And then it permits it. This type of resize operation should fail. It should not be possible to do a resize through ssm (or any GUI resizer) and lose data in this fashion. It should require that you delete the LV in order to destroy it, not destroy it via resizing. Or require that wipefs be used on the LV or LUKS volumes before the resize will work. It needs to be more fail safe that this. But it did to exactly what you asked it to do. And ssm lit very clearly showed that it had NOT shrunk your file system volume before you decided to make the LV smaller than the file system. > [root@localhost ~]# e2fsck -fy > /dev/mapper/luks-a69b434b-c409-4612-a51e-4bb0162cb316 > e2fsck 1.42.13 (17-May-2015) > The filesystem size (according to the superblock) is 51309056 blocks > The physical size of the device is 50522624 blocks > Either the superblock or the partition table is likely to be corrupt! > Abort? yes These file systems are toast. Hopefully you have a backup of /home at least. -- Chris Murphy -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://lists.fedoraproject.org/admin/lists/users@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
