Recently I've migrated my homeserver from Fedora to ArchLinux. Which
gives me the headache of installing Cockpit (since i like it a lot :)
) on Archlinux.
I've seen the AUR package, but it has an insane amount of dependencies
and i don't understand some of them. (Compiling from source gives the
same dependencies, so the're not wrong...)
Is there some kind of dependency tree/graph for *all* components
needed for compiling Cockpit from source (and maybe why they are
Some of the components that I didn't like that one way or another were
needed as a dependency:
- some LateX stuff
All the help/info is welcome!
I have these messages when I load cockpit in firefox:
$ rpm -qa|grep cockpit
I have an idea for cockpit, but before thinking it further, I'm
interested in hearing your opinions. I am oVirt developer mostly
dealing with system stuff and this is something that could be useful
in virtualization while also providing utility for administrators
The idea is about new tab/plugin (not sure of the terminology) called
'devices', that would allow access to (hardware) devices as exposed by
sysfs. The interface could be similar to 'Services' tab/plugin,
showing a list of device names created from their physical location,
similarly to libvirt's nodedev-list.
After clicking on the name, new screen would be presented, showing
additional information such as
* physical address,
* driver in use,
* special capabilities (SR-IOV numvfs and totalvfs, NPIV max_vports,
* iommu group (possibly clickable to reveal all devices in given
* vendor, vendor id, product, product id.
Additionally, it makes sense to allow some basic operations:
* unbinding from host driver, binding it to specific one (useful for
local vfio-pci testing),
* reattaching it back (one use case is that
oVirt does not reattach devices automatically due to possible
issues, needs user intervention),
* setting numvfs, vports,
* ... ?
Do you find ideas above reasonable for cockpit? It is mostly in idea
phase, and builds on development and requirements of oVirt. I
personally believe that this could be useful for broader audience.