xtrap225

okay i got it i am like 99.999% sure this time. kinda cheating but whatever gets the job done. i will edit this with more detail later before marking it complete. basically i got a new usb corporate image sent to me. i dd'd it to a .img file edited the xml to use the .img as the installer, and before doing that also switched emulated tpm before installing. this allowed me to use an emulated tpm and get the vpn to work and not have to rat myself out to the IT support team. but there are more important details to come. just in case anyone else is in the same position.

bios settings were no help back to the drawing board.

2026-02-02 17:43:18.714+0000: Domain id=2 is tainted: high-privileges 2026-02-02 17:43:18.714+0000: Domain id=2 is tainted: custom-argv char device redirected to /dev/pts/1 (label charserial0) 2026-02-03T12:12:18.839718Z qemu-system-x86_64: tpm_passthrough: error while transmitting data to TPM: Broken pipe approx start time 2026-02-02 5:43 PM approx error time 2026-02-03T12:12 AM next schedule shutdown and hopefully make bios changes above, i don't actually know what the current settings are.

here is my latest attempts - added 'tpm_tis.interrupts=0' to the boot see picture below added this to go file # 1. Force TPM Power to stay ON (prevents sleep/broken pipe) echo "on" > /sys/class/tpm/tpm0/device/power/control # 2. Try to wrest RNG control away if it hasn't been blocked via Syslinux yet echo "none" > /sys/devices/virtual/misc/hw_random/rng_current 2>/dev/null #<----this didn't work it remains 'tpm-rng-0' # 3. Ensure permissions are wide open for QEMU chmod 666 /dev/tpm0 assuming now that the error will return, next thing to try will be to make changes to the bios. BIOS Category Setting Name Action Why? Security > TPM 2.0 TPM Security / TPM On ENABLED Essential for the chip to exist. Security > TPM 2.0 PPI Bypass for Enable ENABLED (Check) Prevents BIOS prompts when the VM resets the TPM. Security > TPM 2.0 PPI Bypass for Clear ENABLED (Check) Same as above; avoids manual interaction. Security > TPM 2.0 Attestation Enable DISABLED (Uncheck) Stops Dell firmware from constantly "pinging" the chip. Security > TPM 2.0 Key Storage Enable ENABLED (Check) Allows the chip to actually store the keys your VPN needs. Security > TPM 2.0 SHA-256 ENABLED Ensure the hashing algorithm is modern (standard for TPM 2.0). Virtualization Trusted Execution (TXT) DISABLED (Off) CRITICAL. This is the primary cause of "Broken Pipe." Security Intel PTT DISABLED (Off) Prevents the CPU's internal TPM from fighting the discrete chip. but for now i am monitoring ...

came back start was approx 2026-01-28 14:04:40.477+0000: starting up libvirt version: 11.7.0, qemu version: 9.2.3, kernel: 6.12.54-Unraid, hostname: done starting approx 026-01-28T14:19:29.674078Z error 2026-01-29T14:21:54.949080Z qemu-system-x86_64: tpm_passthrough: error while transmitting data to TPM: Broken pipe remains on vpn for a while longer so i won't try anything until i must. or no one is watching plex

thanks i did notice that, both it gets rewritten and that a single dash is correct. big thanks for the response though.. i forgot to come back and make the correction because of all the attempts to fix.

i have changed /added to my /boot/config/go rm -f /dev/tpmrm0 the idea here is that this will prevent tailscale or anything from messing around with tpmrm0 and still allow the vm to interact with tpm0 which is necessary. otherwise i have the vm starting automatically via GUI slider again, and NOT changed back other customization in go file or xml. so far so good, for a bit there the error was coming up nearly immediately again in the vm's log .. so far it hasn't but need to wait for as long as a week or two to make sure it doesn't come back again.

it came back at nearly quarter after 4am this morning. so that is an approximate record uptime of 4 days and 16 hours (about), before reoccurrence. 2026-01-20T04:11:39.899988Z qemu-system-x86_64: tpm_passthrough: error while transmitting data to TPM: Broken pipe i am going to try to fix it, using the same concept as the previous fix but this time just stopping the tailscale service and starting it again without read permissions to the tpm. no rebooting. if i can get it to work i can maybe create another user script to 'fix' as needed while not rebooting. but i have my doubts, and even if it does work, i don't know if i can call that a 'fix'. probably something in the tailscale that can be changed to NOT use the tpm but i thought it was already set.

