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
When one boots into the rescue system and manually invokes the
deployment script, the boot option debianrelease=... isn't set.
Then we use the default DEBIAN_RELEASE setting, and given that we
use Debian/trixie as our current release, adjust this accordingly.
Change-Id: I3a28a75775a95b0a16d8d2ec087d928c25a5f09a
Lots of changes took place in between v0.54.1 and v0.55.1 upstream[1].
To ensure to follow upstream changes, let's make sure our configuration
avoids relying on features that are going to be dropped in upcoming
versions.
[1] FTR:
% git log --oneline --no-merges v0.54.1..v0.55.1 ^83c27dcf
28272472 (tag: v0.55.1) Update changelog for 0.55.1 release
7e3e30d6 (pull-requests/452) SW: add ncurses-term to GRML_FULL,GRML_SMALL
94f956a1 (pull-requests/451, origin/mika/p9) 9p virtio: do not complain if mount_tag doesn't exist
0b6b8db2 (pull-requests/450, origin/mika/flashrom) SW: drop flashrom package from GRML_FULL
1f7fee83 (tag: v0.55.0) Update changelog for 0.55.0 release
7ebdc43e (pull-requests/449, origin/mika/outputdir) Fix output directory handling if base directory doesn't exist
6c64ec50 (pull-requests/447, origin/mika/squashfs) Fix squashfs exclude usage for grml-live directory
523de64c (pull-requests/446, origin/mika/firmware) SW: add firmware-mediatek to GRMLBASE
00322e7b (pull-requests/445) ZFS remove /proc workaround
04593ba9 (pull-requests/444, origin/mika/xorg, mika/xorg) SW: drop grml-desktop from XORG
7c010147 (pull-requests/443) SW: GRML_FULL: remove mpt-status
64f6ec40 (pull-requests/424) grml.sources snapshot: disable
62a7d5f3 (pull-requests/435, origin/mika/vbox) grml-autoconfig _detect_virtual: prefer Virtualbox over KVM in virt-what
b7c7c20a (pull-requests/146) also mention -I/CHROOT_INSTALL as a possible ssh key injection point
2cd9a141 explain operators how to complete the TOR configuration
661be4de Revert "new SSHGEN class to generate SSH keys at build time"
3cdd9610 new SSHGEN class to generate SSH keys at build time
c4ab37ff add TOR class to the grml-live(8) manual
d1f8ad19 (pull-requests/439, origin/zeha/doc-cleanup) doc: stylize the output directories consistently
ac4dfbb8 doc: specify bookworm as minimum host Debian
91125018 doc: remove squashfs version info
4c85eae5 doc: remove outdated base tarball instructions
345e1b92 (pull-requests/438) doc: simplify "local-files" example with -I option
911a66e9 TOR class to allow remote SSH access over deep networks
af5b4c69 (pull-requests/437, origin/zeha/no-snapshot) build-driver: remove SNAPSHOT
5a79060c (pull-requests/436) restore-config: do not read unused /etc/grml/script-functions
c233f265 (pull-requests/434, origin/mika/bootctl) SW: add systemd-boot-tools to GRML_SMALL + GRML_FULL
acf7575e (pull-requests/433) Stop symlinking /etc/locale.alias
ebe9b2ec (pull-requests/430, origin/zeha/adoc) Rename asciidoc files to *.adoc
cfe71db7 (pull-requests/429, origin/zeha/merge-run-screen) config: import run-screen from grml-scripts
bd281f83 config: getty@tty12: inline run-journalctl
80a4a71f (pull-requests/423) Restrict Docker image pushes to branches from upstream repo
d04e2394 (pull-requests/422) 15-initsetup: Ignore errors as systemd upstream does not support containers
4fe5b0e5 (pull-requests/421) cheatcodes: drop nosyslog option
ae2a3185 cheatcodes: drop noconsolefont option
49421fdd cheatcodes: drop wondershaper option
e5b0e7ef 15-initsetup: un-function-ify
5324bf46 (pull-requests/415) 98-clean-chroot: install xinit files as executable
bda93669 (pull-requests/417) config: drop DEBIAN_BULLSEYE class
18bd18a1 (pull-requests/418) Build Docker images and publish to GitHub Package Registry
f53cf463 grml-desktop: appease shellcheck
5945ee74 cheatcodes: remove mention of release 2010.12 in example
8257f7f1 cheatcodes: drop info about releases older than 10 years
8a0756df 41-memtest: drop support for memtest86+ from bullseye
8a108094 SW: drop grml-desktop
Change-Id: I4ded42b493632bc15226a2b8399f6587adc2f95a
The einfo() function is available via /etc/grml/lsb-functions,
which we don't source in our deployment.sh.
Fixes:
Creating partition table
/tmp/netscript.grml: line 357: einfo: command not found
Thanks: Volodymyr Fedorov for reporting
Change-Id: Ifc1d06fa8c7f64db502054c501c12e0d8b122dd5
- Update copyright years.
- Update Standards-Version to 4.7.2.
- Remove «Rules-Requires-Root: no» field, which is now the default.
- Remove «Priority: optional» field, which is now the default.
- Wrap and sort fields.
- Add spaces around operators in make variables.
Change-Id: I1f1b149c24cfd8302f7f584be4b70e2d904e80e7
The file path was adjusted in grml-live upstream
commit 303888ac617cee40f82b61190071d92b4f82de96
Otherwise the "Boot from ... boot device" entries fail to run due to:
Failed to load COM32 file /boot/addons/chain.c32
As reported by Mike Jackson on spce-user ML.
Change-Id: Id06d4c53f4fab043e093bba6e2e95f1936610271
So we have reproducible Grml-sipwise image building.
If variable repo_date is set - use it with option '-w' for a Debian
wayback machine.
Change-Id: I84491fd746746ab04158adfd5537b0cfadd8b3d5
This option is used to force using of mrX.X.X-update repo. It's
necessary for testing of LTS CE releases which are already out of
support. We still want to test the code despite it's EOL so for such a
cases use our internal repo.
Fix typos.
Change-Id: I33c1b5f3c3e309d586428c087eae09eda71a4743
There is a missing single quote in the build command for
BOOTSTRAP_MIRROR
>build_command+=" BOOTSTRAP_MIRROR=${debian_bootstrap_url}'"
Change-Id: I07daccfb3c8eeb8ed4ae9a8c307037ba14caf2a4
Lots of changes took place in between v0.53.2 and v0.54.1. To ensure to
follow upstream changes, let's make sure our configuration avoids
relying on features that are going to be dropped in upcoming versions.
Relevant changes:
* FAI_DEBOOTSTRAP=... became BOOTSTRAP_MIRROR=... (without the Debian
release name, but just requiring the mirror URL)
* the templates command line option `-t ...` is considered deprecated,
now that boot templates are also class-based configuration files
(via ${GRML_FAI_CONFIG}/config/media-files/$CLASS)
Let's keep our templates as-is, but provide
grml_build/config/media-files/SIPWISE as symlink to our templates
directory
* GRMLBASE and architecture-specific classes are now enabled by
default and no longer should be included in the grml-live invocation,
so drop GRMLBASE + AMD64 class names in wrapper.sh
* The RELEASE class (which cleans up /root and /home/grml) is also
automatically enabled, but since we e.g. ship files like /root/puppet.gpg
we need to disable this new behavior by enabling the new "-R" option
Change-Id: I66dc8c685decac25370234844e33d4be60dea08a
Once again, puppetlabs doesn't provide packages for Debian/trixie yet,
so use the AIO packages from the bookworm repos for now.
Change-Id: I62f0a1c9a812acfd9e827ee4d903bf3f8239ee37
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
Noted in daily-build-carrier-runner installation (see
https://jenkins.mgm.sipwise.com/job/daily-build-install-vm/148320/console):
| Installing for i386-pc platform.
| grub-install: error: unable to identify a filesystem in mduuid/ad9e241cd5c1093cd46de7932bc3fce1; safety check can't be performed.
| Error: failed to execute 'grub-install --no-floppy --target=i386-pc /dev/md0'.
One can run 'grub-install /dev/md0' without problems on EFI systems, as
this doesn't really touch the disks then. But in non-EFI systems, this
fails hard, because GRUB doesn't support direct installation to the
SW-RAID.
Instead we need to iterate over all the disks separately, being already
handled within stage swraidinstallgrub:
| +11:37:12 (deployment.sh:2457): set_deploy_status swraidinstallgrub
| +11:37:12 (deployment.sh:102): set_deploy_status(): '[' -n swraidinstallgrub ']'
| +11:37:12 (deployment.sh:103): set_deploy_status(): echo swraidinstallgrub
| +11:37:12 (deployment.sh:2458): for disk in "${SWRAID_DISK1}" "${SWRAID_DISK2}"
| +11:37:12 (deployment.sh:2459): grml-chroot /mnt grub-install /dev/sda
| Writing /etc/debian_chroot ...
| Installing for i386-pc platform.
| Installation finished. No error reported.
| +11:37:12 (deployment.sh:2458): for disk in "${SWRAID_DISK1}" "${SWRAID_DISK2}"
| +11:37:12 (deployment.sh:2459): grml-chroot /mnt grub-install /dev/sdb
| Writing /etc/debian_chroot ...
| Installing for i386-pc platform.
| Installation finished. No error reported.
| +11:37:13 (deployment.sh:2462): grml-chroot /mnt update-grub
| Writing /etc/debian_chroot ...
| Generating grub configuration file ...
| Found linux image: /boot/vmlinuz-6.12.33+deb13-amd64
| Found initrd image: /boot/initrd.img-6.12.33+deb13-amd64
| Adding boot menu entry for UEFI Firmware Settings ...
| done
So install GRUB only to the *first* SW-RAID disk.
Change-Id: I436e3deca37d68ef505d44fd24620028f2ded0f4
With kernel versions >=6.3, efivarfs is loaded even when
the system wasn't booted in EFI mode. But loading efivarfs
fails:
| root@web01a ~ # lsmod | grep efi
| efivarfs 28672 0
|
| root@web01a ~ # ls /sys/firmware/efi/
| ls: cannot access '/sys/firmware/efi/': No such file or directory
|
| root@web01a ~ # mount -t efivarfs efivarfs /sys/firmware/efi/efivars
| mount: /sys/firmware/efi/efivars: fsopen() failed: Operation not supported.
| dmesg(1) may have more information after failed mount system call.
Adjust our EFI support detection code to what we're also doing in
grml-debootstrap.git (see commit
b8a6a2c90f5bffceeb7d85cdc30ac7a7e58f4c0b).
Furthermore by now we have grml-debootstrap v0.121 available in our
current deployment ISO, so drop the now deprecated efivars_workaround.
Change-Id: I2210a7b87d0df2ae41872380e458e29e755f6886
mdadm upstream commit
e97c4e18c8
changed its behavior, now (pretty much) always promting the user for the
expected bitmap configuration. :(
Now with mdadm v4.4-11 as present in current Debian/trixie,
automatically creating a mdadm array fails for us:
| (netscript.grml:704): set_up_partition_table_swraid(): echo y
| (netscript.grml:704): set_up_partition_table_swraid(): mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sda3 /dev/sdb3
| To optimalize recovery speed, it is recommended to enable write-indent bitmap, do you want to enable it now? [y/N]? mdadm: /dev/sda3 appears to be part of a raid array:
| level=raid1 devices=2 ctime=Mon Jun 16 13:39:42 2025
| mdadm: Note: this array has metadata at the start and
| may not be suitable as a boot device. If you plan to
| store '/boot' on this device please ensure that
| your boot-loader understands md/v1.x metadata, or use
| --metadata=0.90
| mdadm: /dev/sdb3 appears to be part of a raid array:
| level=raid1 devices=2 ctime=Mon Jun 16 13:39:42 2025
| mdadm: size set to 468218880K
Behavior with mdadm versions older than 4.4 (e.g. with mdadm 4.2-5 as
present with our previous deployment system):
| (netscript.grml:703): set_up_partition_table_swraid(): echo y
| (netscript.grml:703): set_up_partition_table_swraid(): mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sda3 /dev/sdb3
| mdadm: /dev/sda3 appears to be part of a raid array:
| level=raid1 devices=2 ctime=Mon Jun 16 13:39:42 2025
| mdadm: Note: this array has metadata at the start and
| may not be suitable as a boot device. If you plan to
| store '/boot' on this device please ensure that
| your boot-loader understands md/v1.x metadata, or use
| --metadata=0.90
| mdadm: /dev/sdb3 appears to be part of a raid array:
| level=raid1 devices=2 ctime=Mon Jun 16 13:39:42 2025
| mdadm: size set to 468218880K
| mdadm: automatically enabling write-intent bitmap on large array
| Continue creating array? mdadm: Defaulting to version 1.2 metadata
| mdadm: array /dev/md0 started.
Now with this mdadm behavior change, we seem to have the following
options to handle this:
1) Explicitly enable the `--bitmap=internal` command line option:
| root@grml ~ # echo y | mdadm --create --verbose --bitmap=internal /dev/md0 --level=1 --raid-devices=2 /dev/sda3 /dev/sdb3
| mdadm: /dev/sda3 appears to be part of a raid array:
| level=raid1 devices=2 ctime=Thu Jun 19 09:26:41 2025
| mdadm: Note: this array has metadata at the start and
| may not be suitable as a boot device. If you plan to
| store '/boot' on this device please ensure that
| your boot-loader understands md/v1.x metadata, or use
| --metadata=0.90
| mdadm: /dev/sdb3 appears to be part of a raid array:
| level=raid1 devices=2 ctime=Thu Jun 19 09:26:41 2025
| mdadm: size set to 468218880K
| Continue creating array [y/N]? mdadm: Defaulting to version 1.2 metadata
| mdadm: array /dev/md0 started.
This option enables an explicit choice, causing the bitmap to be
stored with the metadata on the array (and so is replicated on all
devices). While this might be the preferred option for now, mdadm
internals might change over time, so I would prefer not to(tm) rely
on this option.
2) Piping `yes` into mdadm
| root@grml ~ # yes | mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sda3 /dev/sdb3
| To optimalize recovery speed, it is recommended to enable write-indent bitmap, do you want to enable it now? [y/N]? mdadm: /dev/sda3 appears to be part of a raid array:
| level=raid1 devices=2 ctime=Thu Jun 19 09:25:35 2025
| mdadm: Note: this array has metadata at the start and
| may not be suitable as a boot device. If you plan to
| store '/boot' on this device please ensure that
| your boot-loader understands md/v1.x metadata, or use
| --metadata=0.90
| mdadm: /dev/sdb3 appears to be part of a raid array:
| level=raid1 devices=2 ctime=Thu Jun 19 09:25:35 2025
| mdadm: size set to 468218880K
| Continue creating array [y/N]? mdadm: Defaulting to version 1.2 metadata
| mdadm: array /dev/md0 started.
This would be my preferred choice, but it still causes an error within
mdadm, returning with exit 141 while not reporting an actual error:
| root@grml ~ # set -o pipefail
| root@grml ~ # yes | mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sda3 /dev/sdb3
| To optimalize recovery speed, it is recommended to enable write-indent bitmap, do you want to enable it now? [y/N]? mdadm: /dev/sda3 appears to be part of a raid array:
| level=raid1 devices=2 ctime=Thu Jun 19 10:02:32 2025
| mdadm: Note: this array has metadata at the start and
| may not be suitable as a boot device. If you plan to
| store '/boot' on this device please ensure that
| your boot-loader understands md/v1.x metadata, or use
| --metadata=0.90
| mdadm: /dev/sdb3 appears to be part of a raid array:
| level=raid1 devices=2 ctime=Thu Jun 19 10:02:32 2025
| mdadm: size set to 468218880K
| Continue creating array [y/N]? mdadm: Defaulting to version 1.2 metadata
| mdadm: array /dev/md0 started.
| 141 root@grml ~ #
We could disable the pipefail option around the mdadm execution in our
script, though this might have unindented side-effects for us with
further failures. So I would prefer not to(tm) rely on this option,
neither.
3) Enable mdadm's `--run` command line option:
| root@grml ~ # echo y | mdadm --create --run --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sda3 /dev/sdb3
| mdadm: /dev/sda3 appears to be part of a raid array:
| level=raid1 devices=2 ctime=Thu Jun 19 09:23:48 2025
| mdadm: Note: this array has metadata at the start and
| may not be suitable as a boot device. If you plan to
| store '/boot' on this device please ensure that
| your boot-loader understands md/v1.x metadata, or use
| --metadata=0.90
| mdadm: /dev/sdb3 appears to be part of a raid array:
| level=raid1 devices=2 ctime=Thu Jun 19 09:23:48 2025
| mdadm: size set to 468218880K
| mdadm: creation continuing despite oddities due to --run
| mdadm: Defaulting to version 1.2 metadata
| mdadm: array /dev/md0 started.
The `--run` option is documented as follows in mdadm(8):
| Insist that mdadm run the array, even if some of the
| components appear to be active in another array or filesystem. Normally
| mdadm will ask for confirmation before including such components in an
| array. This option causes that question to be suppressed.
and under "CREATE MODE" it also says:
| --run insist on running the array even if some devices look like they
| might be in use.
It seems to be the only way to disable user prompting, so it seems to
be our preferred choice.
BTW: not even the `--force` option prevents this question:
| # mdadm --create --force --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sda3 /dev/sdb3
| To optimalize recovery speed, it is recommended to enable write-indent bitmap, do you want to enable it now? [y/N]? ^C
OH: "--run is the new --force"
Change-Id: I26bcef8f8e5da057ba3029e0bdbbb7cf527f0374
In jenkins-configs commit 765cbf270df321c8c08d567a9803064696c78028
AKA "TT#62000 Add puppet key to Grml-sipwise image" we
included the puppetlabs upstream key into our deployment ISO.
Updating the file is error prone and requires quite some effort
(including changes to jenkins-configs!), whenever the file needs to be
adjusted. In commit 8647b3d7b5 we went
for usage of http://apt.puppetlabs.com/DEB-GPG-KEY-puppetlabs, which is
the *expired* key though. :-/
| % gpg DEB-GPG-KEY-puppetlabs
| gpg: WARNING: no command supplied. Trying to guess what you mean ...
| pub rsa4096/1054B7A24BD6EC30 2010-07-10 [SC] [expired: 2017-01-05]
| 47B320EB4C7C375AA9DAE1A01054B7A24BD6EC30
| uid Puppet Labs Release Key (Puppet Labs Release Key) <info@puppetlabs.com>
|
| % md5sum DEB-GPG-KEY-puppetlabs
| 7b4ed31e1028f921b5c965df0a42e508 DEB-GPG-KEY-puppetlabs
So let's check for the expired key, and if present then retrieve the
*current* and proper repository key instead. But instead of using
upstream infra http://apt.puppetlabs.com/pubkey.gpg (which we don't have
under control on our own and might be unavailable during our
deployments), we placed a copy of the key on our own infrastructure:
| mprokop@jenkins1 ~www/files % wget --quiet -O puppetlabs-pubkey-2025.gpg http://apt.puppetlabs.com/pubkey.gpg
| mprokop@jenkins1 ~www/files % ls -lah puppetlabs-pubkey-2025.gpg
| -rw-r--r-- 1 mprokop sipwise 3.2K Apr 9 19:56 puppetlabs-pubkey-2025.gpg
| mprokop@jenkins1 ~www/files % gpg puppetlabs-pubkey-2025.gpg
| gpg: WARNING: no command supplied. Trying to guess what you mean ...
| pub rsa4096 2019-04-08 [SC]
| D6811ED3ADEEB8441AF5AA8F4528B6CD9E61EF26
| uid Puppet, Inc. Release Key (Puppet, Inc. Release Key) <release@puppet.com>
| sub rsa4096 2019-04-08 [E]
| mprokop@jenkins1 ~www/files % md5sum puppetlabs-pubkey-2025.gpg
| d6368c2df370ff2093831daad16d9eeb puppetlabs-pubkey-2025.gpg
| mprokop@jenkins1 ~www/files %
Given that the file puppet.gpg is also in the wrong format for direct
usage with apt-key with its gpg file extension, let's copy it as
puppet.asc then, as expected by apt.
FTR: this used to work in the past only, as in jenkins-config's
jobs/internal/grml/build_grml_image.sh we converted the key for usage as
puppet.gpg within apt, via:
| puppet_key='puppet.gpg'
| gpg --export --no-default-keyring --keyring /etc/apt/trusted.gpg \
| --output "${puppet_key}" release@puppet.com
Change-Id: I7fe7dd20d89ed638112638930f578b6bb3783a5c
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
grml2usb had 47 commits since v0.19.2 (which we used so far), time to
bump it to its most recent stable version (being v0.20.6), which is also
part of current Debian/trixie.
While at it, drop deprecated grml64-small_2018.04.11-efi workaround.
Change-Id: Iac59b6ba9cf1f3782e10dd612153cd8e451c2ea3
Nowadays puppetlabs upstream provides the puppet-agent package
for Debian/bookworm, so we no longer need to work around this
by installing the puppet-agent package from bullseye on bookworm
systems.
Change-Id: Iad081fa02f4fb619330177c38673c86db60f2034
We no longer install any system with bullseye by default (we're using
bookworm internally and starting with trixie support f.e. for NGCP).
The buster workaround LVM support on Debian/buster and the dpkg
workaround for stretch/buster are no longer relevant.
Change-Id: Id96c0c1ce2b49d6332a4eb092a9f559dc221e607
Quoting from grml-live upstream:
| commit 3edddaef70f137f4f2874cef669c05948a41438c
| Author: Michael Prokop <mika@grml.org>
| Date: Mon Apr 11 18:47:19 2022 +0200
|
| SW: move from ntp/ntpdate to ntpsec/ntpsec-ntpdate in GRML_SMALL + GRML_FULL
|
| Starting with bookworm (current Debian/testing), ntpsec replaces ntp,
| and ntpsec-ntpdate replaces ntpdate. Now both the ntp + ntpdate packages
| are transitional packages. Given that ntpsec/ntpsec-ntpdate are
| available even for oldstable, let's follow this transition now (also see
| https://sources.debian.org/src/ntpsec/1.2.1%2Bdfsg1-6/debian/NEWS/).
| [...]
Now that ntpdate no longer exists in Debian/trixie, we need to switch
from ntpdate to ntpsec-ntpdate in our deployment ISO (the later package
also provides the /usr/sbin/ntpdate binary, so nothing further needs to
be adjusted).
Given that ntpsec-ntpdate exists even since oldoldstable AKA buster, we
can further adjust it in our deployment script for our puppet
deployments (to not break when switching to trixie there).
Change-Id: Ie332023aa2e6b4afedddf5a5077cec1c41ecb75b
Quoting from grml-live upstream:
| commit 61b77ff04fb60e09123a79b5f0ededbb6455add5
| Author: Michael Prokop <mika@grml.org>
| Date: Thu Dec 13 12:08:01 2018 +0100
|
| SW: drop deprecated cpufrequtils (+ drop scripts/GRMLBASE/36-cpufrequtils)
|
| The cpufreq drivers are autoloaded and the powersave/ondemand driver
| is mature enough. The linux-cpupower tools provide the binaries
| as replacement for what cpufrequtils provided so far and we ship
| them (with GRML_FULL) already.
|
| Also see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877016
|
| Thanks: Michael Biebl for the pointer
| Closes: https://github.com/grml/grml/issues/51
Now that cpufrequtils no longer exists as of Debian/trixie and newer,
drop it accordingly in our deployment ISO.
Change-Id: I4373ef907824a844cdf8adf240fa3cc2f878a1cd
We need to use the same VirtualBox Guest Additions ISO in both sp1 and
sp2, and instead of duplicating part of the installation logic, from
where to get the original files, just install the ISO on the target,
so that we can then copy it to sp2 and install it from there.
Change-Id: If1b6d0c4609be8504ff2d1bfcb0d9d7e36897539
If /sbin/fsck.ext4 (being a symlink pointing to /sbin/e2fsck) isn't
available, then update-initramfs complains with:
| update-initramfs: Generating /boot/initrd.img-6.12.27-amd64
| W: /sbin/fsck.ext4 doesn't exist, can't install to initramfs
Ensure to have e2fsprogs always available, given that its priority was
decreased from required to important with e2fsprogs v1.47.2-1, so it's
no longer necessarily part of a fresh Debian system as of trixie.
See https://bugs-devel.debian.org/cgi-bin/bugreport.cgi?bug=897277
Change-Id: Ia3fbfed9d499cce09d46cdfb6c6a290d16fb3f1b
We had to revert commit 2974f71127,
as we're relying on the /sys/block autodetection code in our VM
builds that don't specify the target disk explicitly.
So instead let's reintroduce the code, but also support
NVMe disks and make the code more generic WRT sda vs vda.
While at it, also report a message whenever we're running through this
autodetection code.
Change-Id: I39fe04def1694f127a99c97f91fabc2768fec1c7
This reverts commit 2974f71127.
This breaks our automated VM builds which don't set the target disk.
Change-Id: Iad3c21ae69e983de651fedbc6d50633d2dde0a3b
This was actually hiding a problem and is a f'up related to the previous
commit 001c9c6073.
When we're deploying a system with SW-RAID to sd* based disks (with boot
options like swraiddisk1=sda swraiddisk2=sdb), we're not setting
TARGET_DISK, but instead old autodetection code kicks in. This only
supports block devices like vd* + sd*, but then sets DISK to the first
such present disk.
As a result, we're ending up with a grml-debootstrap command line like
this:
| (netscript.grml:2219): grml-debootstrap --arch amd64 --grub /dev/sda --filesystem ext4 [...] -r bookworm -t /dev/mapper/ngcp-root --efi /dev/sda2 [...]
This propagates through grml-debootstrap into GRUB's debconf settings
for the /dev/sda disk, showing up like this:
| root@db01a:~# debconf-show grub-cloud-amd64
| * grub-cloud-amd64/install_devices: /dev/disk/by-id/ata-MTFDDAK480TDT-1AW1ZA_02JG544D7A44709LEN_3416E3FC
This is unexpected behavior, as GRUB would get installed on one disk only.
Also, when deploying to disks other than vda and sd* (e.g. with
NVMe ones), this shouldn't just use unrelated disks, but instead either
work with the expected ones or abort hard (as has been observed in the
previous commit with the NVMe disks).
Furthermore there's no point in further shipping this autodetection code
any longer at all, as we're using the TARGET_DISK approach only via
disk_selection.sh. Otherwise we're expecting the deployment system
(Grml-Deployment ISO, PXE boot environment,...) to fully control and
pass expected disk options.
It's 2025, and NVMe disks are a thing, so good riddance!
Thanks: Volodymyr Fedorov for reporting and assistance
Change-Id: I3fd7aa75a38dc0f07bc07d5b22139a89498f7b96
Since grml-debootstrap v0.116 there's a reworked GRUB setup, to support
installing both BIOS and UEFI bootloaders, and manage its updates via
grub-cloud-amd64 (see
2891f1730f
for details).
Now that we're shipping grml-debootstrap v0.119 in our latest
Grml-Sipwise deployment ISO, we're making use of its new behavior.
As it turned out, when deploying a SW-RAID based NGCP system, we invoke
grml-debootstrap with incomplete `--grub /dev/`. This is of course
incomplete and unexpected, but only started to fail with the more recent
grml-debootstrap version.
The underlying issue is grml-debootstrap setting GRUB's debconf
configuration to:
grub-cloud-amd64/install_devices: /dev/
And if we're installing grub-cloud-amd64 (or its not an EFI system),
then grml-debootstrap also executes:
grub-install --no-floppy --target=i386-pc "${device}"
Which of course won't work with the device being set to `/dev/`:
| Setting up grub-cloud-amd64 (0.0.5) ...
| Skipping installation without enable flag for cloud.
| Processing triggers for libc-bin (2.36-9+deb12u10) ...
| Installing grub on /dev/:
| Installing for x86_64-efi platform.
| Installation finished. No error reported.
| Installing for i386-pc platform.
| grub-install: error: cannot read `/dev': Is a directory.
| Error: failed to execute 'grub-install --no-floppy --target=i386-pc /dev/'.
To avoid any such failure, make sure grml-debootstrap's --grub option
uses a valid block device, also when installing SW-RAID (and even if it
actually shouldn't matter for EFI environments).
See https://github.com/grml/grml-debootstrap/issues/339 for further
details.
Change-Id: I6b839f708806c5107a1c86adbee1407cbeadddcc
We get failing ngcp-status on our trunk systems, due to:
| root@spce:~# systemctl --failed
| UNIT LOAD ACTIVE SUB DESCRIPTION
| ● vboxadd-service.service loaded failed failed VirtualBox Guest Additions Services Daemon
| ● vboxadd.service loaded failed failed vboxadd.service
While we're not even running inside a VirtualBox environment:
| root@spce:~# systemd-detect-virt
| kvm
We install /etc/systemd/system/vboxadd-service.service.d/override.conf
and /etc/systemd/system/vboxadd-service.service.d/override.conf with
`ConditionVirtualization=oracle` through our templates (see its git rev
a2521b609300965e5f8dfdeee63c5961f2d6a559) to address this. But this is
too late to the party, as the vboxadd* services are started *before* our
overrides get relevant.
So ensure we place the overrides already *before* even installing the
VBoxGuestAdditions.iso and executing its VBoxLinuxAdditions.run.
This then prevents the execution inside our Proxmox VMs, and not
reporting failing vboxadd-service + vboxadd services then:
| systemd[1]: vboxadd.service was skipped because of an unmet condition check (ConditionVirtualization=oracle).
Change-Id: I1a3a04bdc5d92d3fc79b336018ac5f588266c59b
virtualbox-guest-additions-iso v7.0.20-1 as present in current Debian/trixie
doesn't yet support kernel v6.12.22-1 (being the current kernel version
in Debian/trixie), while upstream supports kernel 6.12 as of VirtualBox 7.1.4.
Reported towards Debian as https://bugs.debian.org/1104024
FTR:
| mprokop@jenkins1 ~ % cd /var/www/files
| mprokop@jenkins1 ~www/files % wget https://download.virtualbox.org/virtualbox/7.1.8/VBoxGuestAdditions_7.1.8.iso
| [...]
| mprokop@jenkins1 ~www/files % curl -s https://download.virtualbox.org/virtualbox/7.1.8/SHA256SUMS | sha256sum -c --ignore-missing
| VBoxGuestAdditions_7.1.8.iso: OK
Change-Id: I32aa7806e375c4b85084a99d5a6903f632807694
Our deployment ISO might be outdated and when installing any additional
packages, we might get stuck in dpkg:
| +10:10:34 (netscript.grml:311): ensure_packages_installed(): DEBIAN_FRONTEND=noninteractive
| +10:10:34 (netscript.grml:311): ensure_packages_installed(): apt-get -o dir::cache=/tmp/ngcp-deployment-ensure-tmp.BKSocMV4KB/cachedir -o dir::state=/tmp/ngcp-deployment-ensure-tmp.BKSocMV4KB/statedir -o dir::etc=/tmp/ngcp-deployment-ensure-tmp.BKSocMV4KB/etc -o dir::e
| tc::trustedparts=/etc/apt/trusted.gpg.d/ -y --no-install-recommends install jq
| Reading package lists...
| Building dependency tree...
| The following additional packages will be installed:
| [...]
| Get:33 https://debian.sipwise.com/debian trixie/main amd64 libnss-myhostname amd64 257.5-2 [113 kB]
| Preconfiguring packages ...
| Fetched 25.3 MB in 4s (6777 kB/s)
| (Reading database ... 32224 files and directories currently installed.)
| Preparing to unpack .../base-files_13.7_amd64.deb ...
| Unpacking base-files (13.7) over (12.4+deb12u10) ...
| Setting up base-files (13.7) ...
| Installing new version of config file /etc/debian_version ...
|
| Configuration file '/etc/issue'
| ==> Modified (by you or by a script) since installation.
| ==> Package distributor has shipped an updated version.
| What would you like to do about it ? Your options are:
| Y or I : install the package maintainer's version
| N or O : keep your currently-installed version
| D : show the differences between the versions
| Z : start a shell to examine the situation
| The default action is to keep your current version.
|
| *** issue (Y/I/N/O/D/Z) [default=N] ? #
Avoid this, by setting DPKG option `--force-confnew`.
Change-Id: Ic5fed3dbe4744e07290159cec6952468c0557c29
vboxadd-service.service fails on our Debian/trixie systems:
| root@spce:~# lsb_release -c
| Codename: trixie
|
| root@spce:~# systemctl --failed
| UNIT LOAD ACTIVE SUB DESCRIPTION
| ● vboxadd-service.service loaded failed failed VirtualBox Guest Additions Services Daemon
|
| Legend: LOAD → Reflects whether the unit definition was properly loaded.
| ACTIVE → The high-level unit activation state, i.e. generalization of SUB.
| SUB → The low-level unit activation state, values depend on unit type.
|
| 1 loaded units listed.
|
| root@spce:~# sudo systemctl status vboxadd-service.service
| × vboxadd-service.service - VirtualBox Guest Additions Services Daemon
| Loaded: loaded (/etc/systemd/system/vboxadd-service.service; disabled; preset: disabled)
| Drop-In: /etc/systemd/system/vboxadd-service.service.d
| └─override.conf
| Active: failed (Result: exit-code) since Thu 2025-04-24 09:08:15 CEST; 34min ago
| Invocation: 4e151a29f0054a90a717a928fcfb3f8d
| Mem peak: 2.2M
| CPU: 17ms
|
| Apr 24 09:08:15 spce systemd[1]: Starting vboxadd-service.service...
| Apr 24 09:08:15 spce vboxadd-service[1934]: vboxadd-service.sh: Starting VirtualBox Guest Addition service.
| Apr 24 09:08:15 spce vboxadd-service.sh[1937]: Starting VirtualBox Guest Addition service.
| Apr 24 09:08:15 spce vboxadd-service[1940]: VBoxService: error: VbglR3Init failed with rc=VERR_FILE_NOT_FOUND
| Apr 24 09:08:15 spce vboxadd-service.sh[1943]: VirtualBox Guest Addition service started.
| Apr 24 09:08:15 spce systemd[1]: vboxadd-service.service: Control process exited, code=exited, status=1/FAILURE
| Apr 24 09:08:15 spce systemd[1]: vboxadd-service.service: Failed with result 'exit-code'.
| Apr 24 09:08:15 spce systemd[1]: Failed to start vboxadd-service.service.
|
| root@spce:~# cat /etc/systemd/system/vboxadd.service.d/override.conf
| [Unit]
| ConditionVirtualization=oracle
|
| root@spce:~# cat /var/log/vboxadd-setup.log
| Building the main Guest Additions 7.0.6 module for kernel 6.12.22-amd64.
| Error building the module. Build output follows.
| make V=1 CONFIG_MODULE_SIG= CONFIG_MODULE_SIG_ALL= -C /lib/modules/6.12.22-amd64/build M=/tmp/vbox.0 SRCROOT=/tmp/vbox.0 -j2 modules
| make[1]: warning: -j2 forced in submake: resetting jobserver mode.
| [...]
| [,,,] /tmp/vbox.0/VBoxGuest-common.c
| /tmp/vbox.0/VBoxGuest-linux.c:196:21: error: ‘no_llseek’ undeclared here (not in a function); did you mean ‘noop_llseek’?
| 196 | llseek: no_llseek,
| | ^~~~~~~~~
| | noop_llseek
| /tmp/vbox.0/VBoxGuest-linux.c: In function ‘vgdrvLinuxParamLogGrpSet’:
| /tmp/vbox.0/VBoxGuest-linux.c:1364:9: error: implicit declaration of function ‘strlcpy’; did you mean ‘strncpy’? [-Wimplicit-function-declaration]
| 1364 | strlcpy(&g_szLogGrp[0], pszValue, sizeof(g_szLogGrp));
| | ^~~~~~~
| | strncpy
| make[2]: *** [/usr/src/linux-headers-6.12.22-common/scripts/Makefile.build:234: /tmp/vbox.0/VBoxGuest-linux.o] Error 1
| make[2]: *** Waiting for unfinished jobs....
| [...]
We get virtualbox-guest-additions-iso v7.0.6-1 for Debian
stable/bookworm, but virtualbox-guest-additions-iso v7.0.20-1 is
available in current Debian testing AKA trixie. Ensure we use the
package from trixie for trixie based systems, even though the the
VirtualBox Guest Additions v7.0.20 don't work for kernel 6.12.22 either,
yet.
Also adjust ensure_packages_installed to fail installation, if we're
using a yet unknown/unexpected Debian release, to not fall back to
Debian/bookworm, to prevent issue like it has been observed here.
See MT#60815 for main tracking issue WRT Debian/trixie
Change-Id: I030525d37edbe1cf75065d021b51d38273ce81ef
As reported when sending new deployment-iso reviews,
triggered by newer docker image / shellcheck:
| not ok 1 source/templates/scripts/includes/deployment.sh:1543:10: warning: Quote to prevent word splitting/globbing, or split robustly with mapfile or read -a. [SC2206]
| not ok 2 source/templates/scripts/includes/deployment.sh:1903:22: warning: Prefer mapfile or read -a to split command output (or quote to avoid splitting). [SC2207]
| not ok 3 source/templates/scripts/includes/deployment.sh:2275:20: warning: Prefer mapfile or read -a to split command output (or quote to avoid splitting). [SC2207]
| not ok 4 source/templates/scripts/includes/deployment.sh:2486:12: note: Not following: ./etc/profile.d/puppet-agent.sh was not specified as input (see shellcheck -x). [SC1091]
Let's take this as a chance to properly parse ip(8) output via its JSON
output, instead of awk/sed magic.
Change-Id: I723959626fb514ab9e57202b0e5f415b411f5a01
We have made these services conditional on running inside a VirtualBox
VM, so we do not need to remove them anymore.
Change-Id: I6dc563688ba5b0c5e935b0cb88767fcb05ab9a19
On Debian/trixie we get a failing efi.mount systemd unit:
| root@sp1:~# systemctl --failed
| UNIT LOAD ACTIVE SUB DESCRIPTION
| ● efi.mount loaded failed failed EFI System Partition Automount
|
| Legend: LOAD → Reflects whether the unit definition was properly loaded.
| ACTIVE → The high-level unit activation state, i.e. generalization of SUB.
| SUB → The low-level unit activation state, values depend on unit type.
|
| 1 loaded units listed.
|
| root@sp1:~# systemctl status efi.mount
| × efi.mount - EFI System Partition Automount
| Loaded: loaded (/run/systemd/generator.late/efi.mount; generated)
| Active: failed (Result: exit-code) since Fri 2024-11-15 17:20:59 CET; 28min ago
| Invocation: 62c7b659dfd540e294f4b1f6fcda5e13
| TriggeredBy: ● efi.automount
| Where: /efi
| What: /dev/disk/by-diskseq/9-part2
| Docs: man:systemd-gpt-auto-generator(8)
| Mem peak: 1.5M
| CPU: 8ms
|
| Nov 15 17:20:59 sp1 systemd[1]: Mounting efi.mount - EFI System Partition Automount...
| Nov 15 17:20:59 sp1 mount[631]: mount: /efi: wrong fs type, bad option, bad superblock on /dev/sda2, missing codepage or helper program, or other error.
| Nov 15 17:20:59 sp1 mount[631]: dmesg(1) may have more information after failed mount system call.
| Nov 15 17:20:59 sp1 systemd[1]: efi.mount: Mount process exited, code=exited, status=32/n/a
| Nov 15 17:20:59 sp1 systemd[1]: efi.mount: Failed with result 'exit-code'.
| Nov 15 17:20:59 sp1 systemd[1]: Failed to mount efi.mount - EFI System Partition Automount.
|
| root@sp1:~# ls -la /efi
| ls: cannot open directory '/efi': No such device
|
| root@sp1:~# ls -la /dev/disk/by-diskseq/9-part2
| lrwxrwxrwx 1 root root 10 Nov 15 17:20 /dev/disk/by-diskseq/9-part2 -> ../../sda2
|
| root@sp1:~# blkid /dev/sda2
| /dev/sda2: PARTLABEL="EFI System" PARTUUID="fa67b52e-c018-401d-ac71-fad324cad193"
The efi.mount systemd unit is automatically generated by
systemd-gpt-auto-generator. Quoting from systemd-gpt-auto-generator(8):
| The ESP is mounted to /boot/ if that directory exists and is not used
| for XBOOTLDR, and otherwise to /efi/
This got introduced as of systemd v254, see
6a488fa7cc
for details. Now having systemd v256.7-3 in current Debian/testing AKA
trixie, we need to make sure to not present an EFI partition if we
actually don't use it.
So when we don't run in an EFI environment do not mark the second
partition as EFI one.
Change-Id: I546c77fce862a41594500a33da1178c5c6182a1a
Michael Prokop
Sipwise Jenkins Builder
Jose Su
Guillem Jover
Mykola Malkov