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