The package might come back in Debian, or we might bring it back in Kali
(if there is demand for it). However, the discussion at
https://bugs.debian.org/1109025 suggests that the firmware blobs are not
redistributable.
Not sure why there was no info messsages at all in this script, I'm
adding it now to reduce the diff with kali-finish-install, hopefully I'm
not breaking anything by using stdout for informative messages...
Doesn't change anything to the build. It's just that it's easier to spot
scripts when looking at the git repo with eg. `tree`: executable files
are highlighted.
The variants were renamed in 530b22106b,
breaking scripts that used the old name (like, our own build infra that
uses `--variant everything`, for example).
This commit adds compat symlinks so that things keep working.
This is necessary in case more than one terminal is installed, and they
both have the same alternative priority.
For example, while installing all packages at once, sometimes apt will
resolve a dependency "x-terminal-emulator" to one of the many packages
that provide it, for example "zutty". And then it will also install the
terminal listed in the "kali-desktop-${desktop}" metapackage that is
selected, eg. "qterminal" for "kali-desktop-xfce".
Both zutty and qterminal have a alternative priority of 40 at the
moment, so if zutty gets unpacked first, it will have precendence and be
the default terminal.
It's a long-standing issue. By the past, We tried to make sure that the
default desktop terminal is installed first, by listing it early in the
dependencies of the "kali-desktop-{desktop}" metapackage, and it kind of
works with the debian-installer, but it was hard to make it work (we had
to do some changes in tasksel), and it's still brittle as it relies on
apt's dependency solving, which is apt's internal sauce and might change
(hint, apt will get a new solver soon, cf [1]).
As it turns out, it doesn't work for the live iso, somehow we still get
zutty taking precedence over qterminal, I didn't check why, it probably
has to do with how live-build constructs the apt command-line in order
to install everything.
In any case: I think our approach so far didn't work, so with this
commit, we take another approach: we set the default terminal from the
finish-install script, for both the installer iso and the live iso. That
should solve the issue for good.
[1]: https://blog.jak-linux.org/2024/05/14/solver3/
No need to explicitly list kali-themes in the packages to install, it's
pulled in anyway via the following dependency chain: kali-desktop-i3 ->
kali-desktop-core -> kali-themes
I removed the pulseaudio hook. I really don't see a reason to start
pulseaudio once, during the build process, as root. Plus, the second
line of the hook (rm -rf .pulse-cookieaa) has no effect, since there's
no file named .pulse-cookieaa. I added some debug logs to the hook to
confirm that.
usr-is-merged is included in simple-cdd offline.downloads's since
version 0.6.9. Not sure why I needed to list it in installer-netinst as
well at the time, but after testing, I can confirm it's not needed
anymore.
This reverts commit 7bb52e4991.
I wanted to make sure firmware are included in the installer image, but
I missed it, I modified a config file that is only for live images, it
seems...
Also, note that the previous commit message
Kali purple: install kali-system-gui (instead of core)
Should have been:
Kali purple: include kali-system-gui (instead of core) in the installer
Because this commit is really about having the package available in the
installer, but it doesn't "install it" on the system. Sorry for the
confusion.
The dep chain is kali-system-gui > kali-system-cli > kali-system-core.
kali-system-cli contains wget and curl, which we probably want to have,
and will fix https://gitlab.com/kalilinux/kali-purple/documentation/-/issues/9
I'm not sure about kali-system-gui, but I have the impression that it
was the intention to install it in Kali Purple, but at some point it was
forgotten and we install kali-system-core instead.
Even though it's currently empty, we want users to have this component
enabled so that they don't miss on updates when we start to move
packages from non-free to non-free-firmware.
Other things that I tried, but that didn't work, below:
I tried adding the preseed to simple-cdd/profiles/kali-purple.preseed,
however that didn't work, I guess that this preseed file is loaded only
later during installation, and that at this point the GUI was already
loaded and it's too late to set the theme.
I also tried to do this in simple-cdd.conf:
# Theming
if echo " $profiles " | grep -q " kali-purple "; then
export KERNEL_PARAMS="${KERNEL_PARAMS} debian-installer/theme=Clearlooks-Purple "
fi
But it doesn't work, seemingly 'profiles' is not set when simple-cdd
loads the conf, and even though we build with the command:
build-simple-cdd [...] --profiles "$profiles" [...]
Given the fact that uppercase variables are exported, and what we
actually want to change is KERNEL_PARAMS, it seems that the most
straightforward is just to preset it from build.sh.
build.sh:
Note that the installer-purple variant does NOT include the offline
profile, that's on purpose. There's no requirement for this installer to
work offline, and on top of that, we can't include all the packages in
the iso at the moment (the package exploitdb-papers is too big). So we
very much expect to have network, and to download big packages during
the installation.
See next commits for more details.
kali-config/installer-purple/packages:
Unlike other variants, the "base" metapackage is kali-system-core,
which is a very stripped down metapackage with no offensive tools.
(kali-system-core is basically what used to be kali-linux-core, minus
the few offensive tools that were in there).
Arnaud Rebillout
Daniel Ruiz de Alegría
g0t mi1k
Arszilla
Ben Wilson
Raphaël Hertzog