Go to file
2024-05-03 23:40:06 -07:00
cloud langpacks-en is needed temporarily 2024-05-01 15:45:20 -07:00
components kernel should not be there for pi 2024-05-03 16:06:03 -07:00
configs sbc: add more pi steps 2024-05-03 12:56:11 -07:00
container add container definitions 2024-04-23 14:18:31 -07:00
live Add KDE and Cinnamon spins 2024-04-01 18:19:03 -07:00
repositories add key 2024-05-03 19:44:45 -07:00
root/etc poc: init for r9 2024-03-28 23:19:47 -07:00
sbc remove format for sbc 2024-05-03 23:40:06 -07:00
vagrant drop container-build in root 2024-05-01 16:17:43 -07:00
cloud-build.sh add debug fix to scripts 2024-05-01 15:26:37 -07:00
config.sh use labels 2024-05-03 13:59:53 -07:00
config.xml config adjustments 2024-03-28 23:38:44 -07:00
container-build.sh drop container-build in root 2024-05-01 16:17:43 -07:00
grub.tmpl poc: init for r9 2024-03-28 23:19:47 -07:00
live-build.sh support minor 2024-05-01 16:47:35 -07:00
README.md support minor 2024-05-01 16:47:35 -07:00
sbc-build.sh sbc: add more pi steps 2024-05-03 12:56:11 -07:00

rocky-kiwi-descriptions

Kiwi descriptions for Rocky Linux 9.

config.xml is a symlink to rocky.xml. this way the symlink can just be changed to deal with live images (as kiwi doesn't seem to support using the --kiwi-file option for iso).

Can't you use the same config.xml? Why are you symlinking?

Yes and the reason why we're symlinking is that "name" and "displayname" are not flexible. They are only set/read at the very top level <image> (at least from testing at the time of this writing). As our images and volume names (at least for live images) have a very specific format, and we want it to be easy to rename them, we did it this way.

Cloud, container, vagrant images can all use the first config, likely just fine. The live images were the problematic ones, thus, symlinks with a default to the rocky.xml config.

I found an issue...

Please fork and make a PR! We're still learning how this tool works ourselves.

How to try it out

You can actually do this in mock pretty easily. You could also probably get this running in a podman container or otherwise. As of this writing, we haven't tried it yet. Theory says it should work.

Note: SELinux must be set to permissive.

Note: There may be cases where a build will fail in mock. If this is the case, you will need to use --isolation=simple.

Live Image Example (EPEL)

The below makes an XFCE live image using SIG/Core packages.

# Use SIG/Core
% git clone https://git.resf.org/sig_core/mock-rocky-configs
% bash deploy.sh
% mock -r rl-9-x86_64-core-infra --init
% mock -r rl-9-x86_64-core-infra --install kiwi-cli git \
  dracut-kiwi-live \
  kiwi-systemdeps-{bootloaders,containers,core,disk-images,filesystems,image-validation,iso-media} \
  epel-release \
  rocky-release-core

% sudo setenforce 0
% mock -r rl-9-x86_64-core-infra --shell --enable-network
% git clone https://git.resf.org/sig_core/rocky-kiwi-descriptions -b r9
% cd rocky-kiwi-descriptions
% ln -sf configs/live-xfce.xml config.xml
% kiwi-ng --debug --type="iso" \
  --profile="XFCE-Live" \
  --color-output system \
  build \ 
  --description="./" \
  --target-dir /builddir/lmc

The below uses EPEL instead if you do not wish to use SIG/Core.

# Use EPEL
% mock -r rocky+epel-9-x86_64 --init
% mock -r rocky+epel-9-x86_64 --install kiwi-cli git \
  dracut-kiwi-live \
  kiwi-systemdeps-{bootloaders,containers,core,disk-images,filesystems,image-validation,iso-media} \
  distribution-gpg-keys \
  epel-release

% sudo setenforce 0
% mock -r rocky+epel-9-x86_64 --shell --enable-network
% git clone https://git.resf.org/sig_core/rocky-kiwi-descriptions -b r9
% cd rocky-kiwi-descriptions
% ln -sf configs/live-xfce.xml config.xml
% kiwi-ng --debug --type="iso" \
  --profile="XFCE-Live" \
  --color-output system \
  build \ 
  --description="./" \
  --target-dir /builddir/lmc

On the other hand, you can run the live-build.sh script after setting up your mock environment.

% bash live-build.sh --live-image XFCE --output-dir /builddir/xfce