Ensure we're building on top of sipwise-trixie docker image, quoting
from jenkins-configs.git:
commit c3abc88488284a52f555223ad4e927d56193d561 (HEAD -> master, origin/master, origin/HEAD)
Author: Michael Prokop <mprokop@sipwise.com>
Date: Fri Jan 30 18:47:17 2026 +0100
MT#62249 Update sipwise-trixie docker image
Otherwise we end up with shipping ngcp-archive-keyring v2016.01.12+0~mr13.4.1.1
instead of the current one, v2016.01.12+0~mr14.0.1.2.
We ended up here after a many-hour debugging session, tackling the SHA-1
key situation for our Debian repository signing key.
When updating our stack, everything was fine, until we faked the date of
our deployment system and ended up with a breaking installation, because
the expected keyring files weren't there.
As it turned out, we're using the sipwise-trixie docker image as a base
for further docker runs, like present in deployment-iso's
grml-build-trixie one, which we use for building our Grml ISO.
Make sure we refresh our docker image, to have the latest
ngcp-archive-keyring package present.
Change-Id: I177c1ef189885c0d9524687d699b200d44626cd7
1. Add new screenshot with memtest v7 which is in trixie.
2. Use new screenshot for trixie builds.
3. Check the RC. According to the help page of screenshot-compare RC
higher then 100 means 'high difference'.
4. Bump REFRESHED_AT ro regenerate docker image.
Change-Id: I99fe27c146aefba3778d03b7d19c1c0bce52a635
grml-live had >410 commits since v0.47.7 (which we used so far),
including getting rid of FAI (through our own so called minifai
implementation), supporting mmdebstrap for bootstrapping (and using it
by default nowadays), and usage inside non-privileged containers.
Misc changes:
* No longer run any docker containers with --privileged, now that this
is handled all internally from within grml-live's build driver
* Upgrade everything to Debian/trixie (given that we also switched our
trunk/master branch towards trixie also)
* Provide wrapper.sh script to avoid maintaining it also inside
jenkins-configs' jobs/internal/grml/build_grml_image.sh (which meant
going through yet another layer and every single change to it required
a full jenkins-config change). Update README.txt accordingly to
provide usage examples.
* Set up keyring for custom bootstrapping using our own mirror, using
grml_build/config/bootstrap-keyring/SIPWISE and
deploying /usr/share/keyrings/sipwise-archive-keyring.gpg via
updatebase hook script
* Ship .gitignore files to ignore directories that are relevant for
the build process, though we also don't need to explicitly create them
on every single build any longer.
* Update configuration layout for grml-live change as of upstream
version v0.51.0 (see grml-live.git commit f1dc42a), moving from
/etc/grml/fai/config into /usr/share/grml-live/config.
* Update configuration layout for grml-live change as of upstream
version 0.53.0 (see grml-live.git commit 3a4bd41), changing schema
files/<path>/<CLASS> into files/<CLASS>/<path>,
class/<CLASS>.var into env/<CLASS> and
hooks/<hookname>.<CLASS> into hooks/<CLASS>/<hookname>.
* Add memtest86+ + ipxe to SIPWISE class, so they are available for boot
menu integration (grml-live uses addons from grml_chroot and no longer
from host system).
grml_build/Dockerfile related changes:
* Adjust ENV usage (fixes `LegacyKeyValueFormat: "ENV key=value" should
be used instead of legacy "ENV key value" format (line 9)`)
* Add snippet for usage with debian:trixie-slim as base docker image
(useful for debugging e.g. without access to Sipwise systems)
* Install ca-certificates (needed for access to https://github.com/ with
debian:trixie-slim)
* Switch from grml-live v0.47.7 to v0.53.2
* Drop deprecated dependencies that are no longer relevant with recent
grml-live versions (fai-client + fai-server get replaced by our own
minifai implementation, mksh is no longer relevant for grml-live, and
isolinux, ipxe, memtest86+ + syslinux are used from the grml_chroot
instead of from the host system, also see above)
* Instead install mmdebstrap (which is much faster for bootstrapping
than debootstrap), now being supported and the default, thanks to our
minifai implementation
* Drop /root/.bash_history, as we switched towards our custom wrapper.sh
script
t/Dockerfile related changes:
* Mark /code as safe directory for git, to not fail with
"fatal: detected dubious ownership in repository at '/code'"
* Adjust ENV usage (fixes `LegacyKeyValueFormat: "ENV key=value" should
be used instead of legacy "ENV key value" format (line 8)`)
Addendum: it's yet unclear why we need the `ulimit -n 1048576`
workaround to fix an apt/apt-mark performance issue. It feels similar to
what has been observed for fakeroot at https://bugs.debian.org/920913.
Credits to Chris Hofstaedtler for review and working on grml-live's
minifai, to support all our needs.
Change-Id: I85111806a550f1aeffcb5263af2455ec8b90cc32
Add options to install bullseye in all places where buster is used, use
it as default when possible, and keep these for the moment.
Switch to bullseye in Dockerfile.
Change-Id: I2f693982ba92a671a6f2254c5a245a1d05231404
* Addon fixes:
* Provide custom addon template according to our needs, instead of
relying on the default one being present in grml-live.git/templates
* Install memtest86+ as addon for BIOS usage
* Install netboot.xyz.lkrn for BIOS usage and netboot.xyz.efi for EFI usage
* Install ipxe.lkrn for BIOS usage and ipxe.efi for EFI usage
* Stick grml-live version to v0.34.3, instead of relying on some random
git master version
* Stick grml2usb version to v0.17.0, instead of relying on the grml2usb
version available on the host system (being 0.14.14 on Debian/stretch as
present on our current build hosts). For arbitrary addon file names we
need grml2iso (which uses grml2usb underneath) from grml2usb >=0.17.0.
FTR, grml2iso and grml2usb can be executed from within the git repository,
assuming all relevant tools are present
* No longer invoke isohybrid on the resulting ISO, instead rely on
grml2iso behaviour (which also checks for EFI support and enables
according switches as needed)
* Fix usage instructions in t/Dockerfile:
* it's "deployment-iso-buster" and not "lua-ngcp-kamailio-buster"
* refer to working directory instead of "deployment-iso.git",
which very probably isn't named as such on any of our systems,
while the $(pwd) approach works for c/p
* Fix docker build usage in grml_build/Dockerfile (for building we need
to provide a PATH (being current working directory for us)
* Provide testing tools in grml-build-buster docker environment
* Provide new testing script t/iso-tester to compare generated ISO
against pre-defined screenshot (only testing memtest feature using
./t/screenshots/01-memtest.jpg for now)
Change-Id: I67e3f85bbe86bd1b3ee709161504b5250ca5d7fe
We are going to provide common CE/PRO/Carrier install CD which
will install one release only. So deployment-iso.git will follow
the common NGCP branching/tagging model and will provide all the
necessary information inside Install CD (including deployment.sh
which previously was located into netscript.git).
Change-Id: Ia74d8c83f966237815b19a4a503183dfe85aa9d5