s.Oliver

well, unRAID uses the USB-stick as a way of validating your license (because it is bound to the hardware UUID of that stick). don't know how to circumvent that, even though i also don't like the single point of failure associated to that way of doing it. once (quite awhile back) i had it setup with in a different way (with a synchronisation between virtual image and the USB-stick, but you had to have it mounted while booting unRAID and in the long run it was prone to failures when you forgot to sync back to the stick, before rebooting, etc.).

just quickly jumped here to give a hint: if your goal is, to boot unraid as a VM inside of Proxmox see my last post (just a few upwards from here). there's no need anymore, to fake/virtualize the usb-stick as vm file or such things. simple create the VM without (or delete later on) a disk associated. passthrough the original usb-stick ("UNRAID" labeled) to that VM and choose this one as boot order 1 (see Options) to boot from. i've set the machine type to Q35 with UEFI for passthrough of hardware hba controllers and other stuff. works perfectly.

i guess it's because unRAID ignores the power button pressed event from the QEMU agent.

tmux funktioniert bei mir jetzt wieder (ohne neustart von unRAID). perl ist ein überbleibsel aus alten zeiten, als unRAID noch bare metal lief. ich hatte alles probiert, inkl. deinstallation via Nerd Pack (aber auch manuell in der shell) – (tmux) hatte nie funktioniert, immer die gleiche obige fehlermeldung. dann schmieß ich perl runter und installierte tmux via Nerd Pack nochmals und voila – funktioniert wieder. ABER: wenn ich jetzt im Nerd Pack nachsehe, ist perl wieder installiert (evtl. eine abhängigkeit von einem anderen tool? aber kein python package) obwohl ich ja zwischenzeitlich schon mal deine version per shell installierte). unter /boot/config/plugins/NerdPack/packages/6.9 sind bei mir jetzt: iftop-1.0.4-x86_64-2.txz iotop-0.6-x86_64-1_fs.tgz mcelog-161-x86_64-1.txz ncurses-terminfo-6.1.20191130-x86_64-1.txz perl-5.32.0-x86_64-1.txz tmux-3.1.0-x86_64-1.txz unrar-5.8.5-x86_64-1_SBo.txz utempter-1.2.0-x86_64-3.txz ich weiß leider nicht mehr genau, was ich per hand letztenendes alles de- bzw. installierte, aber auf jedenfall geht jetzt mein oft benötigtes tmux wieder.

also soeben nochmal mit removepkg sowohl python, als auch tmux deinstalliert. dann von hand installiert, danach leider die gleiche fehlermeldung. nachtrag: funktioniert jetzt wieder. kann es sein, daß das im zusammenhang mit dem (soeben deinstalliertem) perl package steht? obwohl ich jetzt sehe, daß es doch wieder installiert ist – strange.

hab' das mit deinem Python3.9 package probiert – allerdings ohne neustart – immer noch die gleiche meldung. zudem auch noch das slackware 14.2 package "tmux-3.2a-x86_64-1.txz" installiert – keine änderung. btw. NerdPack meldet auch danach beim Update-Check ein Update für tmux als vorhanden. ist ein neustart zwingend notwendig? und sehe ich das richtig, daß ich dann dein Python3.9 + tmux package in den /boot/extra/ lege, sodaß diese dann beim neustart installiert werden (und evtl. vorhandene/bereits installierte versionen überschreiben/ersetzen)?

this latest update of the plug-in made the tools tmux & screen unusable with the same error message. these tools are used daily here and i kindly ask for a fix.

leider hier genau das gleiche problem. wollte eben grad tmux benutzen (screen ebenfalls) und exakt der gleiche fehler. testweise das iSCSI plugIn installiert (ohne neustart zumindest) hat das aber nichts an der fehlermeldung geändert.

UPDATE: since one of the latest PROXMOX updates native booting from an USB device is directly support. No hacks, tricks needed anymore.

thx. for the reminder. i always tend to forget, that i've to look at the beginning (even for actual news) 🙂 works perfect!

Hey 6.9.1 is out! I guess we need an adapted DVB Driver Package? And thx. so much for this work to enhance unRAID!

i've only tested briefly one tune/channel and that worked. my card is a Digital Devices Max A8i (cable). has 8-tuners and was heavily used in the past.

well, couldn't wait and tried my luck – and... it looks good! needs a bit more time to see the longevity/stability of all services, but well, for now, i'm happy.

i can't and don't want to say no. it's only my understanding of drivers for interfaces. well, someone with more knowledge of available drivers needs to chime in. but firewire is old and since a long time depreciated. i loved it back in the day, but alas not always the best technology wins in the long run.

i would imagine, that firewire support needs kernel drivers to be present for that I/O interface.