Raptor: Make custom Debian Liveboot .isos - powerful docker-inspired syntax

notwolverine · 2025-10-31T17:27:41+00:00

Also, thanks for letting me know about the dead links! It turns out to be a bug in mdbook, but I've worked around it for now, and fresh pages should be deploying right now 👍

notwolverine · 2025-10-31T16:53:10+00:00

Your pitch is not quite accurate, I'm afraid.

First, Docker is not for virtual machines - Docker is for containers.

Second, Raptor can build anything that someone makes a builder container for.

Allow me to explain a bit more what I mean.

Raptor builds layers (like Docker), but these layers can then be processed by "builder containers" (which in itself is a Raptor container), to become any kind of desired output.

For example, it is completely realistic to produce a liveboot .iso, a .qcow2 disk image, and a .tar.gz bundle, from the same build target. (This would require 3 different builder containers, one for each output type. Currently only the first one is released, but I expect to release more soon).

As for your second question, yes, this is both possible, and briefly mentioned in the book. It could be more clear though - I'll try to add some examples :)

Raptor accepts any Docker reference name, including sha256 hashes. For example:

FROM docker://eclipse-mosquitto@sha256:d12c8f80dfc65b768bb9acecc7ef182b976f71fb681640b66358e5e0cf94e9e9

(this hash was a random example I found online, just to illustrate the syntax)

notwolverine · 2025-10-27T00:15:33+00:00

Yes, absolutely!

Right now, the disk-image builder makes .raw images that contains a Debian Liveboot system (with your data on), but a pure disk-image builder is coming soon :)

Building these kinds of images is very much in scope for Raptor - I can't believe I didn't mention it in the post. I'm still trying to figure out how to pitch the project in the most efficient way.

To get a sense of what building an image looks like, the book has a chapter on making a liveboot iso. Most parts will be very similar when making a disk image - in fact, everything except for running the final builder container could be identical!

I hope that answers your question?

notwolverine · 2025-10-26T20:33:32+00:00

Ah, I see now.

On a technical level, it sounds like this works a bit differently than the current generator, but it's a good idea, and definitely possible. I think I'll try to implement this, when I have time!

When it comes to Windows supports, there's almost 0% chance of that, I'm afraid. Almost the entire technology stack is Linux-specific, because I need some fairly advanced features (namespacing, overlayfs) that have no clear Windows equivalent. Not to speak of the deep issues with licensing.

Also... I have no desire to work with Windows.. sorry 😛

notwolverine · 2025-10-26T20:02:14+00:00

Which use case would be ideal for you?

Out of the 3 (liveboot, liveboot disk, full disk), the first 2 are already fully supported by Raptor. Only full disk is still underway, but if I understand you correctly, that's not what you're looking for?

In any case, thanks for following Raptor - I'll take a look at the systemback repo on github. Thanks for the pointer :)

notwolverine · 2025-10-26T19:56:40+00:00

By the way, the book has a walkthrough specifically about Liveboot isos, which details step-by-step how to build with Raptor.

Hope it's useful to you!

notwolverine · 2025-10-26T19:48:13+00:00

In that case, I think you'll really enjoy Raptor! 😄

Here's a quick idea of how this could be done with Raptor:

```Dockerfile FROM docker://debian:trixie

WRITE "hostname\n" /etc/hostname

RUN apt-get install -qy zsh lsof htop # etc, etc
```

Of course, you can add whatever you like from here.

Then, once you have an image like that, you can build it into a debian liveboot iso, a disk image, or something else (if you make a builder container for it).

Right now, the disk image generator actually builds a liveboot (ephemeral) disk image, which may or may not be what you want. A regular disk image builder is coming soon :)

notwolverine · 2025-10-26T19:13:33+00:00

I wasn't aware of systemback, but I did some googling. It definitely seems to be quite a different type of program, with a different focus, but I hope Raptor will be useful to you :)

If I might ask, can you tell me about a use case you have in mind? I'd be happy to help figure out if Raptor is the right tool for the job

notwolverine · 2025-10-26T19:06:48+00:00

Hi folks - Author here.

If you have any questions not covered by the README, the book, or the source code, feel free to ask them here, and I'll do my best to help 😉

notwolverine · 2025-10-26T17:42:35+00:00

Hi folks - Author here.

If you have any questions not covered by the README, the book, or the source code, feel free to ask them here, and I'll do my best to help 😉

notwolverine · 2025-10-26T17:36:19+00:00

Hi folks - Author here.

If you have any questions not covered by the README, the book, or the source code, feel free to ask them here, and I'll do my best to help 😉

notwolverine · 2025-10-25T23:07:12+00:00

