Hide Forgot
The cpu-partitioning profile needs tuning parameters to be set at initrd time. Bugs bug 1394965 and bug 1395899 are examples of this. To make this possible, tuned could implement a initrd module that allows profiles to add to initrd: 1. Custom configuration files 2. Scripts to be executed during initrd time The Linux kernel and grub support the loading of multiple initrd images: when multiple initrd images are specified, they are unpacked on top of each other. This allows for tuned to create a very small initrd image containing only the additional files needed by the profile. The script bellow is an example of this solution and was used to fix the two BZs mentioned above. It creates an initrd image called tuned-initrd.img containing the system.conf file and a dracut script to be run before udev: ===== #!/bin/bash initrd=/boot/tuned-initrd.img systemd_path=etc/systemd hook_path=usr/lib/dracut/hooks/pre-udev tmpdir=$(mktemp -d) echo $tmpdir cd $tmpdir mkdir -p $systemd_path mkdir -p $hook_path cp /etc/systemd/system.conf $systemd_path cp /root/tmp/00-tuned-pre-udev.sh $hook_path find . | cpio -H newc -o > $initrd === Here's the image contents after creation: [root@rhel73-test boot]# lsinitrd tuned-initrd.img Image: tuned-initrd.img: 4.0K ======================================================================== Version: Arguments: dracut modules: ======================================================================== drwx------ 4 root root 0 Jan 17 12:58 . drwxr-xr-x 3 root root 0 Jan 17 12:58 etc drwxr-xr-x 2 root root 0 Jan 17 12:58 etc/systemd -rw-r--r-- 1 root root 1488 Jan 17 12:58 etc/systemd/system.conf drwxr-xr-x 3 root root 0 Jan 17 12:58 usr drwxr-xr-x 3 root root 0 Jan 17 12:58 usr/lib drwxr-xr-x 3 root root 0 Jan 17 12:58 usr/lib/dracut drwxr-xr-x 3 root root 0 Jan 17 12:58 usr/lib/dracut/hooks drwxr-xr-x 2 root root 0 Jan 17 12:58 usr/lib/dracut/hooks/pre-udev -rw-r--r-- 1 root root 263 Jan 17 12:58 usr/lib/dracut/hooks/pre-udev/00-tuned-pre-udev.sh ======================================================================== [root@rhel73-test boot]# After the image is created, the following line has to be *appended* to each initrd16 line in grub.cfg: /tuned-initrd.img Here's an example of the full initrd16 line: initrd16 /initramfs-3.10.0-542.el7.x86_64.img /tuned-initrd.img When the profile is disabled, all tuned has to do is to delete the tuned-initrd.img image and update the initrd16 line in grub.cfg.
Created attachment 1257964 [details] Initial patch It will also require grub2 patch to support grub2-mkconfig.
Cool. Do you have an example on how this can be used from profiles? And does RHEL7.4 has the needed grub2 patch?
(In reply to Luiz Capitulino from comment #4) > Cool. Do you have an example on how this can be used from profiles? And does > RHEL7.4 has the needed grub2 patch? Regarding the grub I filled bug 1427899. I think at the moment it's not show stopper for us, just a minor annoyance. I.e. it should now patch grub.cfg correctly, but if user later runs e.g.: # grub2-mkconfig -o /boot/grub2/grub.cfg it will lost the initrd tuning. The bug 1427899 tries to address this problem. Proposed Tuned patch counts with this RFE and if the grub2 RFE patch gets merged it should start working automagically. Also I didn't introduced new initrd module, but just extended the bootloader module which turned out to be better way. I will post usage examples later today.
OK, changing the BZ subject to reflect that.
This is upstream commit adding the functionality: https://github.com/redhat-performance/tuned/commit/047a7335b02c15d2fa4f347e9c1627a79e3a86a8 I am running regression tests now, but feel free to test, I am going to provide testing Tuned builds today. How to use it: The bootloader plugin now supports the following options: initrd_add_img=IMAGE initrd_add_dir=DIR initrd_dst_img=PATHNAME The 'initrd_add_img' adds initrd overlay named IMAGE. The IMAGE is added from the current profile directory. If IMAGE begins with '/' it's taken as absolute path (e.g. initrd_add_img="/root/overlay.img"). The 'initrd_add_dir' creates initrd image from the DIR and then adds the image as a overlay. The DIR is taken from the current profile directory. If DIR begins with '/' it's taken as absolute path. The 'initrd_dst_img' sets the name and location of the resulting initrd image. Usually it is not needed to set it. By default the location of initrd images is /boot and the name of the image is taken as a basename of IMAGE or DIR. This can be overridden by 'initrd_dst_img'. If the PATHNAME doesn't begin with '/' it will set only the image name, not the full path (i.e. it will still use the /boot as a target directory). Example: # cd tuned-profile # mkdir -p tuned-overlay.img/etc # cd tuned-overlay.img/etc # touch test.conf Tuned profile: [bootloader] initrd_add_dir=tuned-overlay.img It will build the initrd image containing the overlay and will add it to the grub. Regarding /etc/systemd/system.conf and the second related problem I am going to comment in respective bugs.
Functionality should be provided by following (nightly) build: tuned-2.7.1-1.20170301git1ba523b1.el7 available from the testing repo: https://jskarvad.fedorapeople.org/tuned/devel/repo/
This is working like a charm for me. Thanks a lot!
Sorry, I mistook bug and comments #11 and #12 are invalid.
Seems no info is needed from me, cancel the needinfo.
Ahoj Jardo, I see some problem according mentioned behavior from comment #7: GOOD BEHAVIOR: ============== # cat /usr/lib/tuned/tuned-profile/tuned.conf [bootloader] initrd_add_dir=/usr/lib/tuned/tuned-profile/tuned-overlay.img # tuned-adm profile tuned-profile # cat /var/log/tuned/tuned.log ... 2017-05-15 04:48:12,004 INFO tuned.profiles.loader: loading profile: tuned-profile 2017-05-15 04:48:12,004 INFO tuned.daemon.daemon: starting tuning 2017-05-15 04:48:12,007 INFO tuned.plugins.plugin_bootloader: generating initrd image from directory '/usr/lib/tuned/tuned-profile/tuned-overlay.img' 2017-05-15 04:48:12,014 INFO tuned.plugins.plugin_bootloader: installing initrd image as '/boot/tuned-overlay.img' 2017-05-15 04:48:12,027 INFO tuned.daemon.daemon: static tuning from profile 'tuned-profile' applied >> There is used absolute path to initrd image in tuned.conf and work as expected. BAD BEHAVIOR: ============= # cat /usr/lib/tuned/tuned-profile/tuned.conf [bootloader] initrd_add_dir=tuned-overlay.img # tuned-adm profile tuned-profile # cat /var/log/tuned/tuned.log ... 2017-05-15 04:54:26,579 INFO tuned.profiles.loader: loading profile: tuned-profile 2017-05-15 04:54:26,580 INFO tuned.daemon.daemon: starting tuning 2017-05-15 04:54:26,581 ERROR tuned.plugins.plugin_bootloader: error: cannot create initrd image, source directory 'tuned-overlay.img' doesn't exist 2017-05-15 04:54:26,581 INFO tuned.daemon.daemon: static tuning from profile 'tuned-profile' applied >> There is not used aboslute path to initrd image in tuned.conf and I see ERROR which should not be there. More info: ========== # find /usr/lib/tuned/tuned-profile /usr/lib/tuned/tuned-profile /usr/lib/tuned/tuned-profile/tuned-overlay.img /usr/lib/tuned/tuned-profile/tuned-overlay.img/etc /usr/lib/tuned/tuned-profile/tuned-overlay.img/etc/test.conf /usr/lib/tuned/tuned-profile/tuned.conf
(In reply to Tereza Cerna from comment #15) > Ahoj Jardo, > I see some problem according mentioned behavior from comment #7: > > GOOD BEHAVIOR: > ============== > # cat /usr/lib/tuned/tuned-profile/tuned.conf > [bootloader] > initrd_add_dir=/usr/lib/tuned/tuned-profile/tuned-overlay.img > # tuned-adm profile tuned-profile > # cat /var/log/tuned/tuned.log > ... > 2017-05-15 04:48:12,004 INFO tuned.profiles.loader: loading profile: > tuned-profile > 2017-05-15 04:48:12,004 INFO tuned.daemon.daemon: starting tuning > 2017-05-15 04:48:12,007 INFO tuned.plugins.plugin_bootloader: generating > initrd image from directory '/usr/lib/tuned/tuned-profile/tuned-overlay.img' > 2017-05-15 04:48:12,014 INFO tuned.plugins.plugin_bootloader: installing > initrd image as '/boot/tuned-overlay.img' > 2017-05-15 04:48:12,027 INFO tuned.daemon.daemon: static tuning from > profile 'tuned-profile' applied > > >> There is used absolute path to initrd image in tuned.conf and work as expected. > > BAD BEHAVIOR: > ============= > # cat /usr/lib/tuned/tuned-profile/tuned.conf > [bootloader] > initrd_add_dir=tuned-overlay.img > # tuned-adm profile tuned-profile > # cat /var/log/tuned/tuned.log > ... > 2017-05-15 04:54:26,579 INFO tuned.profiles.loader: loading profile: > tuned-profile > 2017-05-15 04:54:26,580 INFO tuned.daemon.daemon: starting tuning > 2017-05-15 04:54:26,581 ERROR tuned.plugins.plugin_bootloader: error: > cannot create initrd image, source directory 'tuned-overlay.img' doesn't > exist > 2017-05-15 04:54:26,581 INFO tuned.daemon.daemon: static tuning from > profile 'tuned-profile' applied > > >> There is not used aboslute path to initrd image in tuned.conf and I see ERROR which should not be there. > > More info: > ========== > # find /usr/lib/tuned/tuned-profile > /usr/lib/tuned/tuned-profile > /usr/lib/tuned/tuned-profile/tuned-overlay.img > /usr/lib/tuned/tuned-profile/tuned-overlay.img/etc > /usr/lib/tuned/tuned-profile/tuned-overlay.img/etc/test.conf > /usr/lib/tuned/tuned-profile/tuned.conf Comment 7 is not up-to-date. We changed and consolidated the behaviour, you need to use the internal variable PROFILE_DIR, i.e.: initrd_add_dir=${i:PROFILE_DIR}/tuned-overlay.img It simplified the code and improved inheritance functionality. Also it's now clear from where the image is created.
Tested manually and with new test case /CoreOS/tuned/Regression/support-of-initrd-image-in-tuned-profiles. I tested this bootloader parameters: * initrd_add_img * initrd_add_dir * initrd_dst_img * initrd_remove_dir and basic functionality works well. -> VERIFIED I found some small problems which were not in specification. See BZ#1454340 and BZ#1455161.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:2102