incorrect cpu/graphics/disks information on raspi

Bug #1964601 reported by Dave Jones
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
gnome-control-center (Ubuntu)
Triaged
Low
Unassigned

Bug Description

At least according to gnome-control-center anyway.

Running the Ubuntu Desktop for Raspberry Pi image on a Pi 400 (or a Pi 4B), selecting Settings, then the "About" page shows that gnome-control-center thinks the processor is "", the graphics are "unknown", and apparently so is the disk capacity!

I admit it's a trivial thing, but it's been this way since at least hirsute, and it'd be nice to see something vaguely sane in there at some point :)

Revision history for this message
Dave Jones (waveform) wrote :
Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for your bug report.

The CPU missing has been reported upstream on https://gitlab.gnome.org/GNOME/libgtop/-/issues/60

Could you provide the content of /proc/cpuinfo on the raspi?

And what is the output of
$ glxinfo | grep 'OpenGL renderer string'

And could you add the log generated by
$ udiskctl dump > udisk.log

Changed in gnome-control-center (Ubuntu):
status: New → Incomplete
Revision history for this message
Dave Jones (waveform) wrote :

I'm attaching the full outputs as a tarball (just in case they're useful) but here's the pertinent bits too:

$ tail -n 13 /proc/cpuinfo
processor : 3
BogoMIPS : 108.00
Features : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd08
CPU revision : 3

Hardware : BCM2835
Revision : c03131
Serial : 10000000acbea889
Model : Raspberry Pi 400 Rev 1.1

It looks like "Model" would be the most appropriate field to report here. Looking at the upstream bug it's querying a "Model name" field (which appears per-CPU on my PC) but not a "Model" field in the final section (though on my PC there is no final section, just the per-CPU sections).

On glxinfo:

$ glxinfo | grep 'OpenGL renderer'
OpenGL renderer string: V3D 4.2

I'm attaching two cases of the udisksctl output. The first (udisk_sd.log) is from a "typical" installation of Ubuntu Desktop for Pi on an SD card. The second (udisk_usb.log) is from the same Pi booting from a USB-attached SSD (which is a fairly common configuration for booting the desktop).

Should I post these bits upstream too?

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks for the details.

I've added the cpuinfo to the libgtop report. It does somehow sound like a kernel issue though that the cpu details are not provided.

I can try to upstream the other problems, it seems they are each worth a report on gnome-control-center, but if you want to do it directly please do

