InEnduringGrowStrong@sh.itjust.works

Haven’t had to use port forwarding for gaming in like 30 or so years, so I just looked up Nintendo’s website…

Within the port range, enter the starting port and the ending port to forward. For the Nintendo Switch console, this is port 1024 through 65535

LMAO, no thanks, that’s not happening.

For your question, you could likely route everything through a tunnel and manage the port forwarding on the other end of the tunnel.

Ultimately, do whatever you think you’ll be able to keep up with.
The best documentation system is useless if you keep putting it off because it’s too much work.

It can be in git even if you’re not doing ‘config as code’ or ‘infrastructure as code’ yet/ever.
Even just a text file with notes in markdown is better than nothing. Can usually be rendered, tracked, versionned.
You can also add some relevant files as needed too.

Like, even if your stuff isn’t fully automated CI/CD magic, a copy of that one important file you just modified can be added as necessary.

Also, the crackling might be something about the sampling rate. It’s been a while since since I poked around with audio, but I vaguely remember changing the default sampling rate and restart pulseaudio or something like that.

In my case, I think the onboard audio device is in the same group as the motherboard chipset, which would explain the host crashing when passing through.

Hmmm… I do have audio coming out of a guest VM under proxmox, but I’m passing through a whole GPU which includes audio through its HDMI.

The on-board audio might not be in an iommu group that can be passed without breaking something else, which would likely prevent booting the host correctly.

Honestly, I think I’d just go with a USB dongle for the audio. Easier to passthrough, likely better audio quality too and shouldn’t be too expensive.
You can pass either a USB device id or a port (or group of ports, depending on how it’s grouped)

are you alright?

Yea, if anything it makes good practice.
Swapping hard drives in the larger data pool isn’t as daunting anymore.
Although, I gotta be honest, swapping drives in the zpool from which proxmox boots itself is still a bit iffy to me.
I had to set a reminder, because otherwise I won’t do it often enough.

Personally I use a ZFS pool in my Linux homelab that’s been rock solid. However the pucker factor would be high if a drive fails.

I use a ZFS pool for my home stuff too.
To minimize the pucker factor, I have an extra drive of the same capacity and I rotate through them in the mirror pool.
It makes good practice replacing and resilvering drives and since it’s a mirror it’s also kind of an offline backup.
Also, I had bought the initial drives at the same time and figured rotating though them would minimize the odds of failing around the same time.
I’m much less wary of the whole thing now that I’ve resilvered the drives several times.

Are you trying to recover data here?
Seems like you didn’t use it and (maybe?) don’t have data to lose here?

Yea I’ve been using nextcloud for a while and it’s fine.
I remember when I used owncloud before nextcloud was even a thing and the upgrade experience was absolute shit.
These days it’s just fine.

Ah nice you got it working.
Once it works it’s great.
I’ve been running mine for a while now, but purposefully avoided Kernel upgrades so far.

It does seem a lot like the reset bug, but then you already tried that. :/ Kernel module aren’t as easy to install and if you’re missing the required flags it might just do nothing.

grep -E '(CONFIG_FTRACE|CONFIG_KPROBES|CONFIG_PCI_QUIRKS|CONFIG_KALLSYMS|CONFIG_KALLSYMS_ALL|CONFIG_FUNCTION_TRACER)\b' /boot/config-`uname -r`  

Should show the 6 flags =y

Or maybe some variation of manual reset…
https://forum.proxmox.com/threads/issues-with-intel-arc-a770m-gpu-passthrough-on-nuc12snki72-vfio-pci-not-ready-after-flr-or-bus-reset.130667/

Formatted with a code block so it’s more readable:

