This is a well-known upstream issue/bug. This is not s390x, Ubuntu 18.10, any other Ubuntu release specific. There is no dataloss -> one can execute pvmove operation in reverse (or i guess onto any 512 sector size PV) to mount the filesystems again.
Thus this is not critical at all. Also, I am failing to understand what is the expectation for Canonical to do, w.r.t. this bug report? If you want support, as a workaround one can force using 4k sizes, with vgcreate and ext4, then moving volumes to/from 512/4k physical volumes appears to work seamlessly: $ sudo vgcreate --physicalextentsize 4k newtestvg /dev/... $ sudo mkfs.ext4 -b 4096 /dev/mapper/... For a more general solution, do create stand-alone new VGs/LVs/FSs, and migrate data over using higther level tools - e.g. dump/restore, rsync, etc. But note, that launchpad should not be used for support requests. Please use your UA account (salesforce) for support request for your production systems. This is discussed upstream, where they are trying to introduce a soft check to prevent from moving data across. https://bugzilla.redhat.com/show_bug.cgi?id=1669751 But it's not a real solution, just a weak safety check. As one can still force create ext4fs of either 512 or 4k, and move the volume to the "wrong" size. As ideally it would be user friendly if moving to/from mixed sector sizes would just work(tm) but that's unlikely to happen upstream, thus is wont-fix downstream too. Was there anything in particular that you were expecting for us to change? We could change the cloud-images (if they don't already), installers (i.e. d-i / subiquity) or the utils (i.e. vgcreate, mkfs.ext4) to default to 4k minimum sector sizes. But at the moment, these utils try to guess the sector sizes based on heuristics at creation time, and obviously get is "wrong" if the underlying device is swapped away from under their feet post creation time. Thus this is expected. References: The upstream bug report is https://bugzilla.redhat.com/show_bug.cgi?id=1669751 The upstream overridable weak safety-net check is https://sourceware.org/git/?p=lvm2.git;a=commitdiff;h=dd6ff9e3a75801fc5c6166aa0983fa8df098e91a And that will make it into ubuntu eventually, when released in a stable lvm2 release and integration into ubuntu. Please remove severity critical Please remove target ubuntu 18.10 Please provide explanation as to why this issue was filed ** Bug watch added: Red Hat Bugzilla #1669751 https://bugzilla.redhat.com/show_bug.cgi?id=1669751 ** Changed in: linux (Ubuntu) Status: New => Invalid ** Changed in: ubuntu-z-systems Status: New => Incomplete ** Changed in: lvm2 (Ubuntu) Status: New => Incomplete ** Also affects: lvm2 via https://bugzilla.redhat.com/show_bug.cgi?id=1669751 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1817097 Title: pvmove causes file system corruption without notice upon move from 512 -> 4096 logical block size devices To manage notifications about this bug go to: https://bugs.launchpad.net/lvm2/+bug/1817097/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
