© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
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 --physicalexten
$ 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:/
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:/
The upstream overridable weak safety-net check is https:/
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