Bug 2011329

This is a good question, I expected that only PVs created by the installation would be added to system.devices.  It seems a little odd that a newly installed system will have pre-existing, attached lvm devices that it intends to use... but maybe not so strange after all.  

It's difficult or impossible to know if the new system should own and use data on existing devices.  If we give the new system access to the data, but its actually owned and used by something else, then we have possible corruption of the data.   If the new system should own and use the existing PVs, it may be difficult for the user to figure out how to give the new system access to those devices (they'll need to find an learn about the lvmdevices or vgimportdevices commands, although they'll need to do this eventually anyway.)

The previous system that is being re-installed may have used filters in lvm.conf to exclude the existing devices to protect them, but we likely can't know which devices the previous system was accessing.

So this a balance between protecting the data in some cases and ease of use in other cases.

An awkward middle ground might be to give the new system access to all the devices, but modify the existing VGs (or modify lvm.conf) to not auto-activate those VGs on the new system.  Disabling auto-activation of existing VGs might be somewhat complicated to set up by the installer, and similar to the usability issue above, may require the user to learn about configuring auto-activation to change it.

OK, let's say we have the following use cases:
1) LVM VG created by the installer during the installation.
   ACTION: The created PVs have to be added to system.devices

2) LVM VGs/LVs created before the installation and re-used during the installation (for example LV from the existing VG is mounted as /home in anaconda GUI during the installation)
   ACTION: The used PVs have to be added to system.devices.

3) System with 2 disks, the new system will be installed to the first disk only. The second disk contains an existing VG. Both disks are selected during the installation in anaconda GUI, but the second disk is not used at all. Should the PVs from the second disk be added to system.devices?
   ACTION: ?

4) System with 2 disks, the new system will be installed to the first disk. The second disk contains an existing VG. Only the first disk is selected to be used during the installation in anaconda GUI. Should the PVs from the second disk be added to system.devices?
   ACTION: ?


I think we can ignore the question if the LVM devices are used by something else or not - we do not have this information currently either and all LVM devices are visible to the users by default. Let's assume it's safe to add any PV available on the system to system.devices.

I would also like to prevent doing any changes to lvm.conf to disable auto-activation of VGs. If it is needed, it should be tracked as a separate feature request.

Adding all PVs available on the system (no matter if they were used or not) to system.devices seems like the least disruptive change for the users migrating from RHEL-8 or earlier releases, but it's up to you, LVM team, to say how the feature is supposed to be configured for new installations in use cases 3 and 4. (But feel free to add any other use cases).

(In reply to Jan Stodola from comment #4)
> OK, let's say we have the following use cases:
> 1) LVM VG created by the installer during the installation.
>    ACTION: The created PVs have to be added to system.devices

yes

> 2) LVM VGs/LVs created before the installation and re-used during the
> installation (for example LV from the existing VG is mounted as /home in
> anaconda GUI during the installation)
>    ACTION: The used PVs have to be added to system.devices.

yes

> 3) System with 2 disks, the new system will be installed to the first disk
> only. The second disk contains an existing VG. Both disks are selected
> during the installation in anaconda GUI, but the second disk is not used at
> all. Should the PVs from the second disk be added to system.devices?
>    ACTION: ?

I'm not sure what "selecting the second disk" means in the user interface.  By "not used at all" do you mean that anaconda does not use the disk, or that it has not previously been used for lvm, i.e. it doesn't have a VG on it.

> 4) System with 2 disks, the new system will be installed to the first disk.
> The second disk contains an existing VG. Only the first disk is selected to
> be used during the installation in anaconda GUI. Should the PVs from the
> second disk be added to system.devices?
>    ACTION: ?

