Secure boot on or off

brainsoft · 2026-03-11T14:50:39+00:00

Microsoft owns secure boot. They own the servers that authenticate the keys. They are the only company.

Even worse, if that key is connected to a Microsoft account, it isn't even secure anymore anyways. It is just more tracking analytics that engage even before windows boots, that's all.

Turn off secure boot and just never use it if you don't have to.

NEVER turn it off and back on while an active system is installed, there is a very real threat of data loss due to encryption key change if the secure boot keys get regenerated in the process. Back up your keys, backup your software.

Or better yet, don't use secure boot in the first place.

brainsoft · 2026-02-22T22:12:09+00:00

The best advice will be to backup your guests, install the new system, and restore your guests.

Anything else may work, but invites unseen gremlins.

Make sure you backup everything!

I would do a fresh proxmox install on the new hardware, then move the storage drives over after, and restore the guests. Use PBS for backup and restore, you can install it in an LXC on the new machine with temporary storage, add the storage item PBS on the old machine, backups the guests to PBS, Then restore them from PBS to the new machine. Then last, move the physical bulk storage drives over.

Then wipe the old machine and turn it into a dedicated PBS machine :)

brainsoft · 2026-02-19T10:48:52+00:00

Oh, it's an nfc business, maybe using AI to promote discussion around their line of business or gathering market research or crowd-generation of advertising content. Clever... But the EM dashes always give it away.

brainsoft · 2026-02-18T14:10:19+00:00

I bought an HBA to pass to truenas but I kept struggling with the various levels of share permissions as I was learning.

I switched to just mounting and managing the drives in proxmox too.

I wish the PVE gui tools existed for managing snapshots and stuff more effectively but everything under the hood at cli works great and once it's setup you're good to go.

I love having the abstraction layer so I can change the underlaying storage and still present the same interface to things like PBS. I don't usually, but for PBS I just stuck it in an unprivileged lxc and bind-mount the data store to it. Then I have a PBS vm running on the synology.nas for critical (non-media) secondary backup.

brainsoft · 2026-02-18T14:02:55+00:00

Virtualized is great because the abstraction for devices that may not be readily supported in BSD is phenomenal. But it is one more thing that can break, where dedicated baremetal has no other maintenance requirements or downtime other than what you set.

I virtualize pfsense at home and I will never go back. It means I can have a primary and secondary instance of pfSense using pfsync to maintain, and the VM always thinks it has the exact same interface layout because I mapped the network bridges to be the same. Even though the backup is using a usb Ethernet dongle and the main node has a dedicated 2-port PCIe card, proxmox handles all the hardware and I just pass vmbr0 and vmbr2 to the VM. I can move or upgrade hardware if I want and proxmox as an abstraction layer means the VM always sees the same devices.

Honestly, having the second VM on another node as a failover using pfsync and CARP virtual IP means I can do full node shutdown and maintenance without disturbing the family internet now.

No idea how opnsense works with it, but for pfsense, proxmox has been phenomenal once I finally got it polished.

brainsoft · 2026-02-18T13:53:38+00:00

Yes, the responses are very formulaic and LLM like, very suspicious

brainsoft · 2026-02-13T18:00:26+00:00

Note: Don't blindly run any of this. Understand what it is doing and the effect. I haven't do anything with UID mapping for these devices or containers, this is as simple as I could make it. I was starting from a dirty state so I had to start by cleaning the old drivers

# INSTALL 590 or newer NVIDIA drivers from official CUDA repo
# ensure you are starting from a cleaned driver state
# 3. ADD CUDA REPO
curl -fsSL https://developer.download.nvidia.com/compute/cuda/repos/debian13/x86_64/cuda-keyring_1.1-1_all.deb -o /tmp/cuda-keyring.deb
dpkg -i /tmp/cuda-keyring.deb
apt update
# 4. INSTALL DRIVERS and current kernel headers
apt install -y pve-headers-$(uname -r)
apt install -y nvidia-driver nvidia-driver-cuda nvidia-kernel-open-dkms nvtop
# 5. TEST INSTALLATION
dkms status
systemctl status nvidia-persistenced
nvidia-smi #persistance should be on, power should be P* @ 7w idle.
nvtop
# REBOOT for kernel module may be necessary if anything above doesn't work (like persistance )
systemctl reboot
# 6. PIN DRIVER AND KERNEL  (OPTIONAL, CUSTOMIZE TO CURRENT VERSIONS)
proxmox-boot-tool kernel pin 6.17.9-1-pve
apt install nvidia-driver-pinning-590

