A way to ensure rpm database robustness?

[Panu Matilainen]

On 01/03/2013 01:56 PM, Reshetova, Elena wrote:
> Hi,
>
> I have a simple question and sorry if it was asked before and I just didn't
> find it in archives.
>
> Suppose we run rpm operation (installation, update or anything) on an
> embedded device and power suddenly goes off. This can happen if user removes
> the battery for example.
>
> In such cases, rpm database can get corrupted since the operation was
> stopped in the middle. Rpm database can be rebuild after, but this is quite
> annoying to do. Is there any ways to ensure that database stays sane even in
> such cases? Of course some wrapper can be used for rpm to do the checks,
> backup database and etc., but does rpm itself have anything for it?

No, rpm currently has practically zero protection against such 
scenarios, be it from accidentally tripping over the power cord, system 
crash or pulling out the battery. Or even just executing 'shutdown -h now'.

Inconsistent database is just one part of the resulting mess: files or 
partial files can be left around, scriptlets might have been executed 
resulting in untrackable changes etc. And what happens if we were 
executing a scriptlet while power went out is anybodys guess.

The database could be made to use transactions (its just a bit tricky in 
presence of chroots) but that doesn't help the rest of the system. Rpm 
would have to use write-ahead log mechanism for *everything* it does, 
but even that wouldn't help the scriptlets aborted in mid-flight: 
something like ldconfig might be safely repeatable from rpm POV but 
ldconfig's ability to deal with malformed cache from getting interrupted 
is up to ldconfig. And then take some more complex script that can do 
arbitrary manipulation on various text and binary files...

The only sledgehammer that supposedly works for all these is 
filesystem-level snapshots, but then that has its own issues.

	- Panu -