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.