Paul_Ber

Ok it is back, maybe I can ignore this? Feb 11 15:33:22 Unraid kernel: clocksource: timekeeping watchdog on CPU3: acpi_pm wd-wd read-back delay of 94425ns Feb 11 15:33:22 Unraid kernel: clocksource: wd-tsc-wd read-back delay of 188571ns, clock-skew test skipped! Feb 11 15:33:49 Unraid kernel: clocksource: timekeeping watchdog on CPU1: acpi_pm wd-wd read-back delay of 91073ns Feb 11 15:33:49 Unraid kernel: clocksource: wd-tsc-wd read-back delay of 161752ns, clock-skew test skipped! Feb 11 15:37:19 Unraid kernel: clocksource: timekeeping watchdog on CPU5: acpi_pm wd-wd read-back delay of 88000ns Feb 11 15:37:19 Unraid kernel: clocksource: wd-tsc-wd read-back delay of 183263ns, clock-skew test skipped! Feb 11 15:37:30 Unraid kernel: clocksource: timekeeping watchdog on CPU3: acpi_pm wd-wd read-back delay of 87441ns Feb 11 15:37:30 Unraid kernel: clocksource: wd-tsc-wd read-back delay of 176558ns, clock-skew test skipped! Feb 11 15:47:02 Unraid emhttpd: spinning down /dev/sdf Feb 11 15:47:13 Unraid emhttpd: spinning down /dev/sdd Feb 11 15:47:19 Unraid emhttpd: spinning down /dev/sdg Feb 11 15:48:11 Unraid emhttpd: read SMART /dev/sdf Feb 11 15:48:17 Unraid emhttpd: read SMART /dev/sdd Feb 11 15:48:26 Unraid emhttpd: read SMART /dev/sdg Feb 11 15:49:04 Unraid kernel: clocksource: timekeeping watchdog on CPU7: acpi_pm wd-wd read-back delay of 91352ns Feb 11 15:49:04 Unraid kernel: clocksource: wd-tsc-wd read-back delay of 182704ns, clock-skew test skipped! Feb 11 15:50:21 Unraid kernel: clocksource: timekeeping watchdog on CPU1: acpi_pm wd-wd read-back delay of 87441ns Feb 11 15:50:21 Unraid kernel: clocksource: wd-tsc-wd read-back delay of 176558ns, clock-skew test skipped! Feb 11 15:50:31 Unraid kernel: clocksource: timekeeping watchdog on CPU5: acpi_pm wd-wd read-back delay of 84368ns Feb 11 15:50:31 Unraid kernel: clocksource: wd-tsc-wd read-back delay of 277409ns, clock-skew test skipped! Feb 11 15:51:19 Unraid kernel: clocksource: timekeeping watchdog on CPU6: acpi_pm wd-wd read-back delay of 89955ns Feb 11 15:51:19 Unraid kernel: clocksource: wd-tsc-wd read-back delay of 176279ns, clock-skew test skipped! Feb 11 15:53:19 Unraid unassigned.devices: Removing configuration 'KINGSTON_SHSS37A240G_50026B7253083EAF'. Feb 11 15:55:39 Unraid kernel: clocksource: timekeeping watchdog on CPU6: acpi_pm wd-wd read-back delay of 78501ns Feb 11 15:55:39 Unraid kernel: clocksource: wd-tsc-wd read-back delay of 181866ns, clock-skew test skipped! Feb 11 15:59:04 Unraid kernel: clocksource: timekeeping watchdog on CPU0: acpi_pm wd-wd read-back delay of 172927ns Feb 11 15:59:04 Unraid kernel: clocksource: wd-tsc-wd read-back delay of 451454ns, clock-skew test skipped! Feb 11 16:03:02 Unraid emhttpd: spinning down /dev/sdf Feb 11 16:03:13 Unraid emhttpd: spinning down /dev/sdd Feb 11 16:03:19 Unraid emhttpd: spinning down /dev/sdg Feb 11 16:04:10 Unraid emhttpd: read SMART /dev/sdf Feb 11 16:04:17 Unraid emhttpd: read SMART /dev/sdd Feb 11 16:04:26 Unraid emhttpd: read SMART /dev/sdg Feb 11 16:09:18 Unraid kernel: clocksource: timekeeping watchdog on CPU3: acpi_pm wd-wd read-back delay of 173765ns Feb 11 16:09:18 Unraid kernel: clocksource: wd-tsc-wd read-back delay of 184660ns, clock-skew test skipped! unraid-diagnostics-20230211-1612.zip

Maybe it will be fine, it is saying Disk1 is being emulated.

