New Package Request: pciutils

[samcday]

What, if any, are the additional dependencies on the package? (i.e. does it pull in Python, Perl, etc)

Checking out tree 88148fa... done
Enabled rpm-md repositories: fedora-cisco-openh264 updates fedora kubernetes updates-archive
Updating metadata for 'fedora-cisco-openh264'... done
Updating metadata for 'updates'... done
Updating metadata for 'fedora'... done
Updating metadata for 'kubernetes'... done
Updating metadata for 'updates-archive'... done
Importing rpm-md... done
rpm-md repo 'fedora-cisco-openh264'; generated: 2024-03-12T11:45:42Z solvables: 3
rpm-md repo 'updates'; generated: 2024-08-15T02:25:25Z solvables: 24000
rpm-md repo 'fedora'; generated: 2024-04-14T18:51:11Z solvables: 74881
rpm-md repo 'kubernetes'; generated: 2024-08-14T22:14:11Z solvables: 90
rpm-md repo 'updates-archive'; generated: 2024-08-09T04:04:59Z solvables: 32107
Resolving dependencies... done
Installing 2 packages:
  pciutils-3.13.0-1.fc40.x86_64 (updates)
  pciutils-libs-3.13.0-1.fc40.x86_64 (updates)
Exiting because of '--dry-run' option

What is the size of the package and its dependencies?

~ » rpm -qi pciutils
Name        : pciutils
Version     : 3.13.0
Release     : 1.fc40
Architecture: x86_64
Install Date: Tue 13 Aug 2024 02:39:39 AM CEST
Group       : Unspecified
Size        : 250377
License     : GPL-2.0-or-later
Signature   : RSA/SHA256, Wed 05 Jun 2024 11:23:38 AM CEST, Key ID 0727707ea15b79cc
Source RPM  : pciutils-3.13.0-1.fc40.src.rpm
Build Date  : Wed 05 Jun 2024 11:14:19 AM CEST
Build Host  : buildhw-x86-05.iad2.fedoraproject.org
Packager    : Fedora Project
Vendor      : Fedora Project
URL         : https://mj.ucw.cz/sw/pciutils/
Bug URL     : https://bugz.fedoraproject.org/pciutils
Summary     : PCI bus related utilities
Description :
The pciutils package contains various utilities for inspecting and
setting devices connected to the PCI bus.
~ » rpm -qi pciutils-libs
Name        : pciutils-libs
Version     : 3.13.0
Release     : 1.fc40
Architecture: x86_64
Install Date: Tue 13 Aug 2024 02:39:37 AM CEST
Group       : Unspecified
Size        : 101857
License     : GPL-2.0-or-later
Signature   : RSA/SHA256, Wed 05 Jun 2024 11:23:38 AM CEST, Key ID 0727707ea15b79cc
Source RPM  : pciutils-3.13.0-1.fc40.src.rpm
Build Date  : Wed 05 Jun 2024 11:14:19 AM CEST
Build Host  : buildhw-x86-05.iad2.fedoraproject.org
Packager    : Fedora Project
Vendor      : Fedora Project
URL         : https://mj.ucw.cz/sw/pciutils/
Bug URL     : https://bugz.fedoraproject.org/pciutils
Summary     : Linux PCI library
Description :
This package contains a library for inspecting and setting
devices connected to the PCI bus.

What problem are you trying to solve with this package? Or what functionality does the package provide?

lspci is a very useful command. It's not something you typically need that often, but when you do need it, there's not really any good alternative, as far as I'm aware.

Can the software provided by the package be run from a container? Explain why or why not.

I don't think so? It's scanning the system busses and stuff, I can't imagine that works in containers without a lot of shenanigans.

Can the tool(s) provided by the package be helpful in debugging container runtime issues?

If your container runtime is somehow hosted on a PCI-express card ... maybe? :)

Can the tool(s) provided by the package be helpful in debugging networking issues?

That's what I needed it for today - I wanted to check the PCI ID of the NIC I have in a CoreOS machine.

Is it possible to layer the package onto the base OS as a day 2 operation? Explain why or why not.

Yep, can totally just install it when it's needed.

In the case of packages providing services and binaries, can the packaging be adjusted to just deliver binaries?

N/A

Can the tool(s) provided by the package be used to do things we’d rather users not be able to do in FCOS?

Don't think so.

Does the software provided by the package have a history of CVEs?

I sure hope not.

[Nemric]

Hi, did you try to use lspci within the toolbox ? https://docs.fedoraproject.org/en-US/fedora-coreos/debugging-with-toolbox/

[samcday]

I just confirmed that lspci does indeed work from a toolbox. I assumed it wouldn't because I had a few issues with USB utilities in Toolbox under Silverblue.

That said, trying to use toolbox on my FCOS nodes first ran into the issue with /etc/localtime that causes toolbox enter to fail with Error: invalid entry point PID of container fedora-toolbox-40. Furthermore, a F40 toolbox weighs about 400MB, which seems excessive in order to use lspci (which weighs ~150kb including the pciutils-libs package).

