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@xxxxxxxxx > * Name: Lennart Poettering > * Email: mzsrqben@xxxxxxxxxxxx > > > == 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.html), > 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 :| _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
