[Arm-dev] Observations regarding armhfp images

Pablo Sebastián Greco

pablo at fliagreco.com.ar
Wed Dec 12 11:21:32 UTC 2018


El 11/12/18 a las 14:00, Mark Verlinde escribió:
> 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.
Thanks, I'll try to take a look at that and see if the patch applies.
>
> # 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.
This is more a conflict than a requires, and in fact, version 4.19 
already has that requirement dropped. Eventually I'll fix the same thing 
and drop the provides from kernel-headers
>
> Grtz Mark
> _______________________________________________
> Arm-dev mailing list
> Arm-dev at centos.org
> https://lists.centos.org/mailman/listinfo/arm-dev
Pablo.



More information about the Arm-dev mailing list