RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1113207 - [RFE] Support the rootfs to be a writable snapshot of a thin volume
Summary: [RFE] Support the rootfs to be a writable snapshot of a thin volume
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: anaconda
Version: 7.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: alpha
: 7.2
Assignee: Jiri Konecny
QA Contact: Release Test Team
Petr Bokoc
Depends On: 1413942 1432012
Blocks: 1082754 1172230 1191019 1205794 1243906 1444059
TreeView+ depends on / blocked
Reported: 2014-06-25 15:55 UTC by Fabian Deutsch
Modified: 2017-08-01 08:50 UTC (History)
17 users (show)

Fixed In Version: anaconda-
Doc Type: Enhancement
Doc Text:
You can now create thin logical volume snapshots during the installation process This update adds support for a new Kickstart command, "snapshot". This command allows you to create a LVM thin volume snapshot either before or after the installation. Available options are: * `<vg_name>/<lv_name>` Specify the name of the volume group and logical volume to make a snapshot of. * `--name=` Specify a name for the snapshot. * `--when=` Specify `pre-install` if you want to take a snapshot before the installation begins, which can be useful if you want to preserve the state of a system before an upgrade. Alternatively, specify `post-install` to take a snapshot of a newly installed system before any additional changes are made to it. All three options are mandatory. Also note that you can use this command multiple times in a single Kickstart file to take a snapshot both before and after the installation, or to take snapshots of multiple logical volumes. Make sure that each `-name=` parameter specifies a unique name when doing so.
Clone Of:
: 1243906 1444059 (view as bug list)
Last Closed: 2017-08-01 08:50:51 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:2293 0 normal SHIPPED_LIVE anaconda bug fix and enhancement update 2017-08-01 12:39:44 UTC

Description Fabian Deutsch 2014-06-25 15:55:19 UTC
For ovirt-node we plan to boot of writeable snapshots of thin-volumes.

For this it would be good if anaconda supported this use case.

Basically this means that a logical volume needs to be prepared by one of the ways, after the population a writeable snapshot is created, which is then used on the kernel cmdline and fstab.

Comment 2 Brian Lane 2014-06-26 22:38:29 UTC
This is something that blivet needs to implement, if it doesn't already.

Comment 3 David Lehman 2014-07-16 21:06:42 UTC
Blivet has support (on master branch) for creating LVM snapshots. Most of the logic requested by this RFE is going to live in anaconda and possibly pykickstart as I see it -- especially since there is no UI (existing or planned) in anaconda for creating snapshots.

Comment 4 Fabian Deutsch 2014-07-17 09:45:04 UTC
That sounds amazing.

And the lack of UI is likely not a problem for us, as we (a) would add custom spokes and (b) wouldn't expose this functionality in the UI anyway.

Comment 5 Fabian Deutsch 2015-01-23 17:26:21 UTC
Solving this in anaconda would really help us.

The plan is to roll out the rootfs in a thin LV using a liveimg, once that is rolled out a thin ansphot of that thin LV is taken and used as the rootfs.
That way we preserve the original root tree

Comment 6 David Lehman 2015-01-24 00:19:16 UTC
Let's see if I have this straight:

1. use liveimg payload to install to a thin root lv
2. create a writeable snapshot of root lv
3. put the snapshot into /etc/fstab, &c instead of the original root lv

Is that the whole thing? If so, that could quite easily be implemented using a %post that creates a snapshot, runs sed on the freshly installed system's /etc/fstab, then runs dracut to update initrd(s).

