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.

it takes about five minutes to break. but since i am already logged in to Windows using the working pin cause and on vpn before the TPM breaks, i can keep going until windows needs a reboot. to shutdown and restart the vm, requires a full unraid server reboot. 2025-11-13 17:29:15.296+0000: Domain id=1 is tainted: high-privileges char device redirected to /dev/pts/1 (label charserial0) 2025-11-13T17:33:58.062906Z qemu-system-x86_64: tpm_passthrough: error while transmitting data to TPM: Broken pipe

had the issue again (after the reboot and update), nearly immediately this time. 025-11-13T16:25:56.398047Z qemu-system-x86_64: tpm_passthrough: error while transmitting data to TPM: Broken pipe 2025-11-13T16:25:56.399426Z qemu-system-x86_64: tpm_passthrough: error while transmitting data to TPM: Broken pipe 2025-11-13T16:28:25.233206Z qemu-system-x86_64: tpm_passthrough: error while transmitting data to TPM: Broken pipe 2025-11-13T16:33:32.761522Z qemu-system-x86_64: tpm_passthrough: error while transmitting data to TPM: Broken pipe i had to force shutdown / destroy the vm and the /dev/tpm0 is still there but the /dev/fdset issue is back again ll /dev/tpm0 crw------- 1 root root 10, 224 Nov 13 10:56 /dev/tpm0 virsh start DELL-PC error: Failed to start domain 'DELL-PC' error: internal error: QEMU unexpectedly closed the monitor (vm='DELL-PC'): 2025-11-13T16:34:44.631128Z qemu-system-x86_64: -tpmdev passthrough,id=tpm-tpm0,path=/dev/fdset/0,cancel-path=/dev/fdset/1: '/dev/fdset/0' is not a TPM device. ll /dev/tpm0 crw------- 1 root root 10, 224 Nov 13 10:56 /dev/tpm0 root@DELL-PC:~# ll /dev/fdset ls: cannot access '/dev/fdset': No such file or directory end of log after destroy and start attempt again -watchdog-action reset \ -device '{"driver":"vfio-pci","host":"0000:c2:00.0","id":"hostdev0","bus":"pci.5","addr":"0x0"}' \ -device '{"driver":"usb-host","hostdevice":"/dev/bus/usb/001/005","id":"hostdev1","bus":"usb.0","port":"1"}' \ -device '{"driver":"usb-host","hostdevice":"/dev/bus/usb/001/002","id":"hostdev2","bus":"usb.0","port":"2"}' \ -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ -msg timestamp=on 2025-11-13 16:34:44.554+0000: Domain id=2 is tainted: high-privileges char device redirected to /dev/pts/1 (label charserial0) 2025-11-13T16:34:44.631128Z qemu-system-x86_64: -tpmdev passthrough,id=tpm-tpm0,path=/dev/fdset/0,cancel-path=/dev/fdset/1: '/dev/fdset/0' is not a TPM device. 2025-11-13 16:34:44.666+0000: shutting down, reason=failed

i also just now see there is an update to 7.2.0 ; while i would normally wait a lot longer to make sure it is stable first, i think risking the early adoption is better than the current issue i face. so i will do that update prior to the reboot.

anyone? i have waiting too long and must reboot the server again to get my vm going, however i am sure the issue will return. if there is anymore data i can get while things are working let me know. or example right now the following is the error i get when trying to start the vm virsh start DELL-PC error: Failed to start domain 'DELL-PC' error: Could not open TPM device /dev/tpm0: No such file or directory and i can conffirm there is no '/dev/tpm0' ll /dev/tpm0 ls: cannot access '/dev/tpm0': No such file or directory after i reboot i will check again and i am pretty sure it will be there. **** after reboot and upgrade to 7.2.0 **** ll /dev/tpm0 crw------- 1 root root 10, 224 Nov 13 10:56 /dev/tpm0 virsh start DELL-PC Domain 'DELL-PC' started

after running properly for a 5 days, my passed through tpm goes into an error. 2025-10-27T05:28:40.801789Z qemu-system-x86_64: tpm_passthrough: error while transmitting data to TPM: Broken pipe if i stop the vm and try to start it again (without rebooting my whole unraid server) i get. (ignore the date and time stamp i took this cut and paste the previous time this happened). rebooting (sometimes even needing a poweroff / poweron) to release the TPM seems necessary. i am unsure if this is obvious to others or not or if it only happens when it is in the error mode but '/dev/fdset/0' doesn't exist. so i don't know why the error is saying that. maybe it exists when there is not error, but i don't think so? i am currently waiting for a response before i reboot this time. internal error: QEMU unexpectedly closed the monitor (vm='DELL-PC'): 2025-10-22T11:28:47.393672Z qemu-system-x86_64: -tpmdev passthrough,id=tpm-tpm0,path=/dev/fdset/0,cancel-path=/dev/fdset/1: '/dev/fdset/0' is not a TPM device. this is a pretty bad ongoing issue that i have been putting off making this support request for. it was happening in earlier version as well but wasn't nearly as bad. i even downgraded my version for a very long time because of it. anyway i would very much appreciate any help. ps. if you are wondering why .. i need to use this line(see below) in my xml so that my system is recognized as the hardware it is on. i have my original nvme drive passed through where my companies corporate image is installed. then i must passthrough my tpm, in this way i can use my companies vpn, and windows 'hello!' login/ pin, that is based on the original hardware and a certificate that it checks against that hardware. <smbios mode='host'/> dell-pc-diagnostics-20251027-0859.zip

so the one example i have so far is i moved ... /boot/logs to /boot/config/logs then added the following to /boot/config/go #boot bindings mount --bind /boot/config/logs /boot/logs i did this to get those to backup and because fat32 cannot do symlink. and as you said you don't want to break things so pointing it back to the original location takes care of that. this is also probably the least important of the things i want included in the backup, but i thought it might be useful to someone else if i provided an example.

so i had to use the usb creator to create a usb, then manually copy over everything from my zip file. that is all fine my concern is that the backup doesn't work. is the online backup not supposed to do the whole usb, it just does the config folder? i guess i need to move a bunch of stuff to the config folder in that case.

my flash drive is starting to fail again, so i tried to take an update backup with 'connect' and it didn't work, i had to delete the one from a few months backup again. it worked but the whole backup is just 481.5MB its missing tons of info. so i went over to the Main page, clicked on Flash and clicked the FLASH BACKUP button. i have tried several times but it always stalls out at 2.3G, i checked and i am missing approximately 5214 files. the zip process is gone. how can i run that from the terminal? or should i just zip it myself. will it be usable with 'unraid usb creator' ? trying. zip -r flash-backup-20250119-1729.zip /boot |pv

yes i. understand thanks. that might be a difficult feature to implement. the real feature request I would prefer, is to be to have an option to not create shares from top level folder automatically. it just clutters up the shares list with a bunch of 'shares' that aren't exports.

thanks, i never realized this, i guess i previously more studious organizing prevented me from noticing this. however it would be nice if you create something directly on a cache share that it creates a cache share rather than an array only share.