Ubuntu18.04( wsp) :Encryption Volume and Mount point not visible

[bugproxy]

== Comment: #0 - PREETI THAKUR - 2018-03-22 05:42:06 ==
Ubuntu18.04 (wsp):Encryption Volume and Mount point not visible

---Problem Description---

Ubuntu 18.04 [ wsp ]:

---Environment--
Kernel Build: Ubuntu 18.04
System Name : wsp
Model/Type : P9
Platform : Baremetal

---Steps to reproduce--

1. Start Installation
2. Proceed with Partitioning
3. Encrypt disk
4. Start Installation
5. Once installation is done issue command lsblk
Encrypted Volume and mountpoint which is encrypted is not showing

Screen Shot attached
Attaching screen shots in order.

== Comment: #1 - PREETI THAKUR - 2018-03-22 05:42:35 ==

== Comment: #2 - PREETI THAKUR - 2018-03-22 05:43:02 ==

== Comment: #3 - PREETI THAKUR - 2018-03-22 05:43:42 ==

== Comment: #4 - PREETI THAKUR - 2018-03-22 05:45:56 ==

== Comment: #5 - Chandni Verma - 2018-03-23 05:28:34 ==
So this is happening because of the message we see in screen4 screenshot.

It looks like no volumes encrypted with LUKS are found.

Preeti can you talk a bit about which disk encryption specification you chose?
Was there any choice available for it?

== Comment: #7 - PREETI THAKUR - 2018-03-26 01:04:07 ==
In reply to comment 5

when tried to active the volume this message came
"No LUKS device found"

believe this is the issue, its not encrypting the volume...but also point to be noted is the volume chosen for encryption does not shows "mount point" name.

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[Frank Heimes (fheimes)]

Looks like a manual partitioning was done, so not "Guided - use entire disk and setup encrypted LVM".

Please can you provide the logs? Complete /var/log/installer folder and /var/log/syslog - thx

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2018-04-06 01:13 EDT-------
moving the defect to Open as requested logs already provided

[Andrew Cloke (andrew-cloke)]

I'm afraid I couldn't see the "complete /var/log/installer folder and /var/log/syslog" in the attachments to this bug. Could you confirm the Launchpad comment # where they are included?
Or perhaps they have not properly mirrored across to Launchpad?

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2018-04-06 04:39 EDT-------
Making comment by PREETI THAKUR on 2018-04-05 22:04:15 IST
external.

@preeti, please note that internal comments are not visible to distro partners across bridge.

[bugproxy (bugproxy)]

------- Comment on attachment From <email address hidden> 2018-04-06 08:25 EDT-------

--- Re-attaching installer logs and syslogs as an external comment. ---

[Andrew Cloke (andrew-cloke)]

Thanks - moving back to Triaged.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2018-04-15 14:37 EDT-------
Updates?

[Patricia Gaughen (gaughen)]

This did not make the 18.04 release, after the release has GAd, we will dive into this one deeper and evaluate for delivering for 18.04.1

[Dimitri John Ledkov (xnox)]

It appears that no encrypted volumes were requested in the end, hence none were created, thus no encryption volumes available post-install is... expected.

partman kind of uses a model-view-controller paradigm, and it tries to present ways to model partitioning as much as possible, without actually committing any changes on disk.

In the UI screen captures, it is shown that a partition was started to be marked to be used as backing device for an encrypted volume, but no volume was named/configured in the end. Hence it is marked with 'K' flag, for 'Keep as is', instead of 'f' for 'Format'. In the logs as well, it is indicated to leave that particular partition as is.

After one marks a partition intended for encryption, one has to go into a different sub-menu to configure an ecrypted volume, setup name and passphrase. Then a bare encrypted volume will be available to create a filesystem on top of it, and a mountpoint for it (e.g. /srv)

So it seems to me, based on logs and screenshots, the installer acted as expected in this case.