i might maybe finally have a fix in place however i am unsure and hesitant to confirm it as fixed yet. i get the following line in red, but that is almost certainly a non-issue. it is because of using the qemu direct lines in the xml instead of working through only the libvirt. 2026-01-15 16:56:34.790+0000: Domain id=1 is tainted: custom-argv at this time i am at 2 days 1.5 hours since last reboot, which is the longest ever since this issue started. to be clear unraid itself is stable and doesn't require rebooting, just if i needed my work vm to you know work. i have changed my passthrough of the tpm from tis to crb in my xml, <tpm model='tpm-crb'> <backend type='passthrough'> <device path='/dev/tpm0'/> </backend> <alias name='tpm0'/> </tpm> since that change i have removed the above and changed the xml top line to. <domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> and the bottom section to ... just above the closing line </domain>. <qemu:commandline> <qemu:arg value='-tpmdev'/> <qemu:arg value='passthrough,id=tpm0,path=/dev/tpm0,cancel-path=/dev/null'/> <qemu:arg value='-device'/> <qemu:arg value='tpm-crb,tpmdev=tpm0'/> </qemu:commandline> and put the following in the /etc/libvirt/qemu.conf, now i temporarily made these changes permanent by keeping the file i want in /boot/config/qemu.conf and using the go file to rm -f that file and ln -s the kept file to the proper location(see top of go file below). this is likely not the best way of doing that as eventually that file may change in upgrades so using something like sed to add the changes on boot might be a better method. cgroup_device_acl = [ "/dev/tpm0", "/dev/null", "/dev/full", "/dev/zero", "/dev/random", "/dev/urandom", "/dev/ptmx", "/dev/kvm" ] my 'go' file now has this in it, which also re-iterates the current method i am using for the above qemu.conf. i put this just under and unrelated fix from years ago i am unsure if it is still required but otherwise it's at the top. #!/bin/bash #not sure why this comes but based on cron.daily error <--unrelated and may or may not be needed still for an error i was getting after reboot daily. touch /var/log/tinc.log # Force correct Tailscale parameters (fix single dash bug) cat <<EOF > /usr/local/emhttp/plugins/tailscale/custom-params.sh TAILSCALE_CUSTOM_PARAMS="--encrypt-state=false --hardware-attestation=false" EOF # Ensure permissions are set so Tailscale can't 'see' the TPM to lock it chmod 000 /dev/tpm0 /dev/tpmrm0 #fix qemu for tpm issue rm -f /etc/libvirt/qemu.conf ln -s /boot/config/qemu.conf /etc/libvirt/qemu.conf i turned off auto starting of the vm, which i mostly kept off anyway. but now i start it using a user script as follows; which i run manually. (/boot/config/plugins/user.scripts/scripts/Fix_TPM_and_Start_VM) #!/bin/bash # 1. Reset the device permissions just in case chown root:root /dev/tpm0 chmod 660 /dev/tpm0 # 2. Start the VM virsh start DELL-PC # 3. Wait 10 seconds for the VM to claim the hardware sleep 10 if this repair survives another week or so i will call it fixed and mark this as solved.

issue came back, just took longer

so i think the issue was / is that tailscale was grabbing the tpm out from under qemu / libvirt. i have no idea what i actually did to fix it but now, even though this was already how it was setup. lsof /dev/tpm* 2>/dev/null COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME tailscale 21088 root 18u CHR 242,65536 0t0 398 /dev/tpmrm0 tailscale 21088 root 28u CHR 242,65536 0t0 398 /dev/tpmrm0 qemu-syst 24981 root 6u CHR 10,224 0t0 397 /dev/tpm0 qemu-syst 24981 root 23u CHR 10,224 0t0 397 /dev/tpm0 ll /dev/tpm* crw------- 1 root users 10, 224 Jan 5 09:04 /dev/tpm0 crw------- 1 root root 242, 65536 Jan 5 09:04 /dev/tpmrm0

Libvirt 11.7.0 + QEMU 9.2.3 has a regression/bug with TPM passthrough that causes the error: '/dev/fdset/0' is not a TPM device. This affects hardware TPM passthrough (both /dev/tpm0 and /dev/tpmrm0) with both tpm-tis and tpm-crb models. The issue appears to be in libvirt's file descriptor passing mechanism for TPM devices. A reboot temporarily resolves the issue, but it recurs. Could you investigate upgrading to a newer libvirt version or applying patches to fix the TPM passthrough fd handling?

anyone have any ideas on this one? or even a comment? did i do something wrong? did i ask this in the wrong location on the forum?

anyone have any ideas on this one?

i had to reboot again so i upgraded to 7.2.2 .. it didn't help. but it also didn't hurt anything further. same issue.