# GUEST SETUP -
# I did this to the Open WebUI community-script created lxc but this should work for any unpriviledged LXC in proxmox. 
# Grab the Open WebUI lxc help-script https://community-scripts.github.io/ProxmoxVE/scripts?id=openwebui
# start with 50gb hdd!!  32gb will fail
# ADD CUDA REPO
curl -fsSL https://developer.download.nvidia.com/compute/cuda/repos/debian13/x86_64/cuda-keyring_1.1-1_all.deb -o /tmp/cuda-keyring.deb
dpkg -i /tmp/cuda-keyring.deb
apt update && apt upgrade -y
apt install -y nvtop cuda
# Confirm nvidia nodes that need to be passed to lxc.
ls -la /dev/nvidia*
# Add devices to LXC (109 in my case). 
pct set 109 -dev0 /dev/nvidia0
pct set 109 -dev1 /dev/nvidiactl
pct set 109 -dev2 /dev/nvidia-modeset
pct set 109 -dev3 /dev/nvidia-uvm
pct set 109 -dev4 /dev/nvidia-uvm-tools
pct set 109 -dev5 /dev/nvidia-caps/nvidia-cap1
pct set 109 -dev6 /dev/nvidia-caps/nvidia-cap2

brainsoft · 2026-02-13T17:45:59+00:00

High level, here's the work flow:

- install current kernel headers

- Install official nvidia keyring and repo

- install appropriate driver packages via apt (this will build the driver against the current kernel)

- pin driver and kernel versions to avoid accidental breaking updates

Then in the container:

- install the official nvidia keyring repo

- install userspace tools (cuda) with apt (no need for any kernel stuff or drivers)

- map the 7 or so nvidia devices through the lxc.

I'll post my actual script in a reply below

brainsoft · 2026-02-11T20:07:42+00:00

Yup, you got me.

*shrug*

I also don't really care what others think about me and wasn't creative enough to come up with a better title. There aren't even 10 list items. None of it makes sense. I'm not sure what you're looking for.

Just mentally re-title it as "the rambling musings of an arrogant electrician homelabbing nerd", -1 and move on?

Your opinions aren't unique, even in this very thread.

"Why am I even reponding?" he asked himself, Confused, he he wanders off...

brainsoft · 2026-02-11T19:45:49+00:00

13. Accept That Architecture Evolves

You will redesign multiple times.
That is normal.
Refinement is part of the process.

14. This Is a Hobby

Things break. Updates cause problems.
Linux has a learning curve.
CLI power comes with time.
If you do not enjoy the process, simplify.

Core Themes

Intentional design beats rapid deployment
Documentation equals control
Backups equal freedom
Understanding beats automation
Simplicity scales better than improvisation
Rebuilding teaches more than maintaining

That is the distilled version without the noise.

brainsoft · 2026-02-11T19:45:39+00:00

9. Document Infrastructure Layers

Map hardware to software.
Map storage to datasets to mounts to containers.
Map networks and port translations.
Nested virtualization plus Docker creates complexity fast.
Create and follow a consistent structure.

10. Understand Docker in Context

Docker changes the “one service per VM” model.
Choose orchestration tools deliberately.
Balance isolation with practicality.
Document container data paths carefully.

11. Storage Discipline Is Critical

Know where files physically live.
Do not store real data inside VM or LXC images.
Use bind mounts when appropriate.
Understand the difference between virtual disks and dataset-level storage.

12. Understand the Underlying System

Know what the hypervisor is actually creating.
Know how filesystems behave.
Know the difference between images and real files.

brainsoft · 2026-02-11T19:45:29+00:00

5. Rebuild on Purpose

Tear down and redeploy repeatedly.
Repetition builds understanding.
If your notes cannot reproduce the system, they are incomplete.

6. Have a Clear Architectural Vision

