Comment 6 for bug 1040996

On 12-09-20 04:28 PM, Dmitrijs Ledkovs wrote:

There was no conscious choice to use LVM here. I do not have the
knowledge of Linux required to make that choice intelligently. The
partitioning scheme I wanted to use was not presented as an option by
the installer in an earlier build. In a previous install there had been
a way of compressing the existing system so that it occupied 50% of the
total drive space. The installer then would write a new partition using
the other 50% of drive space freed up. With my current knowledge of LVM,
that's as good an answer as I can give.

Ron Mitchell

> Dear original submitter - can you please reconfirm the disk partitioning
> scheme used? Was it LVM with separate /boot?
>
> One thing to note is that from the logs the reporter's machine suggests that it is installed on top of LVM.
> Currently LVM is ambiguous from auto-resize point of view.
>
> >From implementation point of view, the resize (aka alogside install) is available when:
> * existing installation is single full disk (e.g. full disk linux/windows)
> * where there is sufficient amount of free space available in that partition to perform a resize
> * there is sufficient amount of space left to install ubuntu if resize is attempted
> * the partitioner understands how to resize that file system
>
> This is pre-requisites =)
> Now the caveats
>
> * the resizing may fail if the extends are allocated in a such a way
> that a resize without defragmentation is not possible, or not supported
> enough by existing tools.
>
> This is ambiguous from LVM point of view, because:
> * do you want to resize the VG & create a separate normal partition - OR - do you want to create ubuntu lvm volumes within that group?
> * where should the boot loader go to?
>
> Sorry for not checking the auto-collected logs more carefully when first
> looking into the bug. Thank you mpt for updating the Partitioning
> Options Matrix ;-) I was previously interpolating options while reading
> it.
>