Changed in gnome-control-center (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Sebastien Bacher (seb128) wrote :

On the disk issue, there are some related discussion on https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/633

but basically gnome-control-center currently ignore removable devices because it shouldn't account for a connected usb stick or sdcard as system capacity

one suggested heuristic tweak that could fix the raspi case is 'Use the size of the disk with a partition mounted at / only if there are no non-removable devices.'

Revision history for this message
Sebastien Bacher (seb128) wrote :

What's the output of /usr/libexec/gnome-control-center-print-renderer on the raspi?
and
$ G_MESSAGES_DEBUG=all gnome-control-center info-overview

Revision history for this message
Dave Jones (waveform) wrote :
Download full text (5.0 KiB)

gnome-control-center-printer-renderer produces no output on the raspi. The debug output from gnome-control-center is:

(gnome-control-center:3171): GLib-GIO-DEBUG: 14:47:50.015: _g_io_module_get_default: Found default implementation dconf (DConfSettingsBackend) for ‘gsettings-backend’
(gnome-control-center:3171): dconf-DEBUG: 14:47:50.015: watch_fast: "/org/gnome/desktop/interface/" (establishing: 0, active: 0)
(gnome-control-center:3171): dconf-DEBUG: 14:47:50.016: watch_fast: "/org/gnome/desktop/peripherals/mouse/" (establishing: 0, active: 0)
(gnome-control-center:3171): dconf-DEBUG: 14:47:50.016: watch_fast: "/org/gnome/desktop/sound/" (establishing: 0, active: 0)
(gnome-control-center:3171): dconf-DEBUG: 14:47:50.016: watch_fast: "/org/gnome/desktop/privacy/" (establishing: 0, active: 0)
(gnome-control-center:3171): dconf-DEBUG: 14:47:50.016: watch_fast: "/org/gnome/desktop/wm/preferences/" (establishing: 0, active: 0)
(gnome-control-center:3171): dconf-DEBUG: 14:47:50.017: watch_fast: "/org/gnome/settings-daemon/plugins/xsettings/" (establishing: 0, active: 0)
(gnome-control-center:3171): dconf-DEBUG: 14:47:50.017: watch_fast: "/org/gnome/desktop/a11y/" (establishing: 0, active: 0)
(gnome-control-center:3171): dconf-DEBUG: 14:47:50.017: watch_fast: "/org/gnome/desktop/a11y/interface/" (establishing: 0, active: 0)
(gnome-control-center:3171): dconf-DEBUG: 14:47:50.019: watch_established: "/org/gnome/desktop/interface/" (establishing: 1)
(gnome-control-center:3171): dconf-DEBUG: 14:47:50.019: watch_established: "/org/gnome/desktop/peripherals/mouse/" (establishing: 1)
(gnome-control-center:3171): dconf-DEBUG: 14:47:50.019: watch_established: "/org/gnome/desktop/sound/" (establishing: 1)
(gnome-control-center:3171): dconf-DEBUG: 14:47:50.020: watch_established: "/org/gnome/desktop/privacy/" (establishing: 1)
(gnome-control-center:3171): dconf-DEBUG: 14:47:50.020: watch_established: "/org/gnome/desktop/wm/preferences/" (establishing: 1)
(gnome-control-center:3171): dconf-DEBUG: 14:47:50.020: watch_established: "/org/gnome/settings-daemon/plugins/xsettings/" (establishing: 1)
(gnome-control-center:3171): dconf-DEBUG: 14:47:50.020: watch_established: "/org/gnome/desktop/a11y/" (establishing: 1)
(gnome-control-center:3171): dconf-DEBUG: 14:47:50.020: watch_established: "/org/gnome/desktop/a11y/interface/" (establishing: 1)
(gnome-control-center:3171): GLib-DEBUG: 14:47:50.141: unsetenv() is not thread-safe and should not be used after threads are created
(gnome-control-center:3171): GLib-GIO-DEBUG: 14:47:50.162: _g_io_module_get_default: Found default implementation gvfs (GDaemonVfs) for ‘gio-vfs’
(gnome-control-center:3171): cc-object-storage-DEBUG: 14:47:51.608: Initializing object storage
(gnome-control-center:3171): GLib-DEBUG: 14:47:51.611: unsetenv() is not thread-safe and should not be used after threads are created
(gnome-control-center:3171): Gtk-DEBUG: 14:47:51.612: Connecting to session manager
(gnome-control-center:3171): dconf-DEBUG: 14:47:51.714: watch_fast: "/org/gnome/control-center/" (establishing: 0, active: 0)
(gnome-control-center:3171): dconf-DEBUG: 14:47:52.664: watch_established: "/org/gnome/control-center/" (establishin...

Read more...

Revision history for this message
Sebastien Bacher (seb128) wrote :

> gnome-control-center-printer-renderer produces no output on the raspi.

the code basically does

        context = gdk_window_create_gl_context (gtk_widget_get_window (win), NULL);
        if (!context)
                return NULL;
        gdk_gl_context_make_current (context);
        renderer = g_strdup ((char *) glGetString (GL_RENDERER));

so either the gl context is failing or glGetString isn't returning a value

Revision history for this message
Sebastien Bacher (seb128) wrote :

Is the renderer result different if MESA_GL_VERSION_OVERRIDE=3.3 is exported? It could be similar to https://gitlab.gnome.org/GNOME/gtk/-/issues/2619

Revision history for this message
Dave Jones (waveform) wrote :

I've done a bit of debugging on this; wound up tweaking the code mentioned in comment 8 above to return g_strdup("NULL context") instead of return NULL and with this in place, gnome-control-center-print-renderer (and indeed the "Graphics" field of the control center) both return "NULL context" so at least we know that's what's going on.

I also hacked up an openGL demo to print the result of glGetString(GL_RENDERER) and apparently we should be getting "V3D 4.2" when everything's working correctly. Unfortunately I've no idea why gdk_window_create_gl_context isn't working on the pi desktop.

Revision history for this message
Dave Jones (waveform) wrote :

Sorry, hadn't refreshed this page and didn't notice your comment 9 before posting mine! With the override in place it looks like things work properly:

$ MESA_GL_VERSION_OVERRIDE=3.3 /usr/libexec/gnome-control-center-print-renderer
V3D 4.2

And looking at the upstream ticket you linked makes a lot of sense: the Pi's GL driver only goes up to 2.1:

$ glxinfo | grep "GL version string"
OpenGL version string: 2.1 Mesa 22.0.1

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks, that explain, and I think we have an understanding of each of the disks/graphics/cpu causes now!

Changed in gnome-control-center (Ubuntu):
status: Confirmed → Triaged
summary: - I have no processor!
+ incorrect cpu/graphics/disks information on raspi
Revision history for this message
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1964601

tags: added: iso-testing
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.