cockpit
cockpit copied to clipboard
cockpit-project
cockpit hardware information is wrong on a Raspberry Pi 3
Explain what happens
On my RPI 3 cockpit does not show the model
Device tree has the correct information:
[jelle@fedora ~]$ sudo cat /proc/device-tree/model
Raspberry Pi 3 Model B Rev 1.2
[jelle@fedora ~]$ cat /proc/device-tree/serial-number
00000000895f62e7
dmidecode
Getting SMBIOS data from sysfs.
SMBIOS 3.0 present.
7 structures occupying 265 bytes.
Table at 0x3CB3F020.
Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
Vendor: U-Boot
Version: 2021.10
Release Date: 10/01/2021
ROM Size: 64 kB
Characteristics:
PCI is supported
BIOS is upgradeable
Selectable boot is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 21.10
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: Unknown
Product Name: Unknown Product
Version: Not Specified
Serial Number: 00000000895f62e7
UUID: 30303030-3030-3030-3839-356636326537
Wake-up Type: Reserved
SKU Number: Not Specified
Family: Not Specified
Handle 0x0002, DMI type 2, 14 bytes
Base Board Information
Manufacturer: Unknown
Product Name: Unknown Product
Version: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Features:
Board is a hosting board
Location In Chassis: Not Specified
Chassis Handle: 0x0000
Type: Motherboard
Handle 0x0003, DMI type 3, 21 bytes
Chassis Information
Manufacturer: Unknown
Type: Desktop
Lock: Not Present
Version: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Boot-up State: Safe
Power Supply State: Safe
Thermal State: Safe
Security Status: None
OEM Information: 0x00000000
Height: Unspecified
Number Of Power Cords: Unspecified
Contained Elements: 0
Handle 0x0004, DMI type 4, 48 bytes
Processor Information
Socket Designation: Not Specified
Type: Central Processor
Family: Unknown
Manufacturer: Unknown
ID: 00 00 00 00 00 00 00 00
Version: Unknown
Voltage: Unknown
External Clock: Unknown
Max Speed: Unknown
Current Speed: Unknown
Status: Unpopulated
Upgrade: None
L1 Cache Handle: Not Provided
L2 Cache Handle: Not Provided
L3 Cache Handle: Not Provided
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Characteristics: None
Handle 0x0005, DMI type 32, 11 bytes
System Boot Information
Status: No errors detected
Handle 0x0006, DMI type 127, 4 bytes
End Of Table
Version of Cockpit
262
Where is the problem in Cockpit?
Overview
Server operating system
Fedora
Server operating system version
35
What browsers are you using?
No response
System log
No response
Mine Pi 4 running Fedora IoT is even more sparse...
$ sudo cat /proc/device-tree/model Raspberry Pi 4 Model B Rev 1.1⏎
Here's my dmidecode:
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 3.0 present.
7 structures occupying 209 bytes.
Table at 0x3CB28020.
Wrong DMI structures length: 209 bytes announced, only 128 bytes available.
Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
Vendor: U-Boot
Version: 2021.04
Release Date: 04/28/2021
ROM Size: 64 kB
Characteristics:
PCI is supported
BIOS is upgradeable
Selectable boot is supported
I2O boot is supported
Targeted content distribution is supported
BIOS Revision: 21.4
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: Not Specified
Product Name: Not Specified
Version: Not Specified
Serial Number: 100000002c5d55ea
UUID: 30303031-3030-3030-3263-356435356561
Wake-up Type: Reserved
SKU Number: Not Specified
Family: Not Specified
Handle 0x0002, DMI type 2, 14 bytes
Base Board Information
Manufacturer: Not Specified
Product Name: Not Specified
Version: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Features:
Board is a hosting board
Location In Chassis: Not Specified
Chassis Handle: 0x0000
Type: Motherboard
Invalid entry length (0). DMI table is broken! Stop.
I'm not sure why it's broken. Weird, right?
So the issue for me is that dmidecode ie. machine_info.dmi_info() returns fields for my RPI and we don't reach the catch(). As Fedora Server/IoT use uboot with a EFI payload to boot grub the faulty information likely comes from there as the BIOS, version and date are shown as uboot with their respective release date. Most likely it comes from their smbios implementation which does not populate the board_vendor and other fields from device tree such as product_name.
For the CPU model name, cat /proc/cpuinfo does not have a model name on ARM so that's why we shown "undefined". But lscpu shows: Model name: Cortex-A53. lscpu which uses a whole lookup table for parsing what I think is /proc/cpuinfo on ARM. @martinpitt I don't think we want to add a dependency on lscpu (util-linux right?)
processor : 1
BogoMIPS : 38.40
Features : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
processor : 2
BogoMIPS : 38.40
Features : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
processor : 3
BogoMIPS : 38.40
Features : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
Unrelated vulnerabilities are not shown
Vulnerabilities:
Itlb multihit: Not affected
L1tf: Not affected
Mds: Not affected
Meltdown: Not affected
Spec store bypass: Not affected
Spectre v1: Mitigation; __user pointer sanitization
Spectre v2: Not affected
Srbds: Not affected
Tsx async abort: Not affected
hostnamed dbus API now has chassis/hardware vendor but lacks product_serial/chassis_serial so if we can get that added it would be beneficial.
Please don't override DMI information because of U-Boot, that is a terrible hack for bugs in U-Boot firmware implementations and it'll just become a game of whack-a-mole. Upstream U-Boot is working to improve this as part of the EBBR spec.
Just cross compiled u-boot from git ( f6973cce6af066d28980c9f82c99cb4e10af8a6f ) today on Arch Linux with:
make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- rpi_3_defconfig
make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu-
And then replaced rpi3-u-boot.bin on the FAT partition (efi dir) this led to a successful boot and the following information in cockpit:
cd /sys/class/dmi/id
[admin@fedora id]$ cat board_name
rpi
[admin@fedora id]$ cat board_vendor
raspberrypi
On Fedora IOT the u-boot version is 2022.05 which still shows unknown everywhere, so I'll check if this was recently fixed.
System information is overall odd on a Pi 4 with IoT 36.20220511.0.
It's using uboot-images-armv8-2022.04-1.fc36.noarch FWIW.
I just did an rpm-ostree update and don't see any new release for uboot-images.
Tested on Raspberry Pi 4 and pre-release Fedora 37 and I'm having the same issue.
cockpit-274.1-1.fc37.aarch64 uboot-images-armv8-2022.10-0.1.rc1.fc37.noarch bcm283x-overlays-20220809-1.915a708.fc37.aarch64 bcm2835-firmware-20220809-1.915a708.fc37.aarch64 bcm283x-firmware-20220809-1.915a708.fc37.aarch64 bcm2711-firmware-20220809-1.915a708.fc37.aarch64
Tested on Raspberry Pi 4 and pre-release Fedora 37 and I'm having the same issue.
Reporting "me too" here isn't helpful, I'm working to have it fixed upstream in a generic way for all devices that boot with U-Boot as a firmware. Once that is complete I will report back here and the ticket can just be closed. In fact given this has NOTHING to do with cockpit I would actually just close this bug.
The actual issue is the device isn't reporting SMBIOS tables for dmidecode to read. You can see the same information by just running dmidecode. This is nothing unusual, you see if with cheap Intel based devices with terrible firmware too.
I'm working to have it fixed upstream in a generic way for all devices that boot with U-Boot as a firmware. Once that is complete I will report back here and the ticket can just be closed.
Awesome! Thanks!
As a side effect of not-so-great data, Cockpit's layout is a bit odd, as seen above @ https://github.com/cockpit-project/cockpit/issues/16972#issuecomment-1127834452. I should fix that. It's related to this.
Reporting "me too" here isn't helpful
Yes, it was a "me too" comment but not wholly. The title of this issue says RPi3, and I wanted to give more information about other situations, including RPi4. I also shared the distro version, tested with a not-released-yet version, and provided all the package versions (since they differed from other versions mentioned).
Thanks for doing the work upstream to get this fixed, much appreciated.
Sure, this is something which should end up being fixed in u-boot. I haven't tested this in a while so let's close it and if someone complains we can investigate.