Notes on Using ROOTFS_POSTPROCESS_COMMAND in Yocto

December 23, 2022: Some lessons learned in removing unwanted files

If you are using yocto, you might want to add/remove some files after you have built all other packages.
Here is how you can do that.

For one of my clients, I wanted to disable the sytemd-resolved service, as it opens some ports on the system and thus was deemed a security risk. The port it opens shows up like this in a nmap scan:

simon:~$ sudo nmap -sS 172.30.2.39 -p 1-9000
Starting Nmap 7.80 ( https://nmap.org ) at 2022-12-23 16:24 CET
Nmap scan report for 172.30.2.39
Host is up (0.0014s latency).
Not shown: 8998 closed ports
PORT     STATE SERVICE
5355/tcp open  llmnr

Nmap done: 1 IP address (1 host up) scanned in 0.74 seconds

I searched online and found that you should be able to delete the created systemd symlink in a ROOTFS_POSTPROCESS_COMMAND call. The systemd symlink I wanted to delete was the sytemd-resolved.service file which autostarts the service on the system, once booted up.

I thus added following lines to my image script, under recipes-images/images/my-image.bb.

disable_systemd_recipe() {
 rm -rf ${IMAGE_ROOTFS}/etc/systemd/system/multi-user.target.wants/systemd-resolved.service
}
ROOTFS_POSTPROCESS_COMMAND =+ "disable_systemd_recipe; "

These are some things I learned in this approach:

Use bitbake -e your-image to look at what code is generated and verify everything is there:
- ROOTFS_POSTPROCESS_COMMAND should now have your special function included
- your special function should appear somewhere else in the code
Using rm directly did not work, I had to define a separate function for the function to be picked up
You can not use a minus/hyphen in the name of the function
- My first function was named disable_sytemd-resolved, which bitbake did not complain about, but the function was not included in the bitbake -e output
You have to include the snippet in a recipe inheriting from an image recipe, you can’t use a “normal”/software recipe

However after I did this, the symlink I wanted to remove was still present.
This perplexed me for a while and I dug in to the problem.

Stackoverflow helped me to get on track to find the solution to this mystery: This post from user DJM told me to change 90-systemd.preset via a systemd_%.bbappend file:

do_configure_append() {
#disabling autostart of systemd-resolved
sed -i -e "s/enable systemd-resolved.service/disable systemd-resolved.service/g" ${S}/presets/90-systemd.preset
}

This actually worked and I could have stopped here, however I was intrigued why the previous ROOTFS_POSTPROCESS_COMMAND did not remove the symlink and decided to investigate.

The 90-systemd.preset file is created from poky/meta/recipes-core/systemd/systemd-systemctl/systemctl in the preset_all/Preset function. poky/meta/classes/image.bbclass calls systemd_preset_all in its IMAGE_PREPROCESS_COMMAND_append.
The IMAGE_PREPROCESS command is executed after ROOTFS_POSTPROCESS, so the symlink was only created after I tried to remove it.

So if we move our disable_sytemd_recipe function in to IMAGE_PREPROCESS_COMMAND_append this succeeds.
We can’t move it in to IMAGE_POSTPROCESS_COMMAND_append, as the image process command is supposed to generate the final image file and we are not supposed to tamper with the image files, once they are processed: the function does pass successfully, but the symlink is still there.

So you have two options to remove an unwanted systemd service:

Remove via sed in a systemd_%.bbappend file
Remove via IMAGE_PREPROCESS_COMMAND_append function in a image recipe

I chose to go with the bbappend file, as this appeared cleaner to me. Using this approach I successfully removed the unwanted systemd function from my custom yocto image and closed the port that this process opens.