16:41:43 `Dec 19 16:40:45 pve pvedaemon[1590]: end task UPID:pve:00030675:000E7952:6581B96F:vncshell::root@pam: OK
Dec 19 16:40:47 pve kernel: vfio-pci 0000:03:00.0: not ready 16383ms after bus reset; waiting
Dec 19 16:41:03 pve pvedaemon[1590]: starting task UPID:pve:000308EE:000E85EB:6581B98F:qmstart:195:root@pam:
Dec 19 16:41:03 pve pvedaemon[198894]: start VM 195: UPID:pve:000308EE:000E85EB:6581B98F:qmstart:195:root@pam:
Dec 19 16:41:06 pve kernel: vfio-pci 0000:03:00.0: not ready 32767ms after bus reset; waiting
Dec 19 16:41:40 pve kernel: vfio-pci 0000:03:00.0: not ready 65535ms after bus reset; giving up
Dec 19 16:41:41 pve kernel: vfio-pci 0000:03:00.1: Unable to change power state from D0 to D3hot, device inaccessible
Dec 19 16:41:41 pve kernel: vfio-pci 0000:03:00.0: Unable to change power state from D0 to D3hot, device inaccessible
Dec 19 16:41:41 pve systemd[1]: 195.scope: Deactivated successfully.
Dec 19 16:41:41 pve systemd[1]: 195.scope: Consumed 54min 2.778s CPU time.
Dec 19 16:41:41 pve systemd[1]: Started 195.scope.
Dec 19 16:41:41 pve kernel: tap195i0: entered promiscuous mode
Dec 19 16:41:41 pve kernel: vmbr0: port 4(fwpr195p0) entered blocking state
Dec 19 16:41:41 pve kernel: vmbr0: port 4(fwpr195p0) entered disabled state
Dec 19 16:41:41 pve kernel: fwpr195p0: entered allmulticast mode
Dec 19 16:41:41 pve kernel: fwpr195p0: entered promiscuous mode
Dec 19 16:41:41 pve kernel: vmbr0: port 4(fwpr195p0) entered blocking state
Dec 19 16:41:41 pve kernel: vmbr0: port 4(fwpr195p0) entered forwarding state
Dec 19 16:41:41 pve kernel: fwbr195i0: port 1(fwln195i0) entered blocking state
Dec 19 16:41:41 pve kernel: fwbr195i0: port 1(fwln195i0) entered disabled state
Dec 19 16:41:41 pve kernel: fwln195i0: entered allmulticast mode
Dec 19 16:41:41 pve kernel: fwln195i0: entered promiscuous mode
Dec 19 16:41:41 pve kernel: fwbr195i0: port 1(fwln195i0) entered blocking state
Dec 19 16:41:41 pve kernel: fwbr195i0: port 1(fwln195i0) entered forwarding state
Dec 19 16:41:41 pve kernel: fwbr195i0: port 2(tap195i0) entered blocking state
Dec 19 16:41:41 pve kernel: fwbr195i0: port 2(tap195i0) entered disabled state
Dec 19 16:41:41 pve kernel: tap195i0: entered allmulticast mode
Dec 19 16:41:41 pve kernel: fwbr195i0: port 2(tap195i0) entered blocking state
Dec 19 16:41:41 pve kernel: fwbr195i0: port 2(tap195i0) entered forwarding state
Dec 19 16:41:43 pve kernel: vfio-pci 0000:03:00.0: Unable to change power state from D3cold to D0, device inaccessible
Dec 19 16:41:43 pve kernel: vfio-pci 0000:03:00.0: Unable to change power state from D3cold to D0, device inaccessible
Dec 19 16:41:43 pve kernel: vfio-pci 0000:03:00.0: Unable to change power state from D3cold to D0, device inaccessible
Dec 19 16:41:43 pve kernel: vfio-pci 0000:03:00.0: Unable to change power state from D3cold to D0, device inaccessible
Dec 19 16:41:43 pve kernel: vfio-pci 0000:03:00.1: Unable to change power state from D3cold to D0, device inaccessible
Dec 19 16:41:43 pve kernel: vfio-pci 0000:03:00.0: Unable to change power state from D3cold to D0, device inaccessible
Dec 19 16:41:43 pve kernel: vfio-pci 0000:03:00.1: Unable to change power state from D3cold to D0, device inaccessible
Dec 19 16:41:44 pve kernel: pcieport 0000:02:00.0: broken device, retraining non-functional downstream link at 2.5GT/s
Dec 19 16:41:44 pve pvedaemon[1592]: VM 195 qmp command failed - VM 195 not running
Dec 19 16:41:45 pve kernel: pcieport 0000:02:00.0: retraining failed
Dec 19 16:41:46 pve kernel: pcieport 0000:02:00.0: broken device, retraining non-functional downstream link at 2.5GT/s
Dec 19 16:41:47 pve kernel: pcieport 0000:02:00.0: retraining failed
Dec 19 16:41:47 pve kernel: vfio-pci 0000:03:00.0: not ready 1023ms after bus reset; waiting
Dec 19 16:41:48 pve kernel: vfio-pci 0000:03:00.0: not ready 2047ms after bus reset; waiting
Dec 19 16:41:50 pve kernel: vfio-pci 0000:03:00.0: not ready 4095ms after bus reset; waiting
Dec 19 16:41:54 pve kernel: vfio-pci 0000:03:00.0: not ready 8191ms after bus reset; waiting
Dec 19 16:42:03 pve kernel: vfio-pci 0000:03:00.0: not ready 16383ms after bus reset; waiting
Dec 19 16:42:21 pve kernel: vfio-pci 0000:03:00.0: not ready 32767ms after bus reset; waiting
Dec 19 16:42:56 pve kernel: vfio-pci 0000:03:00.0: not ready 65535ms after bus reset; giving up
Dec 19 16:42:56 pve kernel: vfio-pci 0000:03:00.1: Unable to change power state from D3cold to D0, device inaccessible
Dec 19 16:42:56 pve kernel: vfio-pci 0000:03:00.0: Unable to change power state from D3cold to D0, device inaccessible
Dec 19 16:42:56 pve kernel: fwbr195i0: port 2(tap195i0) entered disabled state
Dec 19 16:42:56 pve kernel: tap195i0 (unregistering): left allmulticast mode
Dec 19 16:42:56 pve kernel: fwbr195i0: port 2(tap195i0) entered disabled state
Dec 19 16:42:56 pve pvedaemon[199553]: stopping swtpm instance (pid 199561) due to QEMU startup error
Dec 19 16:42:56 pve pvedaemon[198894]: start failed: QEMU exited with code 1
Dec 19 16:42:56 pve pvedaemon[1590]: end task UPID:pve:000308EE:000E85EB:6581B98F:qmstart:195:root@pam: start failed: QEMU exit>
Dec 19 16:42:56 pve systemd[1]: 195.scope: Deactivated successfully.
Dec 19 16:42:56 pve systemd[1]: 195.scope: Consumed 1.736s CPU time.

Try journalctl to get more details from when it fails?

Maybe this?
https://github.com/gnif/vendor-reset
Although I’ve been passing through a vega64 without needing this.

What’s nice is it provides a similar level of protection to using a VPN with PKI, but just for that specific subdomain. While a VPN would be have to be connected manually before use (or all the time), this is built-in.

The odds of someone breaking through the mTLS and breaking through that application’s security at the same time are much smaller than either separately.
If you don’t have a valid cert, you’re dropped by the reverse proxy before anything even gets passed to the server behind it.

I’m a big fan of it.

Not really, although now that I have certs for those anyway, maybe I should.
More like I’m using some services on the go that I want to always work, whether I’m on the LAN or on the go.
Opening home automation or 3d printers to the Internet is unwise to say the least.
mTLS in the reverse proxy for those allows me to have more security without having to establish a VPN first.

I’m just doing mutual TLS to authenticate clients which I use the pricate CA for.
I could use the orivate CA for the server instead of lets encrypt and trust that on devices, but letsencrypt is easy enough and useful for other things that I open publicly. mTLS avoids needing a vpn for more sensitive services

I run a private CA for client SSL.
For traditional server SSL I just use let’s encrypt, although I already have the domain (less than $10 a year) for my public facing stuff, and just use a subdomain of that one for my homelab.

I have a container with openssl for the private CA and generating user certs as well as renewing the let’s encrypt ones. I just use openssl without anything fancy.
The output folder is only mounted rw in that one container
I only ever mount the subfolders in read-only in other containers that need those certs.
All these containers are running on the same server so I don’t even have to copy anything around, the containers don’t even need connectivity between them, it’s just mounted where needed.