Troed Sångberg<p>Oh! It's been a while since I commented on <a href="https://ioc.exchange/tags/RedHat" class="mention hashtag" rel="tag">#<span>RedHat</span></a> <a href="https://ioc.exchange/tags/ImageBuilder" class="mention hashtag" rel="tag">#<span>ImageBuilder</span></a> / <a href="https://ioc.exchange/tags/osbuild" class="mention hashtag" rel="tag">#<span>osbuild</span></a> :D Let's correct that.</p><p>It's absolute awesome how you can set an <a href="https://ioc.exchange/tags/OpenSCAP" class="mention hashtag" rel="tag">#<span>OpenSCAP</span></a> profile directly in the blueprint. It's also completely useless :) It always performs both an evaluation and remediation step, with no option to turn the remediation off, or to supply a tailored profile with added or excluded tests.</p><p>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.</p><p>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.</p>
Recent searches
No recent searches
Search options
Only available when logged in.
ioc.exchange is one of the many independent Mastodon servers you can use to participate in the fediverse.
INDICATORS OF COMPROMISE (IOC)
InfoSec Community within the Fediverse. Newbies, experts, gurus - Everyone is Welcome! Instance is supposed to be fast and secure.
Administered by:
Server stats:
1.3Kactive users
ioc.exchange: About · Status · Profiles directory · Privacy policy
Mastodon: About · Get the app · Keyboard shortcuts · View source code · v4.3.7
#osbuild
0 posts · 0 participants · 0 posts today
Troed Sångberg<p>I'm sure you've been eagerly awaiting the next <a href="https://ioc.exchange/tags/redhat" class="mention hashtag" rel="tag">#<span>redhat</span></a> <a href="https://ioc.exchange/tags/imagebuilder" class="mention hashtag" rel="tag">#<span>imagebuilder</span></a> / <a href="https://ioc.exchange/tags/osbuild" class="mention hashtag" rel="tag">#<span>osbuild</span></a> story :D</p><p>$ composer-cli blueprints depsolve <name></p><p>No issues.</p><p>$ composer-cli compose start <name> <image></p><p>ERROR! DepsolveError:<br />...<br />- package fwupd obsoletes dbxtool<br />- conflicting requests</p><p>Yes. We all know fwupd has replaced dbxtool. Now please let me build?</p><p>(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)</p>
Troed Sångberg<p>Alright, next surprise with <a href="https://ioc.exchange/tags/RedHat" class="mention hashtag" rel="tag">#<span>RedHat</span></a> <a href="https://ioc.exchange/tags/ImageBuilder" class="mention hashtag" rel="tag">#<span>ImageBuilder</span></a> / <a href="https://ioc.exchange/tags/osbuild" class="mention hashtag" rel="tag">#<span>osbuild</span></a> :) 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.</p><p>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?</p><p>You could assume that would be [[modules]] - but you'd be wrong. Modules and Packages work exactly the same (as documented).</p><p>The solution is ... [[groups]] :) </p><p>[[groups]]<br />name = "nodejs:16"</p><p>Quote from wldr-client github:</p><p>"groups is a TOML list, so each group needs to be listed separately, like packages but with no version number."</p><p>If you say so ;) The above solution is verified working.</p>
Troed Sångberg<p>well well well</p><p>With no other changes made to the blueprint, building a qcow2 instead of vmdk and then directly converting the qcow2 to vmdk worked.</p><p>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.</p><p><a href="https://ioc.exchange/tags/redhat" class="mention hashtag" rel="tag">#<span>redhat</span></a> <a href="https://ioc.exchange/tags/ImageBuilder" class="mention hashtag" rel="tag">#<span>ImageBuilder</span></a> <a href="https://ioc.exchange/tags/osbuild" class="mention hashtag" rel="tag">#<span>osbuild</span></a></p>
Troed Sångberg<p>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. </p><p><a href="https://ioc.exchange/tags/osbuild" class="mention hashtag" rel="tag">#<span>osbuild</span></a> / image builder does seem a little bit shaky in various places.</p><p><a href="https://ioc.exchange/tags/redhat" class="mention hashtag" rel="tag">#<span>redhat</span></a></p>
ExploreLive feeds
Mastodon is the best way to keep up with what's happening.
Follow anyone across the fediverse and see it all in chronological order. No algorithms, ads, or clickbait in sight.
Create accountLoginDrag & drop to upload