No.  Because it's encrypted, the physical partition will contain
a luks encrypted block device that has to be opened to create
the device mapper block device, that then contains the lvm
"partition".  For luks devices, linux native is the normal choice.

CC: (none) => davidwhodgins

In the installer the partition its open (desencrypted) so here its irrelevant, should continue appearing the same partition type.

Now if in drakdisk you have a partition that is encrypted (and you still havent entered the passphrase), in that case is normal that isnt able to read the partition type.

In the luks encrypted block device, there is one (lvm in this case)
filesystem, but no partition table, so there is no place to store
the partition type.

That's normal for a luks encrypted block device, but it doesn't
have to be done that way.  I haven't tried it, but in theory,
you could create a partition table in the encrypted block device,
and then create partitions within that block device where the
partition type would be shown, as you are expecting.

As the luks encrypted block device may contain partitions, or
could be any file system type (ext4, vfat, lvm pv, etc.), and
there is no way to know what is in the block device until after
it has been opened, the block device is correctly set to linux
native.  After it's been opened, it's contents become visible
in a new tab, but that doesn't change the fact that the partition
containing the encrypted block device is not itself a file system.

On my system, I have a lvm physical volume, with multiple logical
volumes, one of which is encrypted, which then contains an ext4
filesystem.

This is not a bug, it's the working the way it's supposed to work.
I'm going to close this bug, but feel free to post any further
questions, it the above isn't clear.

Status: NEW => RESOLVED
Resolution: (none) => INVALID

You havent read the first comment with attention.

All this is in the installer, and when you add a partition and you set to encrypt and enter the password, after that the partition will contonue open (desencrypted), so here you cant put the case of a LUKS encryption being closed.

Status: RESOLVED => REOPENED
Resolution: INVALID => (none)

Sorry, I've now compared how diskdrake works in Mageia 1, and in the installer.
(I used the dual-cd for the test), and while they are the same, I now agree
that there are two bugs here. One is technical, the other is a matter of making
it clearer how to use lvm.

The technical bug is that when you've first created the encrypted lvm physical
volume, the only option shown as being available, is "Remove from dm", which
is wrong, as it hasn't been added to a volume group yet.

Once you then click on the partition, the option "Add to LVM" appears, where
you can create a new volume group, or if you already have one or more volume
groups, you can select which volume group this physical volume should be added
to.

On the technical side, it would be better, if after creating the physical
volume, the partition were auto selected, so you don't have to click on the
just created physical volume, before you get the option to add it to a volume
group.

The second bug is basically using incorrect terminology, so it isn't obvious
to a new user, what needs to be done.

When selecting the file system type, the string "Linux Logical Volume Manager"
would be better as "Logical Volume Manager Physical Volume.

The button labeled "Add to LVM" should be "Add to a LVM VG"

Help should be available, explaining that a LVM Volume Group may contain multiple
physical volumes, which may be on more than one hard drive, and that logical
volumes.  Once a LVM physical volume is created, it must be added to a LVM
volume group, before logical volumes may be created, that make use of that
physical volume.

I think we'll need help from the documentation team, to ensure the help is
worded in a way that is clear to a user new to lvm.

I'll attach screen shots made with Mageia 1, showing the problem, and part of
what will be needed, to show how to use it.

Created attachment 2357 [details]
Screen shot showing the problem, right after creating an encrypted lvm pv

As seen in this screen shot, after selecting a partition to format as
an encrypted lvm physical volume, the only option shown is "Remove from dm",
which is incorrect since it has not yet been added to a lvm volume group.

Created attachment 2358 [details]
Screen shot after clicking on the partition, showing add to lvm option.

The "Add to LVM" option isn't clear.  It should be "Add to LVM VG".
In this case, I then clicked on Add to LVM, selected new, and gave
the new volume group a name of test. (didn't take screen shots of
those steps).

Created attachment 2359 [details]
Screen shot showing volume group ready for logical volumes

