grub-pc >=2.04-11 has a new behavior regarding /boot/grub/i386-pc/
handling, where we end up with an empty /boot/grub/i386-pc/ after
*successful* grub-install execution:
| root@grml ~ # vgchange -ay
| 3 logical volume(s) in volume group "ngcp" now active
| root@grml ~ # mount /dev/mapper/ngcp-root /mnt
| root@grml ~ # grml-chroot /mnt /bin/bash
| Writing /etc/debian_chroot ...
| (spce)root@grml:/# cd
| (spce)root@grml:~# grub-install /dev/sda
| Installing for i386-pc platform.
| Installation finished. No error reported.
| (spce)root@grml:~# ls -la /boot/grub/i386-pc/
| total 16
| drwxr-xr-x 2 root root 12288 Dec 16 12:04 .
| drwxr-xr-x 4 root root 4096 Dec 16 12:07 ..
This causes the installed system to fail to boot with:
| GRUB loading..
| Welcome to GRUB!
|
| error: file `/boot/grub/i386-pc/normal.mod' not found.
| grub rescue> _
The underlying issue is that recent grub versions unlink the files
inside /boot/grub/i386-pc, though it doesn't report anything about it
(even under `--verbose` execution).
This is triggered in our situation, as lvm2's vgs binary isn't present
yet. In earlier versions of grub this wasn't causing any problems and
grub-install happily installed the files inside /boot/grub/i386-pc, even
though we installed lvm2 only afterwards via our metapackages. To
ensure lvm2 is available during installation time within
grml-debootstrap, explicitly add to it list of packages to be installed.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977544 for further
details regarding the grub bug.
Change-Id: I27a1cd18777526eb26b838fae88d4d87b6e93467
(cherry picked from commit 91e047a486)
This is revert of commit aadbef82b0
The version 0.18.1 fails during the building of mr8.5.1:
===============================
10:59:57 Executing grml2usb version v0.18.1 (git)
10:59:57 Checking for boot flag
10:59:57 Fatal: /tmp/grml2iso.tmp/cddir: unrecognised disk label
===============================
So restore working 0.17.0 version.
Change-Id: Ib5b3369152378dc3aeb7282d098383c5df82904d
(cherry picked from commit 9fbc9afeda)
This variable is required to locate check-for-network script.
Change-Id: I7b5792acab6134a47cdbea6793065d674e47a67f
(cherry picked from commit 73327b10f0)
The /usr/bin/python symlink/binary no longer exists in recent
Grml-Sipwise ISOs and python3 doesn't ship SimpleHTTPServer but
http.server instead.
Change-Id: I6677e8a416b142034d99d5b1d2b11ba74d87a6ec
(cherry picked from commit 862fb155f0)
No need to install this package to non-vagrant system.
Do not add this package to Sipwise-grml image - it's too heavy (86M)
and not needed on real systems.
Change-Id: I9ec9ff76d588f4ced30ba199f05bb167eec5288a
Previously the functions and the code were fixed so it was hard to
understand the flow of execution.
Move all functions to a single section at the beginning of the script
so it's easier to understand the code.
Fix shellcheck warnings:
SC2086: Double quote to prevent globbing and word splitting.
SC2154: efidev1 is referenced but not assigned.
Change-Id: Ie4bf28c166e4a9ff236eff807ee97adae6ecddd0
This variable is used in some ngcpcfg *.services file.
Specifically 'ngcp-provisioning-tools/mysql_values.cfg.services' uses
this variable to specify mysql db host and if it's necessary to reload
kamailio.
Change-Id: Ibf137cdd0ad6f6492a30cfa715c468e4ac22832f
Initially wanted to sync with https://github.com/grml/grml-network/ as
of commit 49409a5587d, though templates/scripts/includes/netcardconfig
existed only to provide the VLAN patch until we had this available from
upstream and our own ISO. Now that everything has been upstreamed and we
have up2date Grml ISOs, let's switch to the one included in upstream
Grml.
Change-Id: I685cd0ad95033ad2b50036e53c2ee9814a776e63
Otherwise execution of FAI might fail:
| Calling task_faiend
| /usr/lib/fai/subroutines: line 142: ps: command not found
| [...]
This is supposed to be fixed with FAI 5.9.4, while
version 5.8.4 suffers from this bug, so until >=5.9.4
is available in buster/stable let's fix this via an
explicit dependency.
Change-Id: I99490f263d1b2a1aec65f55feebe429b62628918
We no longer support linux-image-amd64-grml, so there's
no point in sitting at kernel version 4.19.0-1-grml-amd64,
instead switch to the plain Debian kernel.
Change-Id: I00efa274acf9724241762ef43a15ecec61e2a409
This grml2usb version is supposed to be used for releasing
the upcoming Grml stable release and its related release candidate.
Change-Id: I172cabb02d245794856f2101990e5a445325f7c2
grml-live v0.35.3 is the current release, planned to be the
base for the upcoming new Grml stable release and its release candidate.
Change-Id: Ia5916250975b90f8d5f75d6fd1aefa5a9bd17d4c
Instead of having to maintain this ISO in our web server off-band,
we switch to use the packaged version, which makes validation
unnecessary as apt gives us that. And it also gives us a newer
version (currently 6.0.4 with Debian buster 10.3 vs the old 5.2.26).
Change-Id: Id89280bbe7fadeb35d391b5dc46e930935017588
grml2usb <=0.14.14 works when building with ISO grml64-small_2018.04.11-efi.
Newer grml2usb versions provide SecureBoot support (which was introduced in
grml2usb v0.16.0). This is failing with our grml64-small_2018.04.11-efi ISO
though, because its provided EFI image doesn't contain a valid/mountable FAT
file system:
| % file /tmp/grml2iso.tmp/grml2usb55ey_q68/boot/efi.img
| /tmp/grml2iso.tmp/grml2usb55ey_q68/boot/efi.img: PE32+ executable (EFI application) x86-64 (stripped to external PDB), for MS Windows
Whereas the efi file from more recent Grml(-Sipwise) ISOs like
https://deb.sipwise.com/deployment-iso/grml/grml-sipwise-buster-20191022_addons.iso
looks like this:
| % file /mnt/test1/boot/efi.img
| /mnt/test1/boot/efi.img: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "mkfs.fat", sectors/cluster 4, root entries 512, sectors 8192 (volumes <=32 MB) , Media descriptor 0xf8, sectors/FAT 6, sectors/track 32, heads 64, serial number 0xef681600, label: "GRML ", FAT (12 bit)
and can be properly mounted for further adjusting by grml2usb/grml2iso.
So use grml2usb version v0.17.0 except when handling ISO
grml64-small_2018.04.11-efi ISO, then we use the version we had available on
our Debian/stretch environments back then, AKA grml2usb v0.14.14.
Change-Id: I452d7cbac138d59dc11fb1773ca3d6f6c307a6df
From the packages' deps and content POV Pro and Carrier packages are
equal to each other so get rid of this separation.
Change-Id: I587dba3147bdc9b3c0f10da820ba4cdc8a0a0f08
Newer gcc versions have become more picky on their argument order, due
to the --as-needed default, and require the libraries to be linked to,
to be passed after the code/objects that use them, otherwise they will
get dropped as unused.
Change-Id: I8ace79186b0c8709ccb9cb93f51a9890ce6e1043
* 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
This reverts commit ee2398b6f8.
We've removed mcollective from our infrastructure and ready to update
puppet to the latest available version.
Change-Id: I7a860be9e051ed09bd69c165aaafc2acd1f17cd8
In the past we were associating them by MAC address and only in some cases, like
Pro/Carrier and in Virtual Machine environments.
However, it's beneficial to have this in other scenarios, so we will create udev
rules to pin them down during deployment.
Change-Id: Ic1b397e81af673b974961158a0e9a05ce5b80a69
In mr7.5+ bootstrap gpg keyring is named sipwise-keyring-bootstrap.gpg
so add appropriate directory.
Change-Id: I633deac1ffb203e7d566e5262e0dff35354aa2e5
This file contains the following public keys:
68A702B1FD8E422AAAA1ADA3773236EFF411A836 - jessie, stretch, buster
debian repos, mr3.8-mr8.4 public repos.
F7B8A739CE638D719A078C9859104633EE5E097D - autobuild repos.
8A61E3C73B6987020226079D69D9C21F6D9B587E - new key for mr7.5+.
This very file will be used only for bootstrap purposes and will be
dropped in the end of installer.
Change-Id: I60a903b4b05ab8a0d1a6498773802f756f8e4202
Initially dirmngr package was installed to allow running apt-key inside
deployment.sh to install puppetlabs key. Then after moving puppetlabs
key to local file package installation was removed. But we still need it
for successful first puppet run that also uses apt-key. Otherwise there
is the error: 'Could not find a suitable provider for apt_key'. Puppet
also installs dirmngr package but in such case only the second puppet run
will be successful so we need to install the package before the very
first puppet run.
Change-Id: I28edbd8c91c841074ac1b3f1eb6df16e14daa084
In deployment.sh line 2109:
local puppet_gpg='/root/puppet.gpg'
^-- SC2168: 'local' is only valid in functions.
Change-Id: I628cbac844db6aa1913ab1747906656d7d6d739b
The puppet.gpg is located in Grml-sipwise so no need to download the
hard-coded key but use the local one.
Change-Id: Id57180de96efef4a5a13086e7807c615bd65b886
Sipwise Jenkins Builder
Michael Prokop
Mykola Malkov
Guillem Jover
Sergii Kipot
Manuel Montecelo
Alexander Lutay