search

fedora-silverblue / issue-tracker

Fedora Silverblue issue tracker
https://fedoraproject.org/atomic-desktops/silverblue/
125 stars 3 forks source link

GNOME Color Settings do not work on Silverblue 40 OCI container image #586

Open hrismarin opened 1 month ago

hrismarin commented 1 month ago

Describe the bug By clicking Settings → Color, the tab does not show the color settings. 

systemctl status colord.service

× colord.service - Manage, Install and Generate Color Profiles
     Loaded: loaded (/usr/lib/systemd/system/colord.service; static)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: failed (Result: exit-code) since Sat 2024-08-03 10:00:09 EEST; 11s ago
    Process: 11456 ExecStart=/usr/libexec/colord (code=exited, status=238/STATE_DIRECTORY)
   Main PID: 11456 (code=exited, status=238/STATE_DIRECTORY)
        CPU: 15ms

авг 03 10:00:09 silverblue systemd[1]: Starting colord.service - Manage, Install and Generate Color Profiles...
авг 03 10:00:09 silverblue (colord)[11456]: colord.service: Failed to set up special execution directory in /var/lib: Permission denied
авг 03 10:00:09 silverblue systemd[1]: colord.service: Main process exited, code=exited, status=238/STATE_DIRECTORY
авг 03 10:00:09 silverblue systemd[1]: colord.service: Failed with result 'exit-code'.
авг 03 10:00:09 silverblue systemd[1]: Failed to start colord.service - Manage, Install and Generate Color Profiles.

To Reproduce

  1. Rebase to image derived from quay.io/fedora-ostree-desktops/silverblue:40.
  2. Click on Settings → Color.
  3. Execute systemctl status colord.service.

Expected behavior The GNOME Color Settings tab should display the relevant color settings. colord.service should not fail.

Screenshots image

OS version:

State: idle
BootedDeployment:
● ostree-image-signed:registry:quay.io/operatement/fedora-silverblue:40-base
                   Digest: sha256:1809bb2deea6f2985570fd384e50fe3c1f13107cd848f19f87fea8e9ef2c2b50
                  Version: 40.20240803.0 (2024-08-03T04:09:33Z)

Additional context It turns out that the group of /var/lib/colord/icc directory is openvpn, while on the non-OCI (classic OSTree) and quay.io/fedora-ostree-desktops/silverblue:rawhide images is colord. 

ls -la /var/lib/colord/icc

total 0
drwxr-xr-x. 1 colord openvpn  0 11 окт 2023 .
drwxr-xr-x. 1 colord colord  58 11 окт 2023 ..

Changing the group of /var/lib/colord/icc to colord has no effect, as triggering Settings → Color or restarting colord.service changes the group back to openvpn.

fedelibre commented 1 month ago

AFAIK color calibration never worked on Silverblue. See this old discussion: https://gitlab.gnome.org/GNOME/gnome-color-manager/-/issues/16

When I plug my ColorMunki nothing happens.

hrismarin commented 1 month ago

@fedelibre I'm not sure about calibrating monitor/display colors using various hardware or software tools and their dependencies as I don't currently practice professional image/video editing.

This issue here is for a specific Fedora Silverblue image that isn't even officially supported yet.

As I stated in the issue, GNOME's color settings work fine (at least for the everyday stuff I use them for) in the official non-OCI (classic OSTree) and also in the Rawhide version of the OCI container images.

travier commented 3 weeks ago

hanging the group of /var/lib/colord/icc to colord has no effect, as triggering Settings → Color or restarting colord.service changes the group back to openvpn.

This is really weird.

Can you post the lines for openvpn & colord from:

Thanks

hrismarin commented 3 weeks ago

The GID values ​​(numbers) of classic (non-OCI) Silverblue 40 and OCI Silverblue 40 images in /usr/lib/passwd and /usr/lib/group have been swapped.

Classic (non-OCI) Silverblue 40 image:

 hricky@silverblue  >_ sudo rpm-ostree status 

State: idle
Deployments:
● fedora:fedora/40/x86_64/silverblue
                  Version: 40.20240820.0 (2024-08-20T01:01:41Z)
               BaseCommit: e45ee5cb506f6ddc4fbe0d4274635e656c294b6e99e795dadc44c698a1fb6ffe
             GPGSignature: Valid signature by 115DF9AEF857853EE8445D0A0727707EA15B79CC
      RemovedBasePackages: nano nano-default-editor 7.2-7.fc40 noopenh264 0.1.0~openh264_2.4.0-1.fc40
          LayeredPackages: akmod-nvidia arm-image-installer coreos-installer gnome-console mozilla-openh264 qemu-kvm rpmfusion-free-release rpmfusion-nonfree-release smartmontools vim
                           vim-default-editor virt-install virt-manager
                   Pinned: yes