I did steps 1, 2, 3, 4, 5, and then 6 power on. Well the PC was on, Unraid for some reason assigned the new disk in the slot the old disk was in(I never did this). And the array came up and not the part with all the choices for the slots. So I stopped the array because I still had to preclear my replacement disk. I Unassigned the slot because I wasn't ready to assign yet. My preclear is almost done. I will assign the new disk to the old disks slot next. Then start the array, will it rebuild the missing slot on to the new disk? I guess I will know right away if it is rebuilding and my post will be not needed. Thanks. In the end it is working as intended. unraid-diagnostics-20230211-1452.zip

Too bad the Unraid UI didn't filter this put.

So it looks like it would be a pain seeing this all the time. unraid-diagnostics-20230210-0300.zip

Turned off HPET settings in bios and seems fine now.

Brand new Seagate 6TB drive is already getting error messages. I have never seen that high of an error rate before, is the disk DOA and I should return it? I am doing a preclear on that disk right now. Already switched from HBA to MB SATA ports and different SATA cables and it still does the error message. unraid-diagnostics-20230209-2243.zip

In the middle of replacing a disk and am getting these errors in the log, can I just ignore? Feb 9 17:42:38 Unraid kernel: clocksource: wd-tsc-wd read-back delay of 128577ns, clock-skew test skipped! Feb 9 17:42:39 Unraid kernel: clocksource: timekeeping watchdog on CPU0: hpet wd-wd read-back delay of 93866ns Feb 9 17:42:39 Unraid kernel: clocksource: wd-tsc-wd read-back delay of 116844ns, clock-skew test skipped! Feb 9 17:42:40 Unraid kernel: clocksource: timekeeping watchdog on CPU1: hpet wd-wd read-back delay of 231733ns Feb 9 17:42:40 Unraid kernel: clocksource: wd-tsc-wd read-back delay of 248844ns, clock-skew test skipped! Feb 9 17:42:41 Unraid kernel: clocksource: timekeeping watchdog on CPU3: hpet wd-wd read-back delay of 229777ns Feb 9 17:42:41 Unraid kernel: clocksource: wd-tsc-wd read-back delay of 143244ns, clock-skew test skipped! Feb 9 17:42:42 Unraid kernel: clocksource: timekeeping watchdog on CPU5: hpet wd-wd read-back delay of 233200ns Feb 9 17:42:42 Unraid kernel: clocksource: wd-tsc-wd read-back delay of 125155ns, clock-skew test skipped! Feb 9 17:42:42 Unraid kernel: clocksource: timekeeping watchdog on CPU6: hpet wd-wd read-back delay of 216088ns Feb 9 17:42:42 Unraid kernel: clocksource: wd-tsc-wd read-back delay of 233688ns, clock-skew test skipped! Feb 9 17:42:44 Unraid kernel: clocksource: timekeeping watchdog on CPU1: hpet wd-wd read-back delay of 228800ns Feb 9 17:42:44 Unraid kernel: clocksource: wd-tsc-wd read-back delay of 112933ns, clock-skew test skipped! Feb 9 17:42:47 Unraid kernel: clocksource: timekeeping watchdog on CPU7: hpet wd-wd read-back delay of 229777ns Feb 9 17:42:47 Unraid kernel: clocksource: wd-tsc-wd read-back delay of 231733ns, clock-skew test skipped! Feb 9 17:42:50 Unraid kernel: clocksource: timekeeping watchdog on CPU5: hpet wd-wd read-back delay of 233688ns Feb 9 17:42:50 Unraid kernel: clocksource: wd-tsc-wd read-back delay of 226355ns, clock-skew test skipped! Feb 9 17:42:52 Unraid kernel: clocksource: timekeeping watchdog on CPU1: hpet wd-wd read-back delay of 233688ns Feb 9 17:42:52 Unraid kernel: clocksource: wd-tsc-wd read-back delay of 233688ns, clock-skew test skipped! unraid-diagnostics-20230209-1740.zip

Ok will try this and report back, sorry for not checking your message for so long. Edit: @ich777 boot monitor with really old ATI PCI video card now works, thanks.

Not sure if this is a bug. I upgraded from 6.11.0 to 6.11.1. After it was done upgrading, the Nvidia driver said to wait while it downloaded a Nvidia driver for Unraid 6.11.1. Then shutdown, the started up. A drive was missing from one of the slots, one on the HBA card. It is missing in the boot screen for the HBA ctrl-C screen also, so not Unraid then. Edit: Solution. Just weird, the power connector came off too easy on the missing drive. Reseated power connector, no go. Tried a different power connector and Sata end, so now I do not know if it was the power connector or sata end. But working now.

Damn I forgot this and was banging my head against wall, Extra Parameters: --runtime=nvidia