Comment 7 Fabian Deutsch 2015-01-26 17:25:18 UTC
(In reply to David Lehman from comment #6)
> Let's see if I have this straight:
> 1. use liveimg payload to install to a thin root lv
> 2. create a writeable snapshot of root lv
> 3. put the snapshot into /etc/fstab, &c instead of the original root lv
> Is that the whole thing?

Yes. That is the whole thing.

> If so, that could quite easily be implemented using
> a %post that creates a snapshot, runs sed on the freshly installed system's
> /etc/fstab, then runs dracut to update initrd(s).

That is our current approach which we use  (but it's not yet working correctly) for testing and developing all of the tooling.

But to make the consumption of this usage pattern easier, we'd like to get this included into anaconda.

Maybe as an option to liveimg or to the thinp related storage configuration.

Comment 8 Fabian Deutsch 2015-01-26 17:27:20 UTC
Moving it to anaconda, because according to comment 3 the support in blivet is there, it just needs support in pykickstart and anconda itself.

Comment 9 David Lehman 2015-02-20 15:47:45 UTC
Prototyping is in progress.

Comment 11 Martin Banas 2015-04-08 05:48:23 UTC
Hi Fabian,
Could you please describe step-by-step instructions how to retest this bug, or could you retest this bug once it's fixed?

Comment 12 Fabian Deutsch 2015-04-24 14:21:08 UTC
Yes, I can re-test this this bug and here are also the steps to reproduce this:

1. Install RHEL on a thinp layout with this snapshot feature enabled (possibly by setting a ks directive flag)
2. Boot into the installed OS
3. Run lsblk and look for a layout similar to this:

    │ └─vg_fdeutschlapto-thinpool-tpool
    │   ├─vg_fdeutschlapto-thinpool
    │   ├─vg_fdeutschlapto-Original
    │   ├─vg_fdeutschlapto-Layer--01

Tho I am not sure what the names of the LVs will look like (Original and Layer-01 in the example above).

Comment 14 Fabian Deutsch 2015-05-19 14:18:00 UTC
Is there any progress on this?

There was a POC ... but it's developemnt have stalled.

Comment 15 David Lehman 2015-06-23 21:07:05 UTC
It's worth noting that this will change the bootloader configuration in /boot.

Comment 21 Fabian Deutsch 2016-04-14 09:44:19 UTC
Removing the LP for now, because we are now taking a snapshot in the %post part of a ks.

Comment 23 Fabian Deutsch 2016-06-17 09:36:22 UTC
For reference: We are doing this now in the %post part of a kickstart with the following code:


This is creatign the following layout:

centos/our-nvr-based-scheme-1.0-0     <-- Snap of centos/root
centos/our-nvr-based-scheme-1.0-0+1   <-- Snap of centos/our-nvr-based-scheme-1.0-0

We'll then create a boot entry pointing to centos/our-nvr-based-scheme-1.0-0+1

Comment 24 Jiri Konecny 2016-06-20 12:32:43 UTC
Hello Fabian,

I think we can add kickstart command for snapshot creation. About using writable snapshot as /, it seems easier to me and better to use / and create the snapshot after the installation when everything is set.

It has two advantages, it's less aggressive change on the Anaconda side but also from my understanding (I'm no LVM expert) it's more support way of doing snapshots from the LVM side.

Is this usable solution for your use-case?


Comment 25 Fabian Deutsch 2016-06-23 21:27:38 UTC
The methology suggested in comment 24 is also valuable, but does not align with what we are now using in RHEV-H.

I am not sure if we could migrate our current mechanism to the method described in comment 24.

In the end making the suggested change in comment 24 would not help us specifically, but when it is around, then we might consider to move to that mechanism.

Comment 28 Jiri Konecny 2017-04-05 11:58:12 UTC
Oops bad link, this is the good one:

Anaconda PR: https://github.com/rhinstaller/anaconda/pull/1002

Comment 32 Jiri Konecny 2017-05-15 11:04:12 UTC
In process of backporting this feature to master, I found myself a bug. 
The UUID generator for an XFS snapshots worked only for a post-installation snapshots, it didn't change UUID for a pre-installation snapshots.

Issue is fixed by PR:

For this fix to work properly this Blivet's PR is required to be merged:


Comment 33 Petr Bokoc 2017-05-23 11:42:38 UTC
Hi Jirka, can you please take a look at the Doc Text (for Release Notes) and let me know if it's fine? Thanks!

Comment 34 Jiri Konecny 2017-05-23 13:22:18 UTC
Hi Petr,

It looks fine I just have two ideas for an improvement.

* Move the '--name' as the first parameter because it is lets say more significant.
* The '--when=[pre-install|post-install]' parameter is slightly confusing to me. I would need to think if it is mandatory to specify 'pre-install|post-install' (it is mandatory) or I can use it as '--when' and it will default to something.

Otherwise it looks great to me!


Comment 35 Peter Kotvan 2017-06-20 11:24:59 UTC
I was not able to verify this bug due to a bug 1463198.

Comment 36 Peter Kotvan 2017-06-20 13:01:38 UTC
This as actually not blocked by bug 1463198 after all. 

I was able to verify the current solution on RHEL-7.4-20170616.3 with anaconda-


Comment 37 errata-xmlrpc 2017-08-01 08:50:51 UTC
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, and where to find the updated
files, follow the link below.

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


Note You need to log in before you can comment on or make changes to this bug.