...

 hricky@silverblue  >_ grep --extended-regexp  --regexp='openvpn' --regexp='colord' /etc/passwd /etc/group /usr/lib/passwd /usr/lib/group 

/etc/group:openvpn:x:979:
/etc/group:nm-openvpn:x:978:
/etc/group:colord:x:977:
/usr/lib/passwd:openvpn:x:983:979:OpenVPN:/etc/openvpn:/sbin/nologin
/usr/lib/passwd:nm-openvpn:x:982:978:Default user for running openvpn spawned by NetworkManager:/:/sbin/nologin
/usr/lib/passwd:colord:x:981:977:User for colord:/var/lib/colord:/sbin/nologin
/usr/lib/group:openvpn:x:979:
/usr/lib/group:nm-openvpn:x:978:
/usr/lib/group:colord:x:977:

OCI Silverblue 40 image:

 hricky@silverblue  >_ sudo rpm-ostree status 

State: idle
Deployments:
● ostree-image-signed:registry:quay.io/operatement/fedora-silverblue:40
                   Digest: sha256:754672b4e0dfc8279c0ffd67075aa40f716b7adc848cdcc0b849c165ad15ff5c
                  Version: 40.20240820.0 (2024-08-20T07:26:56Z)
                   Pinned: yes
...

 hricky@silverblue  >_ grep --extended-regexp  --regexp='openvpn' --regexp='colord' /etc/passwd /etc/group /usr/lib/passwd /usr/lib/group

/etc/group:openvpn:x:979:
/etc/group:nm-openvpn:x:978:
/etc/group:colord:x:977:
/usr/lib/passwd:colord:x:983:979:User for colord:/var/lib/colord:/sbin/nologin
/usr/lib/passwd:openvpn:x:982:978:OpenVPN:/etc/openvpn:/sbin/nologin
/usr/lib/passwd:nm-openvpn:x:981:977:Default user for running openvpn spawned by NetworkManager:/:/sbin/nologin
/usr/lib/group:colord:x:979:
/usr/lib/group:openvpn:x:978:
/usr/lib/group:nm-openvpn:x:977:

The OCI Silverblue Rawhide image has the same values (numbers) as the classic (non-OCI) Silverblue 40 image:

 hricky@silverblue  >_ sudo rpm-ostree status 

Job for rpm-ostreed.service failed because a fatal signal was delivered causing the control process to dump core.
See "systemctl status rpm-ostreed.service" and "journalctl -xeu rpm-ostreed.service" for details.
× rpm-ostreed.service - rpm-ostree System Management Daemon
     Loaded: loaded (/usr/lib/systemd/system/rpm-ostreed.service; static)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: failed (Result: core-dump) since Tue 2024-08-20 11:32:39 EEST; 7ms ago
...

 ~  1   
 hricky@silverblue  >_ cat /etc/os-release 

NAME="Fedora Linux"
VERSION="42 (Silverblue Prerelease)"
ID=fedora
VERSION_ID=42
VERSION_CODENAME=""
PLATFORM_ID="platform:f42"
PRETTY_NAME="Fedora Linux 42 (Silverblue Prerelease)"
...
REDHAT_BUGZILLA_PRODUCT_VERSION=rawhide
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=rawhide
SUPPORT_END=2025-05-13
VARIANT="Silverblue"
VARIANT_ID=silverblue
OSTREE_VERSION='41.20240820.0'

 ~  0   
 hricky@silverblue  >_ grep --extended-regexp  --regexp='openvpn' --regexp='colord' /etc/passwd /etc/group /usr/lib/passwd /usr/lib/group

/etc/group:openvpn:x:979:
/etc/group:nm-openvpn:x:978:
/etc/group:colord:x:977:
/usr/lib/passwd:openvpn:x:983:979:OpenVPN:/etc/openvpn:/sbin/nologin
/usr/lib/passwd:nm-openvpn:x:982:978:Default user for running openvpn spawned by NetworkManager:/:/sbin/nologin
/usr/lib/passwd:colord:x:981:977:User for colord:/var/lib/colord:/sbin/nologin
/usr/lib/group:openvpn:x:979:
/usr/lib/group:nm-openvpn:x:978:
/usr/lib/group:colord:x:977:
karuboniru commented 2 weeks ago

авг 03 10:00:09 silverblue (colord)[11456]: colord.service: Failed to set up special execution directory in /var/lib: Permission denied

Try restarting colord.service with setenforce 0?

I am having simliar issue with this AVC log: type=AVC msg=audit(1724821545.529:524): avc: denied { setattr } for pid=5053 comm="(colord)" name="mapping.db" dev="nvme0n1p3" ino=8500830 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:colord_var_lib_t:s0 tclass=file permissive=0, which seems to be a SELinux issue