Doubling what Klaymore said, I’ve seen this “just work” as long as all partitions have the same password, no key files necessary.

That said, if you needed to use a key file for some reason, that should work too, especially if your root directory is one big partition. Keep in mind too that the luks commands for creating a password-based encrypted partition vs a keyfile-based encrypted partition are different, so you can’t, for example, put your plaintext password into a file and expect that to unlock a LUKS partition that was setup with a password.

But the kernel should be trying to mount your root partition first at boot time where it will prompt for the password. After that it would look to any /etc/crypttab entries for information about unlocking the other partitions. In that file you can provide a path to your key file, and as long as it’s on the same partition as the crypttab it should be able to unlock any other partitions you have at boot time.

It is also possible, as one of your links shows, to automatically unlock even the root partition by putting a key file and custom /etc/crypttab into your initramfs (first thing mounted at boot time), but it’s not secure to do so since the initramfs isn’t (and can’t be) encrypted - it’s kind of the digital equivalent of hiding the house key under the door mat.

Another solution to this situation is to squash your changes in place so that your branch is just 1 commit, and then do the rebase against your master branch or equivalent.

Works great if you’re willing to lose the commit history on your branch, which obviously isn’t always the case.

Out of curiosity, what switch are you using for your setup?

Last time I looked, I struggled to find any brand of “home tier” router / switch that supported things like configuring vlans, etc.

Maybe I am not thinking of the access control capability of VLANs correctly (I am thinking in terms of port based iptables: port X has only incoming+established and no outgoing for example).

I think of it like this: grouping several physical switch ports together into a private network, effectively like each group of ports is it’s own isolated switch. I assume there are routers which allows you to assign vlans to different Wi-Fi access points as well, so it doesn’t need to be literally physical.

Obviously the benefits of vlans over something actually physical is that you can have as many as you like, and there are ways to trunk the data if one client needs access to multiple vlans at once.

In your setup, you may or may not benefit, organizationally. Obviously other commenters have pointed out some of the security benefits. If you were using vlans I think you’d have at a minimum a private and public vlan, separating out the items that don’t need Internet access from the Internet at all. Your server would probably need access to both vlans in that scenario. But certainly as you say, you can probably accomplish a lot of this without vlans, if you can aggressively setup your firewall rules. The benefit of vlans is you would only really need to setup firewall rules on whatever vlan(s) have Internet access.

I ran into the same thing. I’ve always just worked around it, but I believe I did find the solution at one point (can’t find the link now).

But if I am remembering right, I believe you need to manually create a bridge between the two networks - by default it isolates the VMs from TrueNAS itself for security reasons.

Sorry I can’t link the exact fix right now, but hopefully this will help you Google the post I found on the subject.

To expand on this a bit, git pull under the hood is basically a shortcut for git fetch (get the remote repository’s state) and git merge origin/main main (merge to remote changes to your local branch, which for you is always main).

When you have no local changes, this process just “makes a line” in your commit history (see git log --graph --decorate), but when you have local changes and the remote has changed too, it has to put those together into a merge commit - think a diamond shape with the common ancestor at the bottom, the remote changes on one side, your changes on the other side, and the merge of the two at the top.

Like the above comment says, normally this process is clarified at the command line - VSCode must be handling it automatically if there are no code conflicts.

Oh wow! 2GB already seems like a lot, especially since it looks like this instance has only been running for 10 days?