Derivative-Maker | Installing kernel from backports?

[Patrick]

This might work:

–kernel [packages] : Specify kernel packages (e.g., ‘linux-image-amd64’ or ‘none’).
–headers [packages] : Specify kernel header packages.

---

Folder build_sources already comes with Debian backports folder. So no enabling of Debian backports is required.

---

@e-coin

For example, could I replace the following in build-steps.d/2800_create-lb-iso?

Whonix-Host (ISO) does not exist at time of writing. Status and updates are here: Whonix-Host Operating System Live ISO, Whonix-Host Installer

Therefore this option file is irrelevant for Whonix at this time.

@e-coin

sed -i "s/XXX_ARCHITECTURE_XXX/${KERNEL_VER}/" package-lists/z-kicksecure.list.chroot

I don’t like many things about this part of derivative-maker source code.

• ISO specific
• not applicable to other build targets (VMs)
• dynamically created file during the build process
• dynamically written during the build process

But building a bootable (Debian) ISO with GRUB + BIOS + EFI + Secure Boot + dracut + multiple architecture support very difficult. (Development of System Image Creation and Bootstrapping Tools) So we rely on Debian live-build for that.

---

@e-coin

Before:

         if echo $derivative_name_list | grep -q -i Whonix ; then
            [ -n "$sources_list_build_remote_derivative" ] || sources_list_build_remote_derivative="
            deb http://HTTPS///deb.kicksecure.com $codename_build_remote_derivative main contrib non-free
            deb http://HTTPS///deb.whonix.org $codename_build_remote_derivative main contrib non-free
            "
         else
            [ -n "$sources_list_build_remote_derivative" ] || sources_list_build_remote_derivative="
            deb http://HTTPS///deb.kicksecure.com $codename_build_remote_derivative main contrib non-free
            "

Variable sources_list_build_remote_derivative is only relevant in context of Whonix build script now optionally supports installing packages from Whonix remote repository rather than building packages locally. I don’t think it should be re-used for other purposes.

---

To install additional packages, expanding the flavor_meta_packages_to_install variable using Build Variables Changes might be an option.

But maybe that’s a bit inconvenient. If other custom, non-kernel/header packages shall be installable, we could add an additional variable user_custom_packages_to_install.

---

The full path to a complete build sources file can probably be set using variable dist_build_sources_list_primary.

---

Other options: Add your own custom build-step.

---

This amount of features and complexity is difficult to manage. Due to dependency on third-party projects, not something that could be centrally planned and improved.

Related: Linux User Experience versus Commercial Operating Systems

There are a ton of SystemBuildTools - Debian Wiki, but probably none can replace Derivative-Maker - Debian based Linux Bootable Image Builder or are simple to customize. It’s a hard problem to solve.

derivative-maker advanced configuration has very low priority. There are much more important tasks on the Whonix ™ Security Roadmap.