Knuckle: Flatcar Container Linux for the Home | Bluefin

[giscus[bot]]

Knuckle: Flatcar Container Linux for the Home | Bluefin

{/ truncate /}

https://docs.projectbluefin.io/blog/introducing-knuckle/

[Danathar]

"For me it's the last OS you install on your new server build. Problem solved, I have jellyfin to set up let's go!". Wow! You are gunna make your fellow uCore colleagues really SAD ;) That being said, I LOVE the idea. Having to deal with ignition and Butane is a pain.

[znmeb]

Yeah - I looked at the Ignition - Butane stuff and said, "Yeah - nope!"

[thegreatzach]

I don't understand why Anaconda can't just be used. For a while, that's what Bluefin was using, right? When I think about installing a homelab distro, I only need to do it once.

Why do I need to go through all of the CoreOS Ignition stuff if I just want to install "Bluefin Server" and create a user? Bazzite already supports things like dual-boot configurations, so disk partitioning and custom disk layouts clearly aren't unsolved problems for bootc-based systems.

After messing around with uCore and the ISO creator, it seems entirely possible to create an Anaconda-based installer for these images. All I really want is a straightforward way to install a bootc system from a live ISO and make it easy to rebase between variants later if I decide to switch.

I understand the appeal of Ignition for reproducible deployments and automated provisioning, but what is the benefit of requiring it over a simple Anaconda installer for users who just want a single server? I'm not trying to deploy a cluster of three identical mini PCs. I want one machine that is effortless to install and effortless to keep updated.

[Danathar]

This might be an upstream question for Fedora Core OS. uCore bases what it does on that and there is no installer for Fedora Core.

[thegreatzach]

I understand that Fedora CoreOS doesn't currently ship an installer, and there are open upstream discussions around Anaconda support:

coreos/fedora-coreos-tracker#1646

What I'm still trying to understand is where the actual limitation is.

Bluefin and Bazzite are also image-based bootc systems, and they've provided an Anaconda-based installation in the past. So if a bootc system can be installed through Anaconda in those cases, what specifically prevents a Fedora CoreOS derived system from offering a similar install path?

The more I read, the more I realize my original comment about partitioning was oversimplified. Things like LUKS, RAID, multi-disk roots, and first-boot provisioning are obviously more complicated than just partitioning a drive.

But that's also why I keep coming back to the user experience question. If someone wants a single-node homelab server on a single disk, creates one user, and doesn't need advanced provisioning, could there be a supported installer path for that use case?

I'm not arguing that Ignition doesn't have valid use cases. The article itself says:

Basically for all intents and purposes, uninstallable for enthusiasts. For experienced Kubernetes operators this always-in-pain life is fine, but for homelab users and folks new to container-native Linux, it's annoying.

If the goal is to make these systems more approachable for homelab users and people getting into self-hosting, I'm not convinced that introducing an entirely different installation paradigm is the right answer.

The article also says:

It would be madness to create our own installer, so Knuckle just translates that stuff into something the Flatcar installer understands and then that's it.

Which is part of why I'm asking the question. If the goal is to simplify installation for enthusiasts and self-hosters, why is a translation layer around Ignition the preferred solution instead of offering a more traditional installer experience for users with simple deployment needs?

Most Linux users understand the basic installer workflow: boot the ISO, pick a disk, create a user, reboot. They may never need to think about provisioning systems, machine configs, or first-boot configuration files.

[castrojo]

Which is part of why I'm asking the question. If the goal is to simplify installation for enthusiasts and self-hosters, why is a translation layer around Ignition the preferred solution instead of offering a more traditional installer experience for users with simple deployment needs?

This is a traditional installer experience, it's just for flatcar - there's no reason for us to use anaconda at all for this.

But that's also why I keep coming back to the user experience question. If someone wants a single-node homelab server on a single disk, creates one user, and doesn't need advanced provisioning, could there be a supported installer path for that use case?

Yeah this is what this is it's just some text fields for you to fill out, like the ubuntu server installer.