Installed the Nvidia Driver for the 1st time or a least uninstalled in the past. Unraid 6.11.0 Edit: also happens on Unraid 6.10.3 I can access Unraid via browser but local boot monitor is just black with a cursor line at the top left. Local boot monitor show all text during boot then when it would come time to for the Unraid login screen to come up everything goes black. Unraid boot video card is an ATI old 32bit PCI card that has always worked. unraid-diagnostics-20220928-1734.zip

Lost my GPU passthru to Windows VM on upgrade from 6.9.2 to 6.10.3 The Windows VM sees the passthru but stops the GPU for reported problems code 43. Tried removing the Iommu binding, restart, add Iommu binding and reboot, no go. Trying updating GPU drivers in Windows now. Triangle gone in device manager now, reboot VM. Ok solved now.

I want to convert from Docker-compose.yml to Unraid Docker Templates? I think I got it all, just not sure about init and the stop_grace_period? ```yml version: "3.8" services: signum: image: signumnetwork/node:latest-h2 init: true stop_grace_period: 2m deploy: replicas: 1 restart: always ports: - "8123:8123" - "8125:8125" volumes: - "./conf:/conf" - "./db:/db" ``` Here is my existing signum-node.xml <?xml version="1.0" encoding="utf-8"?> <Containers> <TemplateURL>https://raw.githubusercontent.com/paulpoco/docker-templates/master/paulpoco/signum-node.xml</TemplateURL> <Beta>True</Beta> <Category>Crypto Currency:</Category> <Date>2022-01-31</Date> <Changes> October 6, 2021 Signum-node for Unraid January 30, 2022 Remove port 8121 January 31, 2022 Fix registry url </Changes> <Project>https://github.com/signum-network/signum-node/</Project> <Name>signum-node</Name> <Description> https://www.signum.network/ The world's first HDD-mined cryptocurrency using an energy efficient and fair Proof-of-Commitment (PoC+) consensus algorithm. The two supported database backends are: H2 (embedded, recommended) MariaDB (advanced users) </Description> <Overview> Proof of Commitment - ASIC proof / Energy efficient and sustainable mining No ICO/Airdrops/Premine Turing-complete smart contracts, via Signum SmartJ Asset Exchange; Digital Goods Store; Crowdfunds, NFTs, games, and more (via smart contracts); and Alias system </Overview> <Support>https://github.com/signum-network/signum-node</Support> <Registry>https://hub.docker.com/r/signumnetwork/node</Registry> <GitHub>https://github.com/signum-network/signum-node</GitHub> <Repository>signumnetwork/node:latest-h2</Repository> <BindTime>true</BindTime> <Privileged>false</Privileged> <Networking> <Mode>bridge</Mode> <Publish> <Port> <HostPort>8123</HostPort> <ContainerPort>8123</ContainerPort> <Protocol>tcp</Protocol> </Port> <Port> <HostPort>8125</HostPort> <ContainerPort>8125</ContainerPort> <Protocol>tcp</Protocol> </Port> </Publish> </Networking> <Data> <Volume> <HostDir>/mnt/user/appdata/signum-node/conf</HostDir> <ContainerDir>/conf</ContainerDir> <Mode>rw</Mode> </Volume> <Volume> <HostDir>/mnt/user/appdata/signum-node/db</HostDir> <ContainerDir>/db</ContainerDir> <Mode>rw</Mode> </Volume> </Data> <WebUI>http://[IP]:[PORT:8125]</WebUI> <Banner></Banner> <Icon>https://raw.githubusercontent.com/signum-network/signum-node/main/resources/images/signum_overlay_logo.ico</Icon> <ExtraParams></ExtraParams> </Containers> Do I add --init under ExtraParams? Not sure about stop_grace_period: 2m Where would I put this and could I have the Global Docker Stop Timeout be 30 seconds but my one Docker with stop_grace_period: 2m would respect the 2 mintutes? I tried the --init under ExtraParams and this is the command that got generated: root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='signum-node' --net='bridge' -e TZ="America/Los_Angeles" -e HOST_OS="Unraid" -p '8123:8123/tcp' -p '8125:8125/tcp' -v '/mnt/user/appdata/signum-node/conf':'/conf':'rw' -v '/mnt/user/appdata/signum-node/db':'/db':'rw' --init 'signumnetwork/node:latest-h2' The --init has to shutting down correctly to close all processes or does Unraid already do this with the Global Docker Stop Timeout?

Thanks. Will set the long time limit.

Is there a Docker Stop Timeout setting per container. I need 120 seconds to let one container close a database properly. I guess for now I can use the setting for all. If a docker shuts down sooner, will Unraid show it as stopped?