[jbtrystram]

You can set a time zone following by linking a tz file from /usr/share/zoneinfo to /etc/localtime

https://docs.fedoraproject.org/en-US/fedora-coreos/time-zone/

That's said, we should provide a default file so it doesn't break toolbox.

[samcday]

Noted, thanks. I "solved" it for a quick test by yeeting that file ;) I personally moved away from Toolbx usage after experiencing too much friction with it throughout Silverblue daily driving usage. I have been using CoreOS in various environments for quite a while now and never find myself needing Toolbx on my cattle compute.

If anything, the alternative I'd go for in situations like this is rpm-ostree usroverlay && dnf install foo.

[jbtrystram]

As the desired functionality can be achieved with a privileged container, we can close this.

I filed a separate issue for the missing localtime file

[samcday]

I'd rather we not close this just yet for the reasons I stated above (400MB is a much larger number than 350KB). Thanks for opening that other issue though :D

[samcday]

Just to expand on this a little ... I'd prefer a bit more discussion on this issue or at least one more FCOS maintainer to step in and say "yeah nah thx" before we close. My main concern is that if "package is available in a Toolbox" is an automatic trump card to packages being considered for inclusion in the base ... well, by that logic why have anything in the host image except for rpm-ostree + containerd + ash? ;)

In particular, I think for situations like this other considerations are relevant:

• Package size
• Is the package/utility typically available by default in other popular (server/DC-oriented) distros?
• How frequently is such a tool needed?

Judging these criteria is going to still be a subjective art, of course. ;)

I don't really care about whether this specific package is included since I'm customizing my own images anyway.

It just seems that, if the only criteria that we care about is "can it only run from the host and not a toolbox?", then I would be opening some follow-up issues to remove packages like bind-utils, nvme-cli, nfs-utils-coreos and so on. Heck, if we take that logic to the extreme, why even have dracut in the base image? You could just have rpm-ostree initramfs delegating to a privileged container to run dracut ;)

[jbtrystram]

Let's discuss this in the next community meeting, can you join ? We hold them on Wednesdays, 16:30 UTC

https://fedoraproject.org/coreos/community/

[samcday]

Sure thing, see you there :)

[travier]

You could make a smaller container image that only has pciutils installed and run it directly with podman to avoid toolbox.

But that would not help in cases where you need the tool to help diagnose networking issue.

I'm tempted to say +1 for inclusion but discussing it a bit more when more folks are back would help, notably for context around why it wasn't included already (might be a historical reason). It's likely that a lot of folks will be out of office for this week's meeting so we may push that discussion back a bit.

[samcday]

You could make a smaller container image that only has pciutils installed and run it directly with podman to avoid toolbox.

Mmm, frankly I consider this option an absolute last resort. If the conclusion from this issue ends up being not to include this utility, and I needed lspci on a regular enough basis, I would just layer it into my FCOS installations (or bake it into my custom image as I've already done). For the ad-hoc case I think it's better to just rpm-ostree usroverlay && dnf install it. If for some reason neither of those were an option, then I just confirmed this works on a FCOS host as well:

sudo docker run --privileged -it busybox:stable lspci -v

... Which is interesting, actually. Makes me wonder if a reasonable solution to this + the spirit of #628 is to include busybox in the base image and run busybox --install early (or late? depends on the semantics of busybox --install which I do not know off the top of my head) in the image compose so that any utilities that don't get a full-fat Fedora-packaged version still have a basic version available.

But that would not help in cases where you need the tool to help diagnose networking issue.

Excellent point, and I think this is a solid inclusion into the "what criteria do we decide if a package is included?" list I started on above. I would submit that usbutils falls into a similar category here. You might be running FCOS on a machine with a USB wifi/wired NIC and that utility might come in handy when debugging network problems.

[yasminvalim]

We discussed this in our community meeting today and agreed to include the pciutils package. You can check the discussion logs here.

[samcday]

Oops, apologies for missing the meeting when I said I'd attend :flushed: I was in deep focus mode the last week or so and left most Matrix channels, forgot to rejoin the CoreOS channel after I said I'd attend that meet.

(It'd be cool if the meeting label had some automation that commented on the issue when a meeting is coming up soon!)

I read the meeting transcript and am happy with the thorough discussion this issue received, thanks!

[jbtrystram]

(It'd be cool if the meeting label had some automation that commented on the issue when a meeting is coming up soon!)

Good idea ! Filed https://github.com/coreos/fcos-meeting-action/issues/106

[marmijo]

The fix for this went into testing stream release 40.20240906.2.0. Please try out the new release and report issues.

[Nemric]

lspci works great in next stream 40.20240906.1.0 ;)

[dustymabe]

The fix for this went into stable stream release 40.20240906.3.0.