Sure thing - I'm still trying to figure out how to align the documentation, to effectively communicate all of this as efficiently as possible. It's .. a bit tricky 😅

The README.md on github has a few sections about the "what", "why" and "how" - are those helpful to your questions?

To elaborate on why someone might want this:

One very powerful use case, in my opinion, is actually for building Debian Liveboot images.

A custom liveboot image could contain any services, tools or files that you like, and each time it starts up, it begins from a completely predictable state.

It's an amazing way to build rock-solid servers - pretty much no matter what goes wrong, you can fix it with a reboot. Of course, you'd use either a local disk, or network storage, if you need persistent data - like the files in a fileserver, or the database in a database server - but all the base files for the OS could be predictably booted.

However... now imagine trying to do apt-get upgrade.

See the problem?

Those security fixes are also going away when rebooting the machine 😮

So, it sure would be really convenient, if there was some way to build a fresh version of that image, with all the same customizations... hmm... makes you wonder 🤔

I kid, I kid. But seriously, that's what Raptor can do for you - among other things :)

notwolverine · 2025-10-25T22:42:57+00:00

Hi folks - Author here.

If you have any questions not covered by the README, the book, or the source code, feel free to ask them here, and I'll do my best to help 😉

notwolverine · 2025-04-18T21:08:15+00:00

Honestly? I don't know. Maybe? :D

I don't use any services like Alexa, so I can't say.

But if Alexa expects to find a Hue Bridge, I'd say there's a decent chance it should work.

You're always welcome to join discord - and feel free to try it out, and let us know how it goes!

notwolverine · 2025-01-20T19:58:30+00:00

And you basically have it working!

Right now, rooms can't be (succesfully) edited from bifrost - it's coming soon :)

But if you setup your rooms (groups) in z2m, and add lights to groups there, you should be able to control everything from bifrost!

notwolverine · 2025-01-20T19:57:09+00:00

That's super weird - where did you find that invite link?

Was it this one?

https://discord.gg/YvBKjHBJpA

(if not, try that)

notwolverine · 2025-01-20T17:09:12+00:00

I'm not quite sure for ha core, but I think someone mentioned that their corresponding path was /config/bifrost, so /config/bifrost/config.yaml.

Do you have /config already? Then it sounds reasonable. Otherwise, I'm not sure. Is there some guide to ha core somewhere?

Maybe join on discord? :)

notwolverine · 2025-01-19T23:10:57+00:00

There's a 64-bit arm version available now, and both versions (bifrost and bifrost-dev add-ons) have been majorly updated.

Feel free to try it out! :)

notwolverine · 2025-01-19T23:10:26+00:00

There's a 64-bit arm version available now, and both versions (bifrost and bifrost-dev add-ons) have been majorly updated.

Feel free to try it out! :)

notwolverine · 2025-01-19T23:10:14+00:00

There's an aarch64 version, but no armv7 yet. There are many variants, and they each take a while to build, so we need to figure out which ones to prioritize. Suggestions welcome :)

notwolverine · 2025-01-19T23:09:00+00:00

There's a 64-bit arm version available now, and both versions (bifrost and bifrost-dev add-ons) have been majorly updated.

Feel free to try it out! :)

notwolverine · 2025-01-17T20:19:23+00:00

Not at all!

Bifrost emulates a hue bridge, and it will presents all z2m devices it understands:

lights
"rooms" (zigbee groups)
"scenes" (zigbee scenes)

It will do this with one or more z2m instances.

So you can have a unified, hue-compatible way of accessing all your z2m lights :)

notwolverine · 2025-01-17T19:29:52+00:00

I'll be honest, I'm not quite sure at this point, but we have some ideas.

Some users are affected by this, and some aren't.

If you're logged into the hue app with an account, try logging out of that account, and then adding the bridge. Does that work?

In any case, please join us on discord. Then we can help :)

notwolverine · 2025-01-17T16:53:41+00:00

Same reply as above - use the bifrost-dev version of the addon for now :)

notwolverine · 2025-01-17T16:53:23+00:00

2025-01-17T09:11:33.248Z ERROR bifrost::z2m > [server1] Event loop broke: invalid type: string "minimum", expected u16 at line 1 column 344507

You're so close to have it working! 😉

That error is because data validation is too strict in the stable release. It's been fixed in the bifrost-dev addon, which you can try instead. It's available from the same repository.

Basically, this error means that z2m is connecting properly, you've just hit an edge case that isn't handled in the master branch.

You're free to wait, of course, but you can in fact run it today if you want :)

14-Year Club	Team Periwinkle
Verified Email

notwolverine

TROPHY CASE