I suggest we exclude it and err on the side of caution to avoid potentially corrupting data on that disk (by using a VG that's being used by someone else.)

> I think we can ignore the question if the LVM devices are used by something
> else or not - we do not have this information currently either and all LVM
> devices are visible to the users by default. Let's assume it's safe to add
> any PV available on the system to system.devices.

How is this different from 4, where you have existing PVs?

> Adding all PVs available on the system (no matter if they were used or not)
> to system.devices seems like the least disruptive change for the users
> migrating from RHEL-8 or earlier releases, but it's up to you, LVM team, to
> say how the feature is supposed to be configured for new installations in
> use cases 3 and 4. (But feel free to add any other use cases).

I would probably agree that in most cases it's safe to include all existing PVs.  However, the small number of cases where it's not safe could lead to more serious problems.  An example of a problematic case is when a system is connected to a SAN with VGs belonging to other systems.  After you install a new system, the first time it boots it would attempt to activate all the VGs it sees on the SAN that are currently in use by other machines.  A smart admin will have set a system ID on these VGs which would protect them from this also. 

Perhaps this has been the historical behavior of anaconda, and users are aware of the dangers of a "greedy" default installation, and know how to protect against it.  In that case it's probably justified to continue allowing it.

(In reply to David Teigland from comment #5)
> (In reply to Jan Stodola from comment #4)
> 
> > 3) System with 2 disks, the new system will be installed to the first disk
> > only. The second disk contains an existing VG. Both disks are selected
> > during the installation in anaconda GUI, but the second disk is not used at
> > all. Should the PVs from the second disk be added to system.devices?
> >    ACTION: ?
> 
> I'm not sure what "selecting the second disk" means in the user interface. 
> By "not used at all" do you mean that anaconda does not use the disk, or
> that it has not previously been used for lvm, i.e. it doesn't have a VG on
> it.
> 

You can select which disks will be used during the installation. In the interactive installation you need to physically select disks to use for auto or manual partitioning[1], with kickstart you can limit disks that will be used with the ignoredisk command[1]. Just because a disk is selected it doesn't mean it will be actually used for the new system or it can be used but the existing VG on it isn't.

Similar situation can also happen with a single disk with preexisting VG (e.g. from a different RHEL installation) and we use existing free space on the disk to create a new VG for the new installation. The new VG will be added to the system.devices file but should we add also the preexisting VG when the disk was used during installation but the preexisting was not used?


[1] https://docs.fedoraproject.org/en-US/fedora/rawhide/install-guide/_images/anaconda/StorageSpoke_Selected.png
[2] https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#ignoredisk


> > 4) System with 2 disks, the new system will be installed to the first disk.
> > The second disk contains an existing VG. Only the first disk is selected to
> > be used during the installation in anaconda GUI. Should the PVs from the
> > second disk be added to system.devices?
> >    ACTION: ?
>
> I suggest we exclude it and err on the side of caution to avoid potentially corrupting data on that disk (by using a VG that's being used by someone else.)

Potential use case for this could be "protecting" the second VG during the installation from being removed/changed by accident. Users can have a separate VG for virtualization for example and it won't be visible in the newly installed system which could be really confusing.

> Similar situation can also happen with a single disk with preexisting VG
> (e.g. from a different RHEL installation) and we use existing free space on
> the disk to create a new VG for the new installation. The new VG will be
> added to the system.devices file but should we add also the preexisting VG
> when the disk was used during installation but the preexisting was not used?

I don't think there's a clearly right or wrong answer, but I wouldn't add the other VG.

> > > 4) System with 2 disks, the new system will be installed to the first disk.
> > > The second disk contains an existing VG. Only the first disk is selected to
> > > be used during the installation in anaconda GUI. Should the PVs from the
> > > second disk be added to system.devices?
> > >    ACTION: ?
> >
> > I suggest we exclude it and err on the side of caution to avoid potentially corrupting data on that disk (by using a VG that's being used by someone else.)
> 
> Potential use case for this could be "protecting" the second VG during the
> installation from being removed/changed by accident. Users can have a
> separate VG for virtualization for example and it won't be visible in the
> newly installed system which could be really confusing.

I think you're saying that if the other VG is included in system.devices, then that will make it more visible to the user that the disk is being used by a VG.  If they see the disk has VG on it, then they are less likely to accidentally use the disk for some other purpose, protecting it.  That sounds logical.  There is also the chance that the other VG is being used by a vm (e.g. the vm's root VG), and by including that VG on the host, then both the host and the vm will be activating the same VG, which can corrupt it (cases of that happening was one of the motivations for introducing the devices file.)

If the installer has historically created new systems with access to everything, then maybe consistency with that should be the basis for the decision, and we should include everything possible.  I'd personally prefer the maximally limited default, and let users expand access as needed.  But I understand this could be disruptive for users in ways that I'm totally unaware of, so I can't argue strongly for this.

Code written, tested manually, on review, needs unit tests: https://github.com/rhinstaller/anaconda/pull/3771

anaconda-34.25.0.24-1.el9 is included in RHEL-9.0.0-20220117.0.
The problem found in comment 14 is tracked in bug 2040302 and possible regressions will be reported as new bugs as well.

Moving this bug to VERIFIED.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (new packages: anaconda), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:2326