Reserved

Overview: Support for Flexget Template. Update: October 10, 2021 no longer a 2 in 1 container. Install Binhex DelugeVPN 1st Application: Flexget - http://flexget.com/ Docker Hub: https://hub.docker.com/r/wiserain/flexget:latest Wiserain is the Author of the DockerHub Container Template GitHub: https://github.com/paulpoco/docker-templates/blob/master/paulpoco/flexget.xml Wiserain Github: https://github.com/wiserain/docker-flexget Flexget wants to see DelugeVPN and use the network of "--net=contanier:binhex-delugevpn" Flexget starts daemonized and runs hourly. The Flexget webui works but you need to set password in the edit screen, needs to be at least 16 characters long. Description Flexget with webui daemon FlexGet is a multipurpose automation tool for content like torrents, nzbs, podcasts, comics, series, movies, etc. It can use different kinds of sources like RSS-feeds, html pages, csv files, search engines and there are even plugins for sites that do not provide any kind of useful feeds. There are numerous plugins that allow utilizing FlexGet in interesting ways and more are being added continuously. FlexGet is extremely useful in conjunction with applications which have watch directory support or provide interface for external utilities like FlexGet. Steps to Setup Binhex-delugevpn & Flexget sucessfully: Get Binhex-delugevpn working 1st before setting up Flexget: You will need an OVPN file from you VPN provider and put that in /mnt/user/appdata/binhex-delugevpn/openvpn folder You will need to update the "auth" file in /mnt/user/appdata/binhex-delugevpn and add "admin:deluge:10" without the quotes You need to read the instructions on https://forums.unraid.net/topic/44109-support-binhex-delugevpn/ https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md Read Q24 Q24. I would like to be able to route other docker containers through one of my existing VPN containers, how do I do this? A24. In order to route an application(s) through an existing VPN container you would do the following steps:- Flexget Container to route through Binhex-delugevpn: Left click icon and 'Edit' Flexget container and toggle advanced view (top right) In 'Extra Parameters' enter --net=container:binhex-delugevpn (already in the template) Go to 'Network Type' and select 'none' Remove all ports defined (no ports required as we will be accessing it via the Binhex-delugevpn container) (ports already removed) Click on 'Apply' Container running Binhex-delugevpn: Left click icon and 'Edit' Binhex-delugevpn container and toggle advanced view (top right) Click on 'Add another Path, Port, Variable, Label or Device' and add in a 'config type' of 'port' Enter in the Flexget Web UI 5050 port for 'container port' and any non conflicting port number for 'Host Port' (host port must not be used by another container) Edit 'VPN_INPUT_PORTS' env var and put Flexget Web UI 5050 port number in the 'value' Click on 'Apply'. In your config.yml put this at the begining: You can read up at https://flexget.com/ on how to put together a config.yml file that goes in /mnt/user/appdata/flexget folder.

Overview: Support for Flexget Template. Update: October 10, 2021 no longer a 2 in 1 container. I will delete my Dockhub/Github Repositories for this Docker in about a month, please migrate to Binhex-delugevpn and you need Flexget then use this template.

I just solved my problem by following Q24 at https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md Got the Flexget webui working. Just have to update my template with your suggestions and convert to version 2, thanks. I didn't build the Docker, https://hub.docker.com/r/wiserain/flexget did.

Docker template port comes up n/a for container port when loaded with add container. This is my template: https://github.com/paulpoco/docker-templates/blob/master/paulpoco/flexget.xml This what the 1st time edit screen looks like: Now is this doing this because I set Network to "none" and am using extra param of --net=container:binhex-delugevpn ? So far I cannot access the webui at host:5050 .

Now that DockerHub on the free plan doesn't you build anymore I am just going to use Binhex-DelugeVPN. I did find a Docker on DockerHub for Flexget so I made a template for Unraid. I have the template use extra params to use the network of binhex-delugevpn. Seems to work fine. Haven figured out how to connect to the Flexget webui, although the webui isn't really needed and if you want to manually run Flexget then use console. https://github.com/paulpoco/docker-templates/blob/master/paulpoco/flexget.xml @binhex how do I access the webui of a Docker that is using the network of -net=container:binhex-delugevpn ? Edit: I solved with question Q24 from VPN FAQ, all working as needed https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

DockerHub no longer free, what now? I tried the Github actions but fails.

Thanks will check that out. I used to manually go into DockerHub and manually trigger a build. I think I will make a stand alone Flexget and use the Network of none and extra params --net=container:DelugeVPN. Too hard to maintain my DelugeVPN-flexget.

I guess Docker Hub is not free anymore. Any replacement that is free?