smkings

Members
  • Posts

    18
  • Joined

  • Last visited

Converted

  • Location
    UK

Recent Profile Visitors

389 profile views

smkings's Achievements

Noob

Noob (1/14)

1

Reputation

  1. Hi all, I'm running unRaid 6.12.3 and a few days ago I noticed that the Docker page is showing "Docker Service failed to start." I've found a few other threads on this and tried some of the suggestions. The main one being to stop the docker service, delete docker.img, and re-start the docker service. After this did nothing, I went through a terminal to check it was actually getting deleted and it didn't seem to be. Trying to delete docker.img manually from the terminal said that my array was in Read-Only. I had one disk full in the array so I scattered shares around with unBalance and rebooted which seemed to get the array out of read-only mode. I tried stopping docker and deleting docker.img again - I can confirm that it deleted, but it still didn't fix the problem. I see some BTRFS errors in my syslog and after scrubbing my 1TB nvme cache drive - nvme0n1 - which holds the appdata and system shares, the drive seems to have 3 uncorrectable errors. Can't find out more about them as when I try to run a SMART test, nothing seems to happen. The drive has about 300GB free, so I'm not sure what is causing the errors or if the drive is dying (it's only about 2 years old). Some highlights from my syslog below, and full diagnostics are attached. Aug 8 12:59:23 fractal emhttpd: mounting /mnt/cache Aug 8 12:59:23 fractal emhttpd: shcmd (46): mkdir -p /mnt/cache Aug 8 12:59:23 fractal emhttpd: /sbin/btrfs filesystem show 9e62a0a8-02e6-4e30-9f96-4d413126e2b5 2>&1 Aug 8 12:59:23 fractal emhttpd: Label: none uuid: 9e62a0a8-02e6-4e30-9f96-4d413126e2b5 Aug 8 12:59:23 fractal emhttpd: Total devices 1 FS bytes used 657.42GiB Aug 8 12:59:23 fractal emhttpd: devid 2 size 931.51GiB used 736.03GiB path /dev/nvme0n1p1 Aug 8 12:59:23 fractal emhttpd: /mnt/cache uuid: 9e62a0a8-02e6-4e30-9f96-4d413126e2b5 Aug 8 12:59:23 fractal emhttpd: shcmd (47): mount -t btrfs -o noatime,space_cache=v2 -U 9e62a0a8-02e6-4e30-9f96-4d413126e2b5 /mnt/cache Aug 8 12:59:23 fractal kernel: BTRFS info (device nvme0n1p1): using crc32c (crc32c-intel) checksum algorithm Aug 8 12:59:23 fractal kernel: BTRFS info (device nvme0n1p1): using free space tree Aug 8 12:59:23 fractal kernel: BTRFS info (device nvme0n1p1): bdev /dev/nvme0n1p1 errs: wr 0, rd 0, flush 0, corrupt 3, gen 0 Aug 8 12:59:23 fractal kernel: BTRFS info (device nvme0n1p1): enabling ssd optimizations Aug 8 12:59:23 fractal emhttpd: shcmd (48): mount -o remount,discard=async /mnt/cache Aug 8 12:59:23 fractal kernel: BTRFS info (device nvme0n1p1: state M): turning on async discard Aug 8 12:59:23 fractal kernel: BTRFS error (device nvme0n1p1): incorrect extent count for 4778965336064; counted 1519, expected 1512 Would it be worth moving the appdata and system share from cache to array (currently set to array --> cache and previously 'cache only') and then trying to start docker without using the (potentially) faulty nvme cache drive? I also noticed that after deleting docker.img and restarting the docker service, it seems to create system/docker/docker.img but also system/docker/docker/docker.img - is this normal behaviour? Server info: Fractal: 4u rackmount ~ Intel® Core™ i5-10400 CPU @ 2.90GHz ~ Gigabyte B460M DS3H ~ 48 GB Corsair Vengeance DDR4 @ 3200 Mhz ~ 1 TB WD Blue M.2 NVMe ~ 4x 6TB, 1x 2TB, single parity Thanks so much for any help! fractal-diagnostics-20230808-1715.zip
  2. The new USB key is USB 2.0 (old one was USB3.0). The slot it is plugged into is also USB 2.0. I have the non-UEFI boot selected in my BIOS.
  3. **UPDATE** Just ran into the same problem as before on the new USB so I am thinking it is not something to do with the USB now? I had everything back up and running on the new USB. Dockers fine after restoring the .xml - installed minimal plugins (CA, Fix Common Problems). The one thing I did do was change my PCIE-ACS override to "Both" ("downstream" did not give me correct IOMMU groups) and then passthrough my graphics card (Radeon 470), USB controller, and NVMe controller. The first two I have been successfully passing through for a while now. The NVMe controller is the new one that seems to be the problem. Sure enough, after running in Pop!OS on the passed through NVMe for a while, my POP!Os froze up (same as before). I tried to reboot the VM (running with no vDisk but just the passed through NVMe) - the reboot failed and the VM disappeared. I rebooted the server, and the SQUASHFS problems returned. I backed up the USB and did a clean install (on the same USB) - restoring only the network.cfg and Basic.key files to the config folder. After re-assigning my drives, the array is back up and running a parity check (17% - no errors so far). Is this somehow being caused by passing through the NVMe controller? If so, how?
  4. Fixed! For reference for anyone else encountering this: I had to re-install all my plugins - starting with CA and then Fix Common Problems. The latter pointed me to another missing file. After digging a bit in here: https://wiki.unraid.net/Files_on_v6_boot_drive it turns out the configuration files docker was looking for are stored on the USB boot drive in config/plugins/dockerMan/templates-user as a bunch of .xml files. This folder was empty on my new USB. I copied the files across, rebooted, and everything works. I still need to manually install a bunch of plugins but that's fine! Kudos to the unRaid team for building such a robust system and thanks @JorgeB and @trurl for your help! I guess I will write to the kind people at unRaid now to see if they can switch over my serial to the new USB before the trial runs out Cheers
  5. @trurlthanks, I always get confused with the terminology and without being able to see it in front of me, I mixed them up, but you are exactly right. I was going by the (very helpful) "Mover transfers files from cache to array" text, so I did in fact use Cache: Yes to move them. I'll add an edit to my original post for anyone else coming across this! @JorgeB Thank you - I re-assigned the disks according to my DISK_ASSIGNMENTS.txt from the old USB, ticking the "parity is already valid" box - thank you for the reminder! The array is now back up and running (on the new USB). I haven't run parity yet but the files look good in my shares. I now have a few other small problems as I'm running from a vanilla USB: 1. Share preferences did not update - had to manually re-assign appdata, domains and system to Cache: Prefer (thanks @trurl) - I've fixed this but just for the benefit of anyone else coming across it) 2. Docker containers have no thumbnail images and don't seem to be running: I looked in my docker.cfg and found that a bunch of lines were missing including DOCKER_APP_CONFIG_PATH. I stopped docker, clicked into the selector for config path and pointed to my appdata share again (even though the path looked correct). Saved. Rebooted. Started Docker again. That resulted in the below - new docker.cfg on the left, old/original docker.cfg on the right. However even with the cfg seemingly correct it isn't finding the docker configuration (see above screenshot). I have checked in the appdata files and they all look intact, the share is located on the cache drive and set to cache:prefer. Am I missing something? Do I need to restore my docker.img file or something else? Thanks as ever for your help.
  6. When I boot with a vanilla config on a new USB, adding only my super.dat and DISK_ASSIGNMENTS.txt - it produces the same SQUASHFS errors. So I am guessing it is something in those 2 files. Anyway I have now booted into safe mode from a new USB with a clean configuration. Should I just re-assign the drives in the array? I am getting: "All existing data on this device will be OVERWRITTEN when array is started" against the parity drive" - is that normal? Really don't want to kill my array here
  7. Thanks JorgeB. I created a new flash drive, restored the config folder to that and it hits the same issues. If I use the new flash drive without restoring the config folder then I am able to boot in safe mode no plugins. So it looks like it could be something in the config folder?
  8. Hi there, Currently unable to boot into unRaid (in any mode) so my apologies for the lack of logs. I previously had a 1 TB nvme drive as my cache drive and decided to pass this through to a VM and replace it with a 500 GB Samsung EVO ssd. These were the steps I took: - Changed the shares on the cache to "prefer" (appdata, domains, system) **EDIT** Cache:Prefer is incorrect. I used Cache:Yes, see below post from trurl - Ran the mover to move everything to the array - A few files were left behind which I moved manually with the unbalance plugin - Removed the (now empty) nvme drive from the array config - Added the new 500 GB EVO as cache - Changed the shares back to Cache: Only and ran mover again **EDIT** This should be Cache:Prefer - see post below - Array then seemed to be working fine. All good so far. When I was setting up PopOS without a vdisk but passing through the nvme drive, something froze up the entire server, forcing me to do a hard reboot. When the server tried to boot up again (regular, safe, safe gui, etc.) I get a sequence of errors which I **think** are due to being unable to find the system files on my cache drive. Sure enough - in my DISK_ASSIGNMENTS.txt - my old nvme drive is listed as cache, so unRaid is looking on a drive that now has PopOS on it. My question is: What is the safest way to resolve this please? I am able to boot in safe mode with a different USB key created from scratch. Should I re-assign the array drives correctly and then take the super.dat and DISK_ASSIGMENTS.txt file from that and move them to the normal USB key with my licence on it? I tried removing super.dat from my existing usb key and booting but I get the same errors. Thank you so much!
  9. bump - I have the same problem
  10. Bump... could my USB boot drive be dead?
  11. Hi there - I was in the process of trying to pass through an AMD Radeon 470 graphics card to an Ubuntu 20.04 VM and having some trouble with getting it to save the configuration when I hit the update button, I assumed this was down to passing through the graphics and sound portions together related to their IOMMU groups. I had been using the VFIO-PCI Config plugin to remap some of my IOMMU groups to make the passthrough easier and as the current config was giving me problems I decided to switch the mode from "both" back to "downstream". I did this - rebooted the server and then that was it... I can't get it to boot in normal mode, GUI mode, safe mode with GUI, or safe mode (no plugins no gui)....I'm kind of at a loss as to what to try from here. Everything was fine up untill that reboot, no indication of prior issues. Attaching a screenshot of the boot screen that I get to from booting in safe mode (no plugins no gui). Can't SSH in or anything to be able to diagnose so any help as to where to even start would be much appreciated! PS Server config = 'fractal' in my signature below.
  12. I realise the topic is old but for anyone else coming across this - setting up a VM configuration and doing all the software installs and configuration once inside the OS are two separate things. Add a new VM configuration and in Primary vDisk Location select manual and point it to your existing vdisk.img (i.e. the one you've spent ages working in). This is the equivalent of moving a hard drive between PCs and booting from it. Should be just as you left it
  13. ** MARKED AS SOLVED** CA Appdata Backup / Restore did not work for me to fix this unfortunately Solution: Remove and re-create boot drive for the second time. Do not install binhex-preclear (as much as I love their other dockers!)
  14. I couldn't fix this so I recreated the boot USB and started again. Unfortunately the exact same thing happened right after the binhex-preclear docker completed (successfully). As soon as I hit "Done" this is what I get: Everything was solid until then... Diagnostics attached without rebooting this time: nzxt-diagnostics-20200506-0219.zip My /usr/local/emhttp/plugins/dynamix/include/Wrappers.php looks like this: GNU nano 4.6 Wrappers.php <?PHP /* Copyright 2005-2018, Lime Technology * Copyright 2012-2018, Bergware International. * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License version 2, * as published by the Free Software Foundation. * * The above copyright notice and this permission notice shall be included in * all copies or substantial portions of the Software. */ ?> <? $docroot = $docroot ?? $_SERVER['DOCUMENT_ROOT'] ?: '/usr/local/emhttp'; // Wrapper functions function parse_plugin_cfg($plugin, $sections=false, $scanner=INI_SCANNER_NORMAL) { global $docroot; $ram = "$docroot/plugins/$plugin/default.cfg"; $rom = "/boot/config/plugins/$plugin/$plugin.cfg"; $cfg = file_exists($ram) ? parse_ini_file($ram, $sections, $scanner) : []; return file_exists($rom) ? array_replace_recursive($cfg, parse_ini_file($rom, $sections, $scanner)) : $cfg; } function parse_cron_cfg($plugin, $job, $text = "") { $cron = "/boot/config/plugins/$plugin/$job.cron"; if ($text) file_put_contents($cron, $text); else @unlink($cron); exec("/usr/local/sbin/update_cron"); } function agent_fullname($agent, $state) { switch ($state) { case 'enabled' : return "/boot/config/plugins/dynamix/notifications/agents/$agent"; case 'disabled': return "/boot/config/plugins/dynamix/notifications/agents-disabled/$agent"; default : return $agent; } }
  15. On your mac go to Applications > Unraid USB Creator > right click and Show Package Contents > MacOS and run "Unraid USB Creator" - then it should actually run. Not sure why, but works for me **EDIT: Does not work. Double clicking that file will open a terminal with /Applications/Unraid\ USB\ Creator.app/Contents/MacOS/Unraid\ USB\ Creator ; exit; but you actually need to be sudo, when you run with sudo - you get the same error in terminal this time: 2020-05-05 15:02:46.048 Unraid USB Creator[71441:1246371] The application with bundle ID com.limetech.UnraidUC is running setugid(), which is not allowed. Exiting.