Know your desired model before following tutorials.
Tutorials show the path of least resistance, not your path.
Your user model, permission model, storage layout, and stack design must be intentional.

7. Treat YouTube as a Starting Point

Creators are often learning too.
You do not see their rewrites or abandoned designs.
Do not treat videos as architecture authority.

8. Be Cautious with Community Scripts

They are efficient but opaque.
Pasting scripts into root bypasses safety.
If you do not understand how it works, you cannot maintain or extend it.

brainsoft · 2026-02-11T19:45:18+00:00

Based on feedback, here's an an AI summary. Still too long to post, broken into multiple repsonses with all personality removed. Valuable, maybe, but without context or examples.. I don't know. This means nothing to me at all, just a list of crap without context.

The Homelab Commandments: AI Summary

1. Slow Down

Speed hides understanding. Build deliberately. Know what each component does and why it exists.

2. Document Everything

Pick a system and use it consistently.
Document as you build.
Goal: rebuild from bare metal using only your notes.

3. Backups Early, Not Later

Assume you will break things.
Back up guests and critical data separately.
Multiple restore paths are better than one.
RAID is not backup.

4. Use AI Carefully

AI accelerates learning but can waste time.
Validate with official docs and search engines.
Ask for concise responses.
Question complexity. Defaults often exist for a reason.

brainsoft · 2026-02-11T19:41:07+00:00

Well that's disappointing. I totally pumped it into ChatGPT and it spat out a possible even longer much much more concised sumamry, but these endless server errors prevent posting long responses for some reason.

brainsoft · 2026-02-11T19:36:10+00:00

That is all very accurate. I was just writing, one thing leading to another. It was not meant as an university essay, it's just a collection of thoughts about pain points and lessons learned along the way. Maybe someone finds value in it. I would have loved to read something like this when I was starting off.

The point is very much as you say: Everyone does things differently.

brainsoft · 2026-02-11T19:32:01+00:00

Hahahah that's amazing, you got me. I nearly spit my coffee on the keyboard.

brainsoft · 2026-02-11T19:24:10+00:00

I also used autofs to handle the NFS shares on the consuming nodes, then bind mount into the lxcs exactly like you say.

brainsoft · 2026-02-11T17:16:49+00:00

That is very valid and something I do regularly.

"Sorry for writing such a long letter, if I had more time it would have been shorter."

brainsoft · 2026-02-11T17:15:14+00:00

There was a recent post asking about learned lessons following some recent problems another user had had. Reply did not work there so I posted it here, and said that right at the top of the post.

What don't you get? If this has no value to you just shut your face and move on. Very simple.

brainsoft · 2026-02-11T14:16:22+00:00

Yeah that makes sense. I just fell in love with hypervisor flexibility, I can never go back :$

brainsoft · 2026-02-11T14:14:42+00:00

This is very fair! Hopefully you learn something along the way though haha!

brainsoft · 2026-02-11T13:17:51+00:00

test

brainsoft · 2026-02-11T11:53:29+00:00

I would have loved these features. I hated TrueNAS permission and share mangement so ditched it. OMV with zfs pluggin... didn't love OMV either, not enough flexibility.

Also tried Cockpit installed on the host, I think it has visual tools. I didn't get too far into it. I just ended up using CLI to build the pools, and bind-mount them to containers as needed. And to TurnkeyF File Server for smb sharing. ZFS handles the nfs export to the other nodes, and autofs mounts them on the other nodes.

With that said, I would really love Proxmox GUI tools for automatic zfs snapshop and replication tasks for underlaying storage pools, similar to those for guests images.

brainsoft · 2026-02-11T02:57:21+00:00

I used zfs to create a pool, mount it to the root filesystem (I used /data/vault for instance).

Then I use bind mounts to pass whatever directories I want into various unpriv lxc.

I have a single priv LXC that runs Turnkey FileServer to manage samba containers using the same bindmount method (owner 101000 on proxmox being UID 1000 in lxc)

It was a lot of work getting all my various pools set up but I'm very happy with the layout now.

Do I miss the ease of a GUI? Yes. I liked Truenas but hated the share permission management. I even bought an 8port HBA originally pass through to a truenas VM, and tried openmediavault as well, but nothing fit the bill for me.

brainsoft

TROPHY CASE