This screenshot was taken after using the add to lvm button, selecting new,
entering the name test, waiting for the new tab with test to appear, and
then clicking to the tab test.  At this point, you can click on the blank
unallocated area within the volume group, and create logical volumes within
it.

Just to be clear, I consider this a minor bug, as it doesn't prevent the
logical volumes from being used, it just makes it difficult for someone
who is not familiar with diskdrake, to figure out how to do so.

You have described issues that are not related with this bug report, but even beter that you did, but i think you should create other bug reports instead keeping all those problems in a single bug report.

The issue that this bug report is about is that the installer does not show a partitions type as being the same.

After the LVM partition is created then in advanced mode (to allow to show the  button "Type"), and when clicking in button "type", the isntaller now changes the partition as being "Linux native" instead showing "Linux Logical Volume Manager".

Im adding Thierry Vignaud to CC since hes the maintainer.

CC: (none) => thierry.vignaud

Thinking about this a bit more, I realize the "Remove from DM' does have
to be there, but it should be reworded as something like "Close encrypted
device",
so this is strictly a bug about making the usage clearer.

You are missing the point, that when you create an encrypted lvm physical
volume, two things are created.

A linux native partition containing an encrypted block device.

A LVM physical volume, inside of the encrypted block device.

What is shown, after creating the encrypted lvm physical volume, is the
encrypted block device, which has to be shown, so you can select the "Remove
from DM" option, to perform the cryptsetup luksClose, if you want to.

Once you click on the encrypted block device, since it is open, the option
to add the physical volume it contains to a lvm volume group is provided,
but that doesn't change the encrypted block device into a lvm physical volume.
It's still a linux native partition on the disk.

when you choose to create a LVM partition type its different from a partition type "Linux native".

I have also checked this with the opensuse installer, i choose to create an encrypted LVM, and it was never reported as linux native, and it shows correctly in fdisk.

So in Mageia when you choose to create an encrypted LVM and then you click to see the partition type and appears as "Linux native" its clearly a bug.

Remember this, when you choose to create a partition and click to choose its type, you have there listed "Linux Logical Volume Manager" and also "Linux native", these are 2 different partition types.

Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Keywords: (none) => NEEDINFO

This bug is valid for Mageia 2 and cauldron since there werent any changes regarding it and its a critical bug due to the matter in question.

While I think comment 11 does include some useful suggestions on improving
the wording used with lvm volumes, I strongly disagree that showing the
encrypted container as linux native is a bug.

This bug report boils down to a difference of opinion, on what should be
shown where, within diskdrake.  It does not affect the usability of
diskdrake.

So you say that a LVM partition which code is 8e, is the same as a Linux native partition which has the code 83?

