BlueBuild images with Dank Linux. Only Hyprland available for now.
DankBlue is heavily inspired by wayblue and aims to be pretty much like wayblue if it had Dank Linux.
Important
A good chunk of the QoL features development was AI-assisted since I only had surface-level knowledge of Bash and knew nothing about Systemd units. Once I learned enough from the back-and-forth with ChatGPT, I manually debugged the scripts and wrote the post-login-setup add-on scripts myself.
- Provide pre-built ISOs via SourceForge.
- Convert the Hypland config to Lua once Dank Linux supports it.
- Use Flatpak Preinstall once BlueBuild's Flatpak module supports it.
I added this because I thought it would be a hassle to manually create and edit the needed dotfiles after rebasing. Although BlueBuild has a
chezmoimodule, I thought using it just to initialize some default configurations was overkill.
This script will run only once on boot to initialize Dank Linux's defaults for existing users in an effort to reduce post-rebase tinkering. The script does this by copying the contents of /etc/skel to the existing user directories. Existing config files will be backed up to the same directories for easy recovery.
For a new user from a fresh install or that was manually added, the nature of /etc/skel will automatically initialize the contents of their home directory.
To let skel-init run again, delete the run.completed file in /var/lib/dank-bluebuild/skel-init/ and then reboot.
Drop-ins for BlueBuild's Flatpak Setup Services
Aside from me not liking the enabled-by-default auto-reinstallation of default flatpaks and having to manually disable it, the reliance on the timers confuses me. I probably should've asked more about why that is before deciding to disable and replace them on a whim.
BlueBuild's Flatpak setup services are what installs the flatpaks declared in the default-flatpaks module. However, the services for the system and user Flatpak setups are always started by their timers after boot and log-in respectively, and thus will install the declared flatpaks again, meaning any of the default flatpaks that were uninstalled will be reinstalled again (like annoying bloatware you just can't get rid of).
These drop-ins solve that problem by making the Flatpak setup services run only once ever for their respective scopes, ensuring that no auto-reinstallation will happen and that the default flatpaks can actually be uninstalled if the user wished to.
The drop-ins make the services not rely on the timers anymore, but I don't know if that actually changes something for the better.
The drop-in for the user Flatpak setup service, in particular, will only let the setup start after Dank Material Shell is active because the setup needs to be able to send notifications or else it will fail and not install the default user flatpaks at all.
To reinstall the default user flatpaks, run bluebuild-flatpak-manager apply [system|user|all] in the terminal.
This is a framework that will run a bunch of setup scripts for the user automatically after logging in.
The only setup script included in DankBlue is sync-dankgreeter which syncs your user theme to DankGreeter using dms greeter sync. However, you can add your own scripts in .../post-login-setup/script.d/.
Additionally, the setup scripts are symlinked to the PATH, so they can be individually started if you wish to.
Note
Scripts to disable the Flatpak setups and skel-init services used to be part of post-login-setup, but I eventually thought that letting them disable themselves with Systemd's own directives was cleaner. Let me know if explicitly disabling them in post-login-setup is better.
Important
The only available tag is latest.
| Image | Recipe |
|---|---|
hyprland |
recipe-hyprland.yml |
hyprland-minimal |
recipe-hyprland-minimal.yml |
All images include core-modules.yml, which adds Dank Linux and the DankBlue QoL features.
Window manager-specific images include the module for their respective WM alongside the core module.
Non-minimal images also include common-modules.yml on top of the core and window manager modules, which adds a bunch of GUI apps and useful utilities for an OOTB experience.
Warning
BlueBuild: This is an experimental feature, try at your own discretion.
To rebase an existing atomic Fedora installation to a DankBlue image:
First rebase to the unsigned image, to get the proper signing keys and policies installed:
rpm-ostree rebase ostree-unverified-registry:ghcr.io/dank-blue/$IMAGE_NAME:latestReboot to complete the rebase:
systemctl rebootThen rebase to the signed image, like so:
rpm-ostree rebase ostree-image-signed:docker://ghcr.io/dank-blue/$IMAGE_NAME:latestReboot again to complete the installation
systemctl rebootFor example, rebasing to the latest DankBlue Hyprland build:
rpm-ostree rebase ostree-unverified-registry:ghcr.io/dank-blue/hyprland:latest
systemctl reboot
rpm-ostree rebase ostree-image-signed:docker://ghcr.io/dank-blue/hyprland:latest
systemctl rebootImportant
Make sure you have the BlueBuild CLI tool installed.
Note
On Windows, I installed the BlueBuild CLI tool using its GitHub install script on a Docker-integrated WSL 2 instance. Maybe you could try this for yourself.
To install a DankBlue image from an ISO, you must first run the following command to build an ISO:
sudo bluebuild generate-iso --iso-name $IMAGE_NAME.iso image ghcr.io/dank-blue/$IMAGE_NAME:latestThen you can flash the ISO using Fedora Media Writer.
These images are signed with Sigstore's cosign. You can verify the signature by downloading the cosign.pub file from this repository and running the following command:
cosign verify --key cosign.pub ghcr.io/dank-blue/$IMAGE_NAME:latestIt is recommended that you set up a new repository based on blue-build/template and use a DankBlue image as the base for your recipe. This is so you can add your customizations on top of DankBlue instead of directly configuring it, such that you only need to maintain your own customizations and not constantly update your repository to sync with DankBlue's.
Check out my personal images repository to see how I built my own custom image on top of DankBlue.
xdg-terminal-exec is used to set Ghostty as the "fallback terminal emulator", so DankBlue recommends not removing Ghostty from your recipe. Instead, add your preferred terminal emulator to your recipe and set it as the default.
To set a default terminal emulator, please create xdg-terminals.list in /etc/skel/.config/ or ~/.config/ and write to it the name of your preferred terminal emulator's .desktop file.
If you really want to get rid of Ghostty, then make sure to edit /etc/xdg/xdg-terminal-exec/xdg-terminals.list accordingly.
You can add your own setup scripts in /usr/libexec/dank-bluebuild/post-login-setup/script.d/ for your own convenience after installation or rebase.
DankBlue recommends following the format below for consistency and compatibility, but you may deviate from it or do your own thing entirely because post-login-setup really just runs the scripts for you and nothing more.
#!/usr/bin/env bash
set -euo pipefail
on_interrupt() {
trap - INT TERM
echo "Script interrupted." >&2
exit 130
}
trap on_interrupt INT TERM
# This ensures that the username and user directory are always read whether you run the script in sudo or not.
if [ "$EUID" -ne 0 ]; then
SCRIPT_USER="$USER"
SCRIPT_HOME="$HOME"
else
SCRIPT_USER="$SUDO_USER"
SCRIPT_HOME="$SUDO_HOME"
fi
ACTUAL_SCRIPT_NAME=$(basename "$0")
CLEANED_SCRIPT_NAME="${ACTUAL_SCRIPT_NAME#[0-9]*-}"
SCRIPT_STATE="/var/lib/dank-bluebuild/post-login-setup/script.d/$CLEANED_SCRIPT_NAME.completed"
SCRIPT_HOME_STATE="$SCRIPT_HOME/.local/state/dank-bluebuild/post-login-setup/script.d/$CLEANED_SCRIPT_NAME.completed"
# This, along with the code at the end, ensure that the script will not run again after a successful execution.
if [ -f "$SCRIPT_STATE" ] || [ -f "$SCRIPT_HOME_STATE" ]; then
echo "Script '$CLEANED_SCRIPT_NAME' already completed."
exit 0
fi
echo "Executing command..."
if ! sudo -u "$SCRIPT_USER" command; then # DankBlue recommends using `sudo -u <username> <command>` to ensure that commands do not need sudo will always run normally. If you do need sudo, then simply use `sudo <command>` instead.
echo "Failed to execute command." >&2
exit 1
fi
echo "Successfully executed command."
mkdir -p "$(dirname "$SCRIPT_HOME_STATE")"
touch "$SCRIPT_HOME_STATE"
exit 0
Simply disable skel-init.service and create the file /etc/dank-bluebuild/post-login-setup/auto.disabled in your own recipe via BlueBuild's systemd and script modules respectively. You can also add said file directly into your repository's files/ directory.
modules:
- type: script
snippets:
- "mkdir -p /etc/dank-bluebuild/post-login-setup && touch /etc/dank-bluebuild/post-login-setup/auto.disabled"
- type: systemd
system:
disabled:
- skel-init.service
As for the Flatpak Setup service drop-ins, you can simply disable the services and re-enable the timers. To be extra sure, you can also delete the drop-ins.
modules:
- type: script
snippets:
- "rm -r /etc/systemd/system/system-flatpak-setup.service.d" # Optional
- "rm -r /etc/systemd/user/user-flatpak-setup.service.d" # Optional
- type: systemd
system:
enabled:
- system-flatpak-setup.timer
disabled:
- system-flatpak-setup.service
user:
enabled:
- user-flatpak-setup.timer
disabled:
- user-flatpak-setup.service
Instead of creating your own hyprland.conf with your preferences, DankBlue recommends putting your own Hyprland configs in /etc/skel/.config/hypr/user/ or ~/.config/hypr/user/. The default hyprland.conf that comes with DankBlue's Hyprland images sources ./user/* at the very end of the file so that your configs take precedence over the default config and the DMS overrides. This is to separate your own configs from the base default config such that whatever breaks in the base config is DankBlue's to fix, and whatever breaks in your configs is yours to fix.