On Mon, Oct 25, 2021 at 03:09:00PM -0400, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects
== Summary ==
All binaries (executables and shared libraries) are annotated with an
ELF note that identifies the rpm for which this file was built. This
allows binaries to be identified when they are distributed without any
of the rpm metadata. `systemd-coredump` uses this to log package
versions when reporting crashes.
== Owner ==
* Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]]
* Email: zbyszek(a)in.waw.pl
* Name: Lennart Poettering
* Email: mzsrqben(a)0pointer.net
== Detailed Description ==
The directly motivating use case is display of core dumps. Right now
we have build-ids, but those are just opaque hexadecimal numbers that
are not meaningful to users. We would like to immediately list
versions of packages involved in the crash (including both the program
and any libraries it links to). It is not enough to query the rpm
database to do the equivalent of `rpm -qf …`: very often programs
crash after some packages have been upgraded and the binaries loaded
into memory are not the binaries that are currently present on disk,
or when through some mishap, the binaries on disk do not match the
installed rpms. A mechanism that works without rpm database lookup or
network access allows this information to be showed immediately in
`coredumpctl` listings and journal entries about the crash. This
includes crashes that happen in the initrd and sandboxed containers.
Getting RPM NEVRs directly from the coredumps is something that
will be incredibly helpful for people dealing with support
requests after crashes. build-ids have always been very tedious
to deal with and as you say RPM database may be newer than what
is in memory. This benefit alone will make it all worthwhile
from my POV.
=== Why not just use the rpm database? ===
<pre>
17:34:33 <dcantrell> The main reason for this appears to be that we
need the RPM db locally to resolve build-ids to package names. But
since containers wipe /var/lib/rpm, we can't do that. So the solution
is to put the ''nevra'' in ELF metadata?
17:34:39 <dcantrell> That feels like the wrong approach.
</pre>
First, there are legitimate reasons to strip packaging metadata from
images. For example, for an initrd image from rpms, I get 117 MB of
files (without compression), and out of this `/var/lib/rpm` is 5.9 MB,
and `/var/lib/dnf` is 4.2 MB. This is an overhead of 9%. This is ''not
much'', but still too much to keep in the image unless necessary.
Similar ratios will happen for containers of similar size. Reducing
image size by one tenth is important. There is no `rpm` or `dnf` in
the image, to the package database is not even usable without external
tools.
As discussed on IRC
(
https://meetbot.fedoraproject.org/teams/fesco/fesco.2021-05-11-17.01.log....),
the containers ''we'' build don't wipe this metadata, but custom
Dockerfiles do that.
Also even if the RPM database is present, it might not reflect the
NEVRs of what is resident in-memory.
Furthermore as someone dealing with bug reports I don't have access
to the RPM database. That is on the end user's machine. Often all I
get is a core dump attached to a bug report, and if I'm lucky they
manually typed a couple of RPM NEVRs into the bug description. On
many occassions I've found the NEVRs the user supplied in the
description to be wrong due to mistakes on the bug reporter's side
collecting the data.
Regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|