We miss "kinfo" for GNOME

KDE Plasma has a very nice and compact way to get system info, in text.

I rewrote that once in bash and extended it a bit, to include more useful things like GPU info, GPU RAM and package manager integration.

It is currently broken.

On Fedora we only have fpaste, which has a complex CLI interface (with the default not being local), takes pretty long and produces a rather huge output for most use cases.

We struggle a bit because of that lack. Could fpaste maybe get an alias to produce more compact, simpler, local output?

I have this on the back burner, but it’s there if anyone is willing to have a look into the code and ways to improve it.

2 Likes

So, it takes long when it’s getting repodata—because if the user has not been using their user cache, this needs to be updated.

If we’re happy to get rid of that particular bit (perhaps an --offline option that runs dnf -C or something, or parses the repo files instead of using dnf repolist), it’ll be quicker. The other commands don’t really take much time.

As noted, please file these issues at fpaste and they can be all be worked on. It’s just a python script, so it’s easy to modify.

1 Like

Interesting, what happens on Silverblue then? Does it fail, or error out or something?

I don’t think we handle silverblue as a special case now. We have no rpm-ostree commands in fpaste at the moment at all from what I remember:

https://pagure.io/fpaste/blob/main/f/fpaste

1 Like

Added silverblue-team

Looking at the original post, something similar to kinfo, in text format, could be obtained under GNOME by going to the Settings app -> System -> About -> System Details, and from there hitting the Copy button.

Example:
(Disk capacity missing, maybe because the system is virtualized)

# System Details Report
---

## Report details
- **Date generated:**                              2024-07-16 16:43:55

## Hardware Information:
- **Hardware Model:**                              VMware, Inc. VMware20,1
- **Memory:**                                      5.7 GiB
- **Processor:**                                   Intel® Core™ i7-9750H × 2
- **Graphics:**                                    SVGA3D; build: RELEASE; LLVM;
- **Disk Capacity:**                               (null)

## Software Information:
- **Firmware Version:**                            VMW201.00V.21805430.B64.2305221830
- **OS Name:**                                     Fedora Linux 40 (Workstation Edition)
- **OS Build:**                                    (null)
- **OS Type:**                                     64-bit
- **GNOME Version:**                               46
- **Windowing System:**                            Wayland
- **Kernel Version:**                              Linux 6.9.8-200.fc40.x86_64

4 Likes

Yes this is good! Is there a cli interface for that?

  1. Because CLIs are just better
  2. If users cant login graphically

I will have to search for that.

I have made some research, and, unfortunately, gnome-control-center doesn’t have CLI output options. Nor did I find anything else GNOME-specific which would bring system information to the CLI.

The closest I have found, and is DE-agnostic, is fastfetch. Unfortunately it is not installed by default on Fedora, however, it has a really small footprint. Can be run without generating logo, with fastfetch -l none.

1 Like

Possibly look into GCC’s gsettings …
dbus-launch gsettings list-schemas

2 Likes

I’ve never seen that work, including today F40, and I’m even doing the most boring partition layout possible (standard, no home, giant root as ext4).

Someone on QA should probably look at that, especially if they take the time to have a virtualization tag :stuck_out_tongue:

https://paste.centos.org/view/3a4b2b3f

Does something like this work?

1 Like

If we are still talking about the GNOME Settings app (gnome-control-center) displaying disk capacity, it is working for me with a bare metal install on SSD, so I don’t know if it is virtual machine vs bare metal, or rather nvme vs ssd.

2 Likes

Ah, I have NVMe on bare-metal

1 Like

For me, it works on baremetal nvme and in a virtual machine (GNOME Boxes).

1 Like

Interesting. I wonder if it expects LVM or defaults with Btrfs maybe?


Here’s my df -hT:

Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/nvme0n1p3 ext4      915G  112G  757G  13% /
devtmpfs       devtmpfs  4.0M     0  4.0M   0% /dev
tmpfs          tmpfs     7.8G     0  7.8G   0% /dev/shm
efivarfs       efivarfs  384K   85K  295K  23% /sys/firmware/efi/efivars
tmpfs          tmpfs     3.1G  2.0M  3.1G   1% /run
tmpfs          tmpfs     7.8G   20K  7.8G   1% /tmp
/dev/nvme0n1p2 ext4      974M  418M  489M  47% /boot
/dev/nvme0n1p1 vfat      599M   20M  580M   4% /boot/efi
tmpfs          tmpfs     1.6G  160K  1.6G   1% /run/user/1000

As far as I an understand, such value is calculated using udisks.

1 Like

The thread seems to evolve in a similar direction as my “kde sysinfo” rewrite.

I just looked for random commands to show the output.

  1. Package manager integration, just checking if the command is available and using $1 as search query, works really well
  2. Software things (most are broken in KDE 6 so I need to rewrite and maybe just use kinfo)
  3. Additional hardware stuff

Disk usage should be BTRFS native.

I think it would make sense to do a more minimal version of fpaste. Maybe by using a set of flags, and likely by contributing there. Anybody good in python? :face_with_peeking_eye:

Then apparently gnome-control-center is missing to get the correct data from udisks.

Some snippets from udisksctl dump:

...
org.freedesktop.UDisks2.Filesystem:
    MountPoints:        /
                        /home
    Size:               30490492928
...
/org/freedesktop/UDisks2/block_devices/nvme0n1:
  org.freedesktop.UDisks2.Block:
  ...
  Device:                     /dev/nvme0n1
    Size:                       32212254720
...

So the needed information seems to be there.