Oh! It's been a while since I commented on #RedHat #ImageBuilder / #osbuild :D Let's correct that.

It's absolute awesome how you can set an #OpenSCAP profile directly in the blueprint. It's also completely useless :) It always performs both an evaluation and remediation step, with no option to run the remediation off, or to supply a tailored profile with added or excluded tests.

I can't imagine many images being built that don't have some form of post-processing, so running remediation beforehand is either just unwanted or worse, changes things that shouldn't be changed.

Now, I do really mean that the intention is awesome. I just think there weren't too many actual users offering input :) So, this is mine - please take it as constructive criticism.

Interested in what RHEL is doing in the Edge space?

Check out this 1hr session with Ben Breard talking about RHEL for Edge and a live demo that deploys an 8.7 version with a seamless upgrade to RHEL 9.2.

https://www.youtube.com/watch?v=QQs1AOCfg8k

Super proud that my team at Red Hat had a hand in this! ❤️

#ostree #edge #redhat #linux #osbuild

I'm sure you've been eagerly awaiting the next #redhat #imagebuilder / #osbuild story :D

$ composer-cli blueprints depsolve <name>

No issues.

$ composer-cli compose start <name> <image>

ERROR! DepsolveError:
...
- package fwupd obsoletes dbxtool
- conflicting requests

Yes. We all know fwupd has replaced dbxtool. Now please let me build?

(I have not found a solution to this yet - recall that osbuild uses its own dnf-resolve python code. Yes I've been hacking around in it with success)

Alright, next surprise with #RedHat #ImageBuilder / #osbuild :) We're on Red Hat 8.6, using the DVD as repo. When trying to install Node-JS through the blueprint we kept getting 10.24, even though 16.14 is clearly there when looking at the files. Changing 'version' just meant it couldn't find the package.

Oh. That's right. To get 16.14 we need to use 'module' with yum / dnf. Without it they will also only find 10.24. So how do we do that in the blueprint then?

You could assume that would be [[modules]] - but you'd be wrong. Modules and Packages work exactly the same (as documented).

The solution is ... [[groups]] :)

[[groups]]
name = "nodejs:16"

Quote from wldr-client github:

"groups is a TOML list, so each group needs to be listed separately, like packages but with no version number."

If you say so ;) The above solution is verified working.

well well well

With no other changes made to the blueprint, building a qcow2 instead of vmdk and then directly converting the qcow2 to vmdk worked.

So at this moment I would wager that there's an issue in Red Hat 8.6 osbuild / image builder when it comes to generating vmdk type filesystems.

#redhat #ImageBuilder #osbuild

Still confused. Having attached the vmdk in another VM and investigated the disk, layout, VG, VL etc I can only conclude that there really is something wrong with how the contents were created and the "bad superblock" message is correct.

#osbuild / image builder does seem a little bit shaky in various places.

#redhat

::: Fedora Linux 38 - live media creation modernized!

"As we look forward to new and better tooling for producing images (such as Kiwi and Osbuild), we cannot continue to rely on kickstart-driven image builds that construct shell scripts on the fly to embed in the image as we do now.

With livesys-scripts, those scripts have been simplified and turned into systemd services that activate only in live environments.

This also gives us the opportunity to introduce new functionality for live media."

=> https://fedoraproject.org/wiki/Changes/ModernizeLiveMedia

#Fedora #Linux #Live #Install #Media #development #RedHat #Kiwi #Osbuild