Mailinglist Archive: opensuse-factory (826 mails)

< Previous Next >
Re: [opensuse-factory] RFC: Proposed relocation of /var/lib/rpm
On Wed, Oct 04, Josef Reidinger wrote:


sorry for top posting, but it is general feedback not specific to any part of
of email and pasting it in bottom is easy to overlook.

1. /usr/share/ sounds bad for me, as it can be often read-only FS ( e.g. on
my system it is ).

Which means you have an problem if you update man-pages anyways.

2. this snapshot and rollback make assumption that data in /var/lib is
version agnostic. Can you please specify on which data you make such
assumption? I think this is simply not true and just because we do not run it
long enough we do not face problems. But e.g. consider that mysql as part of
update migrate /var/lib/mysql to more efficient binary format and then you do
rollback. Bum! And e.g. with pgsql it is even more true, as it contain also
part of configuration. On my system is 62 entries in /var/lib and I am not
sure if every survive bigger downgrade of software that is using it.

Correct, most software is not able to handle such a version downgrade
But only think about a customer, who runs a mariadb based web shop and is
doing a rollback. Yes, the old mariadb cannot access the data, but if you
would rollback the database, the last orders would be lost.
So the whole idea behind the design is, to never loose important customer
data during a rollback.


According to this I suggest to instead move version agnostic data that should
not be snapshotted to own directory for which it is clear its purpose and
have such guarantie.


On Wed, 4 Oct 2017 13:16:58 +0200
Richard Brown <RBrownCCB@xxxxxxxxxxxx> wrote:

Hi all,

Currently, rpm stores its rpmdb (the record of all a systems packages)
in /var/lib/rpm

Various openSUSE & SUSE distributions have a number of problems with this

This has a major impact on our default btrfs snapshot & rollback feature.
We need the contents of the rpmdb contained within the snapshots.

This means /var/lib/rpm must be contained in the root snapshot in
order to preserve the "system-state";
Without it a rolled-back system still thinks it has packages
installed/removed which were changed as a result of the rollback.

But /var and /var/lib both contain a great deal of data which we DO
NOT want to include in the root snapshot;
For example, we most certainly don't want snapper rolling back a
database in /var/lib/mysql for example, and destroying user data in
the process.

Therefore we currently carry a rather complicated default list of

This list contains a number of specific directories in /var/* we wish
to preserve, which means it's almost continually out of date, leading
to user data being at risk if we haven't made a specific subvolume for
that data.

The rpmdb is the only "system-state" information we have in /var which
we need to preserve, making it quite a disruptive presence in the /var
filesystem hierarchy.

The problem is further complicated in *SUSE distributions that use a
Read-Only root filesystem (eg. openSUSE Kubic & SUSE CaaS Platform)
because it results in a situation where we really need to micromanage
countless subvolumes under /var - any location we miss otherwise ends
up read-only and packages can't write to the files they expect to be
able to in /var

Red Hat had a similar problem with their rpm-ostree tooling, which
they solved by relocating the RPM database to /usr/share/rpm

I would like to propose we adopt the same location for rpmdb in all
*SUSE distributions

This would mean we could make a single /var subvolume and dramatically
simplify our btrfs configuration

For systems with a read-only rootfs, /usr/share/rpm would be immutable
and pristine, just as we require it to be. Our tooling should already
be able to handle the new location without any major issues.

For systems with a read-write rootfs, we will be slightly bending the
rules of the FHS, in the sense that the FHS claims /usr should be
'read-only data'

However, installing packages routinely modifies the contents of /usr
and it's various subdirectories, that is the nature of installing

Therefore it seems logical to me that the record of what is installed
is also stored under the same conditions.

I'm working on a patchset in an OBS home project to test this proposal
and shake loose any issues, and will also be proposing this location
change to rpm upstream.

Therefore any comments are not only welcome, but the quicker the
better, so I can factor them into what I'm doing.

I would also like suggestions as how best to handle the migration of
an existing rpmdb in /var/lib/rpm to it's new location in
/usr/share/rpm, as I'm certain this is something we want to get
absolutely perfect, and I'm understandably nervous about changing the
rpmdb's location during an rpm transaction which will be altering the

Thanks in advance,

To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >