images.sh not being executed during CREATE phase - KIWI 10.2.33 with schema 8.0

[Matt Tolle]

Hi Folks, 

I'm having an issue with the images.sh script not being executed during the CREATE phase of an image build, and I'm hoping to get some guidance on what might be wrong with my setup.

* Environment:
- KIWI version: 10.2.33
- Schema version: 8.0
- Image type: oem disk image with LVM
- Build command: `kiwi-ng --profile=Cloud-GCE-LVM --profile=rocky system build ...`

* Issue:
I have an images.sh script in my image description directory alongside config.sh, but it doesn't appear to be executed during the CREATE phase. There are no log entries indicating it ran, and the modifications I expect it to make to /etc/fstab are not present in the final image.

*Directory structure:*
/path/to/image-description/
├── config.xml (schemaversion="8.0")
├── config.sh (executable, runs successfully during PREPARE)
├── images.sh (executable, does not run)
├── root/ (overlay directory)
└── cloud/ (additional XML configs)

* images.sh script:
 
#!/bin/bash
set -euxo pipefail

test -f /.kconfig && . /.kconfig
test -f /.profile && . /.profile

echo "Running images.sh for [$kiwi_iname]-[$kiwi_profiles]..."

# Modify /etc/fstab to add mount options
if [ -f /etc/fstab ]; then
  cp /etc/fstab /etc/fstab.pre-hardening
  sed -i '/[[:space:]]\/home[[:space:]]/ s/defaults/defaults,nodev,nosuid/' /etc/fstab
  echo "Modified fstab"
fi

echo "images.sh completed."

* Permissions:
-rwxr-x--- 1 root root 1687 Nov  5 23:27 images.sh

* Why I need images.sh:
The config.sh script runs during the PREPARE phase, but KIWI generates /etc/fstab during the transition from PREPARE to CREATE. I need to modify the fstab after it's been generated by KIWI, which is why I'm trying to use images.sh.

* Questions:
1. Does KIWI 10.x still automatically detect and execute images.sh from the image description directory?
2. Do I need to explicitly reference images.sh in config.xml for schema 8.0?
3. Are there specific requirements for images.sh that I might be missing?
4. Is there a better way to modify /etc/fstab after KIWI generates it during the build process?

* What I've verified:
- config.sh runs successfully and its changes are present in the image
- images.sh has execute permissions
- images.sh is in the same directory as config.sh
- No errors in KIWI build logs related to script execution

I've consulted the KIWI documentation which mentions images.sh should run during CREATE phase, but I can't find specific information about schema 8.0 requirements or version 10.x changes.

Any guidance would be greatly appreciated!

Thank you!

-Matt

[Marcus Schäfer]

Hi Matt,

> I have an images.sh script in my image description directory alongside
> config.sh, but it doesn't appear to be executed during the CREATE
> phase. There are no log entries indicating it ran

That sounds weird. At call time of any script there is a log
message produced like this:

[ 63s] [ INFO ]: 11:47:36 | Calling images.sh script

I can see that in one of the integration tests. Can you share
the kiwi log file ?

>, and the
> modifications I expect it to make to /etc/fstab are not present in the
> final image.

yes that is true because you cannot manage fstab content
via the scripts because this is one of the rare system setup
files that kiwi has to manage itself. As such for changing
fstab content we added an extra feature for users. Please
take a look here:

https://osinside.github.io/kiwi/working_with_images/custom_fstab_extension.html

> I've consulted the KIWI documentation which mentions images.sh should
> run during CREATE phase,

yes it runs at the beginning of the create stage. If you call
kiwi with "system build" this means prepare+create, if you call
kiwi with "system prepare" this means only prepare, if you call
kiwi with "system create" this means only create (from previous prepare)

As I said your log file would be helpful and maybe you are
just missing the fstab change which would be expected

Hope this helps

Regards,
Marcus
--
Public Key available via: https://keybase.io/marcus_schaefer/key.asc
keybase search marcus_schaefer

[Matt Tolle]

Thanks for the quick response.

I’ve attached the log file for your review. Please note that I’ve redacted the company name and IP addresses for confidentiality.

It appears that images.sh does not show up in the log:

$ grep -i image.sh /tmp/kiwi-rhel9-redacted.log
$

I’m currently using the two-step Kiwi process—running system prepare followed by system create. I’m wondering if this approach might be bypassing image.sh.

I'm not sure how I missed the Fstab documentation. That looks like what I need. I'll give that a try.

Thanks,

-Matt

[Marcus Schäfer]

Hi,

> I’ve attached the log file for your review. Please note that I’ve
> redacted the company name and IP addresses for confidentiality.

sure

> It appears that images.sh does not show up in the log:
> $ grep -i image.sh /tmp/kiwi-rhel9-redacted.log

yes here is my theory. All scripts that kiwi should call are copied
from the image description into the image root tree below the image/
directory. The final image does not contain this directory but
during build kiwi reads information from it. I did a short test with
prepare and create in single steps. After prepare was done you should
see data here:

sudo kiwi-ng system prepare --description ... --root /tmp/mytest/myroot

ls -l /tmp/mytest/myroot/image

-rw-r--r-- 1 root root 616 Nov 6 17:30 config.sh
-rw-r--r-- 1 root root 4601 Nov 6 17:30 config.xml
-rw-r--r-- 1 root root 29 Nov 6 17:30 disk.sh
-rw-r--r-- 1 root root 9 Nov 6 17:30 images.sh

Next create:

sudo kiwi-ng system create --root /tmp/mytest/myroot --target-dir /tmp/mytest/myimage

and I can see among others:

[ INFO ]: 17:34:08 | Calling images.sh script

So I assume you have a config.sh script or other type of code
that drops contents (or all) from the image/ directory in the root
tree when the prepare step builds it such that the subsequent
create step doesn't see any images.sh script

Hope this helps with the debugging

[Matt Tolle]

The images.sh seems to show up in the image ok: 

$ pwd
/tmp/build/image-root/image

$ ls -la
total 76
drwxr-xr-x.  2 root root   101 Nov  6 19:01 .
dr-xr-xr-x. 21 root root  4096 Nov  6 19:06 ..
-rw-r-----.  1 root root 14638 Nov  6 19:01 config.sh
-rw-r--r--.  1 root root 27041 Nov  6 19:01 config.xml
-rw-r-----.  1 root root   269 Nov  6 19:01 edit_boot_config.sh
-rwxr-x---.  1 root root  1687 Nov  6 19:01 images.sh
-rw-r--r--.  1 root root 17549 Nov  6 19:01 rhel.tgz

the rhel.tgz is an archive. That shouldn't overwrite the image dir. It only has a few files from /etc and /usr.

-Matt

[Matt Tolle]

Oddly.. if I do this: 

chmod 755 /tmp/build/image-root/image/*.sh

between the "system prepare" and the "system create" the images.sh runs just fine. The perms were 700 before. 

# egrep -i '(call_image_script|images.sh)' /tmp/kiwi-rhel9.log  

[ INFO    ]: 19:17:36 | --> Importing images.sh script to /app/build/image-root/image/images.sh
[ DEBUG   ]: 19:17:36 | EXEC: [cp ./images.sh /app/build/image-root/image/images.sh]
[ DEBUG   ]: 19:22:39 | EXEC: [chroot /app/build/image-root /image/images.sh]
[ INFO    ]: 19:22:39 | Calling images.sh script
[ DEBUG   ]: 19:22:39 | Running images.sh for [******]-[Cloud-GCE-LVM,Core-Cloud,Core-Boot,rhel]...
[ DEBUG   ]: 19:22:39 | images.sh completed.
[ DEBUG   ]: 19:22:39 | + echo 'Running images.sh for [******]-[Cloud-GCE-LVM,Core-Cloud,Core-Boot,rhel]...'
[ DEBUG   ]: 19:22:39 | + echo 'images.sh completed.'
[ INFO    ]: 19:57:43 | --> Importing images.sh script to /app/build/image-root/image/images.sh
[ DEBUG   ]: 19:57:43 | EXEC: [cp ./images.sh /app/build/image-root/image/images.sh]
[ DEBUG   ]: 20:02:45 | EXEC: [chroot /app/build/image-root /image/images.sh]
[ INFO    ]: 20:02:45 | Calling images.sh script
[ DEBUG   ]: 20:02:45 | Running images.sh for [******]-[Cloud-GCE-LVM,Core-Cloud,Core-Boot,rhel]...
[ DEBUG   ]: 20:02:45 | images.sh completed.
[ DEBUG   ]: 20:02:45 | + echo 'Running images.sh for [******]-[Cloud-GCE-LVM,Core-Cloud,Core-Boot,rhel]...'
[ DEBUG   ]: 20:02:45 | + echo 'images.sh completed.'

Not perfect.. but it works. 

Thanks for the help.

-Matt