(In reply to comment #16)
> So you say that a LVM partition which code is 8e, is the same as a Linux native
> partition which has the code 83?

No.  I'm saying the encrypted container should be assigned type 83.

If the encrypted container contains a partition table, which it doesn't if
diskdrake is used, then within that partition table, type 8e would be
appropriate.  Since diskdrake does not create a partition table inside
of the encrypted container, there is no place to put the type 8e.

The partition on the hard drive is an encrypted container, no matter whether it
is open or closed, or if it contains a lvm physical volume, or an ext4 filesystem, an ntfs partition, etc.

The contents of the container do not change the fact that the container should
be type 83.

You don't want lvm or other tools for other filesystems working directly with
the encrypted container.  They have to work with the luks device in /dev/mapper,
so the partition table must have linux native, not lvm or ntfs or whatever.

pvcreate can be used to create a physical volume that uses an entire hard drive,
without a partition table.  That's creates the same problem, in that there is
no place to store the type 8e.

Created attachment 2388 [details]
Demonstration of creating two partitions within one encrypted container.

I decided to actually test and confirm what I wrote the my last comment.  This
attachment should help make my point more clearly.

While diskdrake won't do this, this should make it more clear, what it is doing.

Creating an encrypted block device, and creating a filesystem within that
device are two separate steps.  The diskdrake program makes it look like one,
to make it easier to use.

In this attachment, I've demonstrated changing an ext2 filesystem to a luks
encrypted block device.  After opening it, I create a partition table, and then
created a vfat and a ntfs partition using cfdisk, within the block device.

As demonstrated using fdisk, within the block device two partitions exist,
while in the physical device, one partition exists.

Do you think the partition sdd1 should be changed from linux native to vfat
or ntfs, given that it contains both types of partitions?

I'm actually a little surprised that cfdisk and fdisk  will handle this, as the
encrypted container doesn't have a real geometry.

As I expected, diskdrake doesn't see the two filesystems, as this is a case
it was not designed to handle.

Think I should open an enhancement bug report for the very unusual case?

(In reply to comment #16)
> So you say that a LVM partition which code is 8e, is the same as a Linux native
> partition which has the code 83?

One other thing I think I should clarify.  There is no difference between
type 83 and type 8e.  Unlike dos and windows, linux doesn't care what the
partition table says it contains.  You can specify anything you like in
the partition table.  Linux low level tools look inside of the partition,
to see what it contains.

You can specify vfat, ntfs, etc, for the partition type, but if you use
mkfs.ext4 to format the partition, linux will see an ext4 filesystem.

Likewise with pvcreate.  You don't have to specify 8e as the partition
type to format the partiton as a lvm physical volume.  All a partition
table entry is really used for, is to reserve space on the drive.

Some helper programs written by people who are not aware of this, may
show wrong information, but the actual low level tools like blkid are
written by people who do understand this.

Yes its correct, still disdrake should be able to perform the correct distinctions.

For example when you create an LVM using opensuse installer it does set correctly, so that when listed in fdisk it appears as "8e  Linux LVM".

In diskdrake when creating an LVM it does not set it as 'lvm', so in fdisk is listed as "83  Linux".

If you run a GUI like gparted you can easily that the one created by diskdrake, in the parameters field is not set as 'lvm', and the one created in opensuse installer is.

(In reply to comment #20)
> Yes its correct, still disdrake should be able to perform the correct
> distinctions.
> 
> For example when you create an LVM using opensuse installer it does set
> correctly, so that when listed in fdisk it appears as "8e  Linux LVM".

Then the opensuse installer is doing the wrong thing, in my opinion.

The container is not a lvm physical volume.  I have /dev/sda9 as a lvm
physical volume. I can run pvck /dev/sda9.  If sda9 were an encrypted
container, that happens to contain a lvm physical volume, the pvck
command would fail.

By using the generic type 83, scripts that look at partitions will then
use other tools to look inside of the partition, to see what is in there.

By using type 8e, the opensuse installer is setting the partition type
such that scripts will expect things like the pvck command to work with
the partition, which they won't.

The blkid command for an encrypted container correctly returns
TYPE="crypto_LUKS".  As there is no specific partition type for a crypto_LUKS
partition type , type 83 is the correct logical choice.

As stated previously, you can run luksOpen on the partition, then modify
the filesystem type inside of the encrypted container, possibly adding a
partition table, and multiple types of filesystems.  None of what is inside
of the encrypted container changes the fact that it is just a container.

So your saying that setting as 'lvm' a LVM is wrong?
So why would it exist then? 
Now your not making sense.

Being a container encrypted or not, it reports its type, thats how things work.
By the fact that you encrypt some partition (being LVM or not) that doesnt mean it will hide the partition type, it will stop you from acess it untill you enter the password.

Now what happens in drakdisk is that isnt setting the correct partition type when its creates a LVM, its simple as that.

By the way, when running drakdisk and choosing the LVM created by opensuse, it reports it correctly as being an LVM and the container was closed.

You are confusing that being encrypted and closed should not report the partition type and its one that causes the other. The fact of being closed does not stop to list the partition type.

For example fdisk doesnt show about being encrypted, however cfdisk does, and gparted lists the type as being crypt-luks but also shows the parameter 'lvm'.

(In reply to comment #22)
> So your saying that setting as 'lvm' a LVM is wrong?
> So why would it exist then? 
> Now your not making sense.

I'm saying the encrypted container, which is not a lvm
physical volume, should not be marked as an lvm physical
volume.

There are two separate and distinct devices being used.

Let's assume sda9 is the physical partition in use.

blkid /dev/sda9 will correctly show TYPE="crypto_LUKS".

Let's assume the luks device name chosen is crypt_sda9.

After you run "/sbin/cryptsetup luksOpen /dev/sda9 crypt_sda9",
then a brand new device is created called /dev/mapper/crypt_sda9.

The new device, /dev/mapper/crypt_sda9 is a lvm physical volume.
Just because the encrypted device has been opened, and the new
device that was created happens to be an lvm volume, that doesn't
change /dev/sda9 into a lvm volume.

/dev/mapper/crypt_sda9 is a lvm physical volume.
/dev/sda9 is a crypt_LUKS container, not a lvm physical volume.

They are different devices, and require different commands to
work with the contents of those devices.  That the lvm volume
is physically using some of the space inside of the luks container,
doesn't change the fact that they are logically different devices.

> Now what happens in drakdisk is that isnt setting the correct partition type
> when its creates a LVM, its simple as that.

And it shouldn't be.  It isn't setting the partition type to lvm,
because the partition dosn't contain a raw lvm physical volume.
 
> You are confusing that being encrypted and closed should not report the
> partition type and its one that causes the other. The fact of being closed does
> not stop to list the partition type.

And you continue to miss the point that the container can contain
multiple file systems of different types.  What that container
happens to contain, doesn't change the fact that it is just a
container.
 
> For example fdisk doesnt show about being encrypted, however cfdisk does, and
> gparted lists the type as being crypt-luks but also shows the parameter 'lvm'.

What if I create a partition table inside of the encrypted device
as I did in the test for Comment 18, with an ntfs filesystem, a
vfat filesystem, and a lvm physical volume, with multiple ext4
filesystems inside of that?

None of the gui partitioning tools will currently handle or show
that in a usable way.  What would you have it partition type
for the container set to, in a case like that?

You are confusing whats this bug report is all about.
This bug report was about reporting what was happening when creating LVM encrypted partitions, so why are you coming with different example that are not related to drakdisk usage?

I think i have correctly described the flaw when a LVM is created and set as encrypted, and also managed to show that drakdisk is not seting the 'lvm' parameter. And i do know what blkid reports about encrypted partitions:

]# blkid /dev/sda9
/dev/sda9: UUID="29b0ef14-a842-4386-be97-c35cb0503a63" TYPE="crypto_LUKS"

When running fdisk the 2 encrypted LVM i have (one created by mageia installer and the other created by opensuse installer it lists:

Dispositivo     Boot        Start        End      Blocks   Id  System
/dev/sda8       115607552   167349104    25870776+  8e  Linux  LVM
/dev/sda9       167350272   199270399    15960064   83  Linux

Now pay attention to this, if i run gparted and for the partition /dev/sda9 i enable the 'lvm' parameter, then gparted shows both as LVM and both are encrypted and closed:

Dispositivo     Boot        Start        End      Blocks   Id  System
/dev/sda8       115607552   167349104    25870776+  8e  Linux  LVM
/dev/sda9       167350272   199270399    15960064   8e  Linux  LVM

And the container is the LVM that can be set as encrypted or not,so again, drakdisk is failing to correctly set the LVM that creates.

To remind that in drakdisk you can *not* put several partition types inside a single encryption, each partition will have its encryption.

To do that you woulld need to put them inside an LVM, but again you have gone way beyond what was the bug report all about.

(In reply to comment #24)
> You are confusing whats this bug report is all about.
> This bug report was about reporting what was happening when creating LVM
> encrypted partitions, so why are you coming with different example that are not
> related to drakdisk usage?

I'm saying it is not a flaw.  I'm using other examples, to try and
get across why I don't think it's a flaw.
 
> I think i have correctly described the flaw when a LVM is created and set as
> encrypted, and also managed to show that drakdisk is not seting the 'lvm'
> parameter. And i do know what blkid reports about encrypted partitions:
> 
> ]# blkid /dev/sda9
> /dev/sda9: UUID="29b0ef14-a842-4386-be97-c35cb0503a63" TYPE="crypto_LUKS"
> 
> When running fdisk the 2 encrypted LVM i have (one created by mageia installer
> and the other created by opensuse installer it lists:
> 
> Dispositivo     Boot        Start        End      Blocks   Id  System
> /dev/sda8       115607552   167349104    25870776+  8e  Linux  LVM
> /dev/sda9       167350272   199270399    15960064   83  Linux

And what happens if you run "vgck /dev/sda8"?  It will fail, because
it is not a Linux LVM fileystem, despite the incorrect setting from
the opensuse installer.

> Now pay attention to this, if i run gparted and for the partition /dev/sda9 i
> enable the 'lvm' parameter, then gparted shows both as LVM and both are
> encrypted and closed:
> 
> Dispositivo     Boot        Start        End      Blocks   Id  System
> /dev/sda8       115607552   167349104    25870776+  8e  Linux  LVM
> /dev/sda9       167350272   199270399    15960064   8e  Linux  LVM
> 
> And the container is the LVM that can be set as encrypted or not,so again,
> drakdisk is failing to correctly set the LVM that creates.

NO!  The container is not an LVM physical volume, no matter what tools
other than diskdrake are showing.

> To remind that in drakdisk you can *not* put several partition types inside a
> single encryption, each partition will have its encryption.

That I agree.  However, the point of showing that it can be done, is
to help make the point that the container's type should not be set
based on the contents of the container.

> To do that you woulld need to put them inside an LVM, but again you have gone
> way beyond what was the bug report all about.

All that diskdrake would need, to support it, would be to enable
writing a partition table to the encrypted device, and then treat
it as a normal block device, like lvm volume groups, or a hard drive.

The only reason I'm going to such an extreme example, is to show that
it is not correct to set the partition type for an encrypted container
based on the contents of the encrypted device.

You are seeing things in the other way, first creates the LVM and then encrypts it.

And yes its a flaw, if is a LVM drakdisk should set it as 'lvm', like when you want some to be the boot partition it must be set as boot, like a raide needs to be set as 'raid', like you want to have a hidden partition you need to set as 'hidden'.

I really dont get why you would say its correct to *not* set a LVM as 'lvm'.

That simply makes no sense, and if things were like you say it would never be possible to see a partition type when its encrypted which is *not* the case.

fdisk always reports the partition type, being it encrypted or not.

I think all was said and i dont want to discuss more and enter in a repeat no sense mode.

When in drakdisk you create a LVM and set it as encrypted and then close drakdisk, the next time you run drakdisk it will show the partition as "Journalised FS: ext4" and this way you can NOT add any volume to the LVM since its no longer seen as a LVM.

The only way now you have to add volumes is to click in the button "Type" and set it again as a LVM.
If in first place the encrypted LVM was *really* set as LVM, instead just "Linux native", when running again drakdisk would never list the partition as "Journalised FS: ext4" and you would not need to reset the partition as LVM (again).

Now the only way i have to avoid this BUG is to reset the new encrypted LVM (that was set as 'Linux native) as a LVM partition type.

Until this BUG can be fixed, users to ensure that an encrypted LVM really stays as a encrypted LVM partition, need to change the type again to LVM after the encrypted LVM is created.

(In reply to comment #26)
> You are seeing things in the other way, first creates the LVM and then encrypts
> it.

You cannot encrypt something (lvm or a filesystem) that already exists.

What diskdrake is doing is
- create the partition (linux native)
- cryptsetup lukxFormat /dev/???
- cryptsetup luksOpen /dev/???? crypt_????
- pvcreate /dev/mapper/crypt_????

(In reply to comment #27)
> When in drakdisk you create a LVM and set it as encrypted and then close
> drakdisk, the next time you run drakdisk it will show the partition as
> "Journalised FS: ext4" and this way you can NOT add any volume to the LVM since
> its no longer seen as a LVM.
> 
> The only way now you have to add volumes is to click in the button "Type" and
> set it again as a LVM.
> If in first place the encrypted LVM was *really* set as LVM, instead just
> "Linux native", when running again drakdisk would never list the partition as
> "Journalised FS: ext4" and you would not need to reset the partition as LVM
> (again).
> 
> Now the only way i have to avoid this BUG is to reset the new encrypted LVM
> (that was set as 'Linux native) as a LVM partition type.
> 
> Until this BUG can be fixed, users to ensure that an encrypted LVM really stays
> as a encrypted LVM partition, need to change the type again to LVM after the
> encrypted LVM is created.

I just tested this on Mageia 2, and it's working fine as is.
For the test, I used diskdrake to create an encrypted lvm, and added it
to a volume group.
Closed diskdrake
Ran cryptsetup luksClose /dev/mapper/crypt_sdc1 (faster than rebooting).
Started diskdrake.
Clicked on the partition.
Selected use, and entered the passphrase.
After a few seconds, the volume group tab appeared, which I could then
select, where I could create logical volumes within the lvm.

What step specifically is not working for you?

What i meant in comment #26 was that first drakdisk first creates the linux partition and then performs crypsetup stages, i didnt explained myself in a more correct way but you made the point.

Please read with more attention what i wrote, im just repeating myself along the comments.

And i think i was more clear in comment #27, but i will try (one more time) that you can understand.

When you create an encrypted LVM in drakdisk it just creates a linux native 83 partition, instead creating a LVM 8e, and im not referring about nothing more (if you create a VG and LV's or not).

When you come back to drakdisk, the partition now appears listed as encrypted Journalised FS (ext4), and you can no longer create a VG, since it was never really a LVM one.

Now if instead you closed drakdisk, you hit the button "Type" and change the partition type to LVM (what it should happen in first place), then you can safely close drakdisk. Because when running drakdisk again will ''really'' list the partition as a (true) LVM.

So drakdisk should never set the encrypted partition as a linux native 83 type, because it will assume the linux default partition type used in drakdisk which is ext4 when running again drakdisk. And we also know that in linux we have several partition types, so setting it as linux native its almost like doing nothing.

And i also agree that this problem will only happen in a small circumstances, thats hard to happen what i just described, still is a flaw and it may happen other things that we dont know (yet).

I can confirm that if you select encrypted lvm, but do not
add it to a lvm volume group, close and restart diskdrake,
you are not given the option to add it to a lvm vg.

Note that if you change the type, as described in comment 30,
the lvm physical volume will not be encrypted.  It will be a
raw lvm pv, not stored in a luks encrypted volume anymore.

I'm not sure if this should be considered a bug, or it should
be considered as user error.

Please look at the bottom of this mail to see whether you're the assignee of this  bug, if you don't already know whether you are.


If you're the assignee:

We'd like to know for sure whether this bug was assigned correctly. Please change status to ASSIGNED if it is, or put OK on the whiteboard instead.

If you don't have a clue and don't see a way to find out, then please put NEEDHELP on the whiteboard.

Please assign back to Bug Squad or to the correct person to solve this bug if we were wrong to assign it to you, and explain why.

Thanks :)

**************************** 

@ the reporter and persons in the cc of this bug:

If you have any new information that wasn't given before (like this bug being valid for another version of Mageia, too, or it being solved) please tell us.

@ the reporter of this bug

If you didn't reply yet to a request for more information, please do so within two weeks from now.

Thanks all :-D

Is this bug still present in Mageia 4? In Mageia 5RC?

Keywords: (none) => NEEDINFO

(In reply to Samuel Verschelde from comment #33)
> Is this bug still present in Mageia 4? In Mageia 5RC?

9 months later, but still no reply.

Besides, this is already comment 34 and the report is confusing.

Please file a new bug report (if it doesn't already exist) if you think you still hit a bug about LVM and encryption in Mga5 or, preferably, cauldron (there should be mga6-dev1 isos soon)

Status: REOPENED => RESOLVED
CC: (none) => marja11
Resolution: (none) => OLD