Welcome to Jailmaker 3.0.0

[kuya1284]

👋 Welcome to the new home of Jailmaker, the brilliant tool originally created by @Jip-Hop.

I decided to work on this fork to continue where @Jip-Hop left off. I decided to resume using Jailmaker once I learned that Incus was no longer going to be supported and was planned for removal in TrueNAS 26. I was really hoping that they would improve on Incus because it would provide an easy way to create and manage containers. Sadly, Incus integration with TrueNAS was short-lived.

In any event, my initial goal was to make some improvements to Jailmaker. More specifically, adding support to automatically install the NVIDIA Proprietary driver for anyone in the community running older NVIDIA GPUs. TrueNAS 25.10 (Goldeye) replaced the proprietary driver with the Open Source version in order to provide support for newer NVIDIA GPUs, such as those built on the Blackwell architecture. Unfortunately, not everyone has these newer versions and the Open Source driver only supports GPUs going back to the Turing architecture. GPUs older than that, such as Pascal, Maxwell, etc. are still very capable cards. Jailmaker 2.2.0 made it possible to resume using those older GPUs on TrueNAS 25.10 and newer.

I originally just wanted to add that one enhancement, but one thing led to another. As I got more comfortable with Jailmaker's source code, I found myself wanting to make additional improvements, such as adding cloud-init support. I've added other features, such as the ability to set a custom hostname inside the Jail, and the ability to set a higher timeout so that Jail creation wouldn't abruptly stop after 90 seconds with more advanced and longer running initial_setup scripts. And so here we are... Jailmaker v3.0.0....

I started writing this intro to continue the original How to ask for help? discussion, but I figured I might as well introduce this new fork. I'm hoping to continue maintaining this fork to make additional improvements, as long as time permits. Family and work always comes first, but I think this will be a fun project to work on from time to time, and I'll do my best to work with the community. Now, with that said, let's get back to why I even started writing this to begin with...

How to ask for Help? Should I open an issue or start a discussion?

When in doubt, start a discussion.

How to ask for help? (Original )

1. Before asking for help, first, and foremost, collect as much data about your situation as possible.
   Collecting this information might reveal the issue before you even ask.

2. Do you understand your issue? Do you understand what is breaking?
   If not, open a Q&A Discussion.

3. Make sure you understand that jlmkr is just a convenient interface for systemd-nspawn making a lot of assumptions about the system, because it is designed to run on a very opinionated flavor of Debian - TrueNAS CE.
   This means that you might need to look for help about systemd-nspawn elsewhere first.
   It's ok to ask here for help, but understand that most of us are not systemd-nspawn experts, we're using it just like you intend to do.

4. If you are absolutely sure (maybe as a conclusion from a discussion you opened) that the issue is with the way jlmkr script works, that's when you should open an issue.
   Issues are for bugs and feature requests for the script.

Should I mark the discussion closed? (Original)

Only when the content in it are irrelevant. But mostly, the answer is keep it open.
Closing a disucssion will filter it from the default search. (removing the is:open from the search will search closed discussions as well)

Unlike Issues, which are closed when things are resolved, open discussions mean - relevant disucssison. If you went through a process, and eventually fixed it, the discussion is still relevant.

When will it be irrelevant? Your issue isn't relevant in the newest version of the script. Or you encountered a bug, after that bug is fixed, the issue is no longer relevant.

Troubleshooting and Collecting information (Original)

1. READ everything. Read the README.md, the linked files, EVERYTHING. But especially read the output of your commands and follow them as instructions.

2. Collect system information.
   See this original comment for a script to collect details and example output.

3. Always mention the version of the jlmkr script you're running.
   Stating 'latest' isn't good enough, because your posting time, and someone's reading time might have a change in between.
   If you're pulling directly from the web, then copying a permalink of the main branch is also good.

4. Provide the content of your config by running jlmkr edit <jailname>

5. Collect what is displayed when the jail starts.

6. Review the journald logs by running jlmkr log <jailname>. Alternatively you can run journalctl -eu jlmkr-<jailname>
   Identify the relevant error message.

7. If something works, and something doesn't work, collect and send everything for both cases.
   (💡 TIP you can use <details><summary></summary></details> to collapse 'noisy'/long details) like this:

click here for link on how to comment like this

Read how you can streamline your Markdown by creating a collapsed section with the <details> tag at Organizing information with collapsed sections

The source for this section looks like:

   <details><summary>click here for link on how to comment like this</summary>    

    Read how you can streamline your Markdown by creating a collapsed section with the \<details> tag at
    [Organizing information with collapsed sections](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/organizing-information-with-collapsed-sections)

   </details>

8. If you are comfortable with reading python code, review the jlmkr.py code and search for phrases to identify whether the error originates from jlmkr.py script or (when no such phrase appears in the code) is just passed through, see if you can identify what produces the error message by searching the interweb.