[Arm-dev] Observations regarding armhfp images

Mark Verlinde mark at havak.nl
Tue Dec 11 17:00:15 UTC 2018


Hi list,

Utilizing the appliance tools to create (custom)  images for a while and going through this process again with the 7.6 release,;
I’d like to share some observations / topics and (if applicable) workarounds for them with you. 

Being aware it is not considered good practice to address multiple topics in one post, opted to do this as you see in an attempt not to spam this list to much. 
If someone wants to discuss one specific topic I suggest to reply with an altered subject to split this of in a separate thread.

Note all references to an image are always to the minimal image without a DE

__  CPU-governor defaults to powersave on RaspberryPI  image __
# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
powersave

In practice this means our RPI's permanently clock on the minimal cpu frequency 
In absence of user-space tools opted to create a (system) service unit which echoes _ondemand_ in the scaling governor of each cpu:

# cat /etc/systemd/system/multi-user.target.wants/cpu_governor.service
[Unit]
Description=Set cpu governor to ondemand

[Service]
Type=oneshot
ExecStart=/bin/sh -c " for i in {0..3}; do echo ondemand > sys/devices/system/cpu/cpu$i/cpufreq/scaling_governor; done"

[Install]
WantedBy=multi-user.target

__ kdump service fails on RPI and Generic image __
RPI image (with raspberrypi2 kernel) :

# journalctl | grep kdump
.… kdumpctl[1569]: Kdump is not supported on this kernel …
. kdumpctl[1569]: Starting kdump: [FAILED]

Generic image (with generic kernel):
 
# journalctl | grep kdump …
. kdumpctl[3764]: No memory reserved for crash kernel …
. kdumpctl[3764]: Starting kdump: [FAILED]

Workaround in place is simply mask the kdump.service (systemctl mask kdump.service)

__(unneeded?) creation of legacy _uImage_ and _uInitrd_ by grubby on Generic image __
In an attempt to reduce the size of the shipped image and (ultimately) the boot partition I had a look at the content of /boot. 
AFIAK the  _uImage_ and _uInitrd_ are not used by syslinux (extlinux) boot method and can safely, with their (versioned) copies,  be removed. 

# df -h | grep /boot
/dev/mmcblk0p2  641M  166M  469M  27% /boot
/dev/mmcblk0p1   29M   13M   17M  45% /boot/fw
# rm -f uI*
# df -h | grep /boot
/dev/mmcblk0p2  641M   71M  564M  12% /boot
/dev/mmcblk0p1   29M   13M   17M  45% /boot/fw

To make this behavior persistent grubby would need a quite comprehensive patch containing  more or less the commit linked below:
https://src.fedoraproject.org/cgit/rpms/grubby.git/diff/drop-uboot-uImage-creation.patch?id=c5aefcde03e38b76506c26bf8a262fc303c0d928
also see:
https://src.fedoraproject.org/cgit/rpms/grubby.git/commit/?id=c5aefcde03e38b76506c26bf8a262fc303c0d928

__ Kernel dependency on kernel-headers __
This seems to be caused by the xorg-x11-drv-vmmouse dependency of the kernel provided by kernel-headers. 

# rpm -q --requires kernel
kernel-core-uname-r = 4.14.82-201.el7.armv7hl
kernel-modules-uname-r = 4.14.82-201.el7.armv7hl
xorg-x11-drv-vmmouse >= 14.0.0 …
.
# rpm -q --whatprovides xorg-x11-drv-vmmouse
kernel-headers-4.14.82-201.el7.armv7hl

Why the  (vmware?) mouse driver is so essential on arm beats me.  

Grtz Mark


More information about the Arm-dev mailing list