ryoko227

Members
  • Posts

    161
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by ryoko227

  1. On 12/6/2023 at 5:14 AM, FoxxMD said:

    did you take any precautions/upgrade prep other than backing up your flash drive? I need to upgrade from 6.11.5 as well.

    Aside from what the others have suggested, I only make sure I have the flash backup on a separate PC just incase I need it. Follow any of the release notes instructions. I generally ensure all my plugins and dockers are up to date and go for it. Afterwards, I go through the system log and make sure there are not any new or weird errors. That's pretty much it for me, but hope that is helpful to you.

  2. On 4/20/2023 at 3:59 AM, djismgaming said:

    This configuration is also missing the usual PUID=99 and PGID=100 variables for writing files in good permissions for the share, just in case you encounter issues while accessing the files from another Obsidian installation in your PC.

    I fought for 2 days with Syncthing and my phone (was thinking it was a Syncthing issue) trying to get passed some permission denied issues. Noticed the files and directories this would make were all authored as UNKNOWN. Ultimately I just ended up installing it via the Obsidian official windows installer into my VM, no sync or permission issues after that. I love the idea of running it in a docker though.

    • Upvote 1
  3. Update-
    Seems to have been an issue with my PC or browser. Had no issues with it today.

     

    Unable to type, nor paste Japanese characters into the search bar while looking for a file to restore. 

    The file names all show correctly in Japanese, but I would like to be able to search them in Japanese as well.

    Am I missing something? Am running on Version: 6.11.5

     


    image.thumb.png.0bfb6385bb30a7258ea87163111aa97f.png

  4. I don't know if this "the right way", but I got to the odoo webUI doing the following. Hopefully it is helpful to you or someone else, and it's here for me when I need it later ^^;

     

    Reference per @Thomasg - "Used the sauce from : https://registry.hub.docker.com/_/odoo/"

     

     

    Firstly, install PostgreSQL 15 via your unRAID Apps and set as follows...

     

    Name  - db    <---- per the reference "The alias of the container running Postgres must be db for Odoo to be able to connect to the Postgres server."

    POSTGRES_PASSWORD: Set a password you think is strong, I used a 16 chars alphanumeric from a rnd generator
    POSTGRES_USER: odoo
    POSTGRES_DB: postgres

     

    Next, install the Odoo15 from your unRAID Apps and set as follows...

     

    Addons: /mnt/cache/appdata/odoo/extra-addons  <--changed these to /mnt/cache/appdata/   to hopefully keep it all in an easy to find/use space.
    Configuration: /mnt/cache/appdata/odoo/config  <--changed these to /mnt/cache/appdata/    to hopefully keep it all in an easy to find/use space.
    DB Username: odoo
    Database Password: Previously entered strong password from above
    Database URL: your unRAID server IP

     

    And that seems to have worked for me. Hope it helps o/

  5. I'm not sure if this is relevant to the OPs issue or not, but right now, my current work around for naming IPs over WireGuard, is just to add the record to PCs that we use remotely's Windows Host file. It has no problems pulling up network mapped drives, etc. when done this way.

     

    I'm sure there has to be a more elegant way of doing this though, maybe in the wireguard config file?? It seems that everyone is just forwarding to either piHole or pfense though, as everything I Google to try and find an answer, relates to those.

     

    If someone knows how to do this directly in the Wireguard config files, that would be greatly appreciated.

     


    (note) networks are multiple unifi usg3s, using jsons directing the naming across IPSEC tunnels. Changes to those break that functionality

  6. On 6/4/2022 at 3:27 AM, John_M said:

     

    Check the value of Settings -> Notification Settings -> Plugins update notification. I have it set to Check once a day. You probably have it set to Never check.

    Thanks, that fixed it! Now when I open the Plugin tab, it checks the status.

  7. Updated the office server from 6.8.3 -> 6.10.2, seems like no issues so far!

     

     

    UPDATE-

    Couldn't get the VM to reboot without black screening the system, ended up bonding the GPU and USB Controller via the VFIO-PCI option in System Devices. This fixed that issue. Also was finally able to remove the "Docker - Case Insensitive" fix from the go file.

     

     

    UPDATE 2-

    In the Plugin tab, they show as status unknown everytime, until I click check for updates.

    Solved by this ....

      

    On 6/4/2022 at 3:27 AM, John_M said:

     

    Check the value of Settings -> Notification Settings -> Plugins update notification. I have it set to Check once a day. You probably have it set to Never check.

     

     

    Final issue being, Nerdpack is showing "kbd-1.15.3-x86_64-2.txz" and "mcelog-161-x86_64-1.txz" as being "update ready" even though neither of those exist on my flash device under the 6.10 nerdpack plugin folder.

  8. On 5/18/2021 at 5:35 PM, jademonkee said:

    Worth a shot: did you clear your browser cache?

    Does the Android/iOS app still work?

    Unfortunately I tried that as well as connecting from differing machines that normally do not have access. No joy. I ended up reverting back to 6.8.3 due to other issues, but won't be able to mess with the docker till next Tuesday.

     

    UPDATE (solved) - Seems to have been a corrupted image. Moved the appdata to another share, removed the image, reinstalled via template, copied the appdata back over, used the controller's autoback file from the beginning of the month to restore everything. 100% back up and running.

  9. Updated unRAID 6.8.3 -> 6.9.2 and now get a "ERR_CONNECTION_REFUSED" when trying to access my unifi 5.14.23 docker webui. The docker log shows no errors messages. So I tried: removing and redownloading the docker, completing deleting the docker image, reverting to 6.8.3, etc. Tried playing with the webui ports in the docker, but it just spits out the same error. The tunnels I have to offsite USGs are still up and according to their webui's, "The UniFi Controller is currently unreachable." TBH, not sure if this is a 6.9.2 issue, or an underlying issue that happened to pop off when I tried the update. Has anyone else run into this or has a suggestion on where/what I can try?

  10. 2 hours ago, BrianB said:

    Starting to wish I hadn't clicked "upgrade."

    Unfortunately, based on your described symptoms, coincidental failure at the same time you happened to be updating/rebooting your unRAID. If you are not getting POST of any kind, then this points to your hardware/bios. At minimum when you start a PC you should get a post screen. If you are getting nothing on a confirmed working monitor, then you need to dig deeper. Firstly, pull your unRAID USB out and set it off to the side, you won’t need it right now. Your goal is to get the PC to properly boot, then worry about whether your unRAID works.

     

    There are many things that could be wrong when you get a solid black screen/no signal. If your MB displays post codes, check your manual to see what they mean and follow the troubleshooting steps. If the MB is older and doesn’t have this feature (nor a pc speaker), you might want to look into the following….

     

    BIOS – may have gotten corrupted (pull all power, hit bios/cmos reset button (if your MB has this) or hold in the power button) plug it back in and see if it will boot.

    GPU – may have died, or gotten unseated while you have been working on this (try pulling it out and reseating, additionally, you could try it in a different slot). If you have another PC nearby, verify the GPU works by tossing it into the other machine to see if you can get a post screen.

    Memory – reseat all, still nothing? pull all out, try each dimm one at a time in different slots (try to see if you have a bad dimm).

     

    This is a process of elimination to try and find the fault in your PC. I think the above is enough for now, if none of the above solves it, let us know and we will try to go from there.

     

     

    PS – Truth be told, I had a CMOS battery die on me once, and after a simple reboot it borked my bios and I had to reset like I mentioned above. With constant power, that shouldn’t be possible, but meh, tech stuff so…. Best of luck.

  11. Smooth update on the Home server from 6.8.2->6.8.3. The new kernel fixed my nvme IO_PAGE_FAULT issue, which is awesome!! I was also able to easily get the AMD cache thing running on my VMs with a simple Edit->Update to each of them. Awesome work as always Limetech!

     

    EDIT/UPDATE: Work server also updated from 6.8.2->6.8.3 with no issues.

  12. On 2/12/2020 at 2:18 AM, bland328 said:

    Did you end up opening an issue on this? If so, I'd love to contribute to it, at least in the form of a +1, as I really need to get IOMMU going again and patching the kernel myself sounds at least...unwise. I mean, it sounds kinda fun, but mostly unwise ;)

    Sorry I haven't gotten back to you on this!!! I agree with you on the kernel patching (way outside my bredth), www. I haven't had a chance to update unRAID to 6.8.3 yet, but the kernel for that is ...

    Linux kernel:
    
    version 4.19.108 (CVE-2020-2732)
    kernel-firmware: version 20200207_6f89735
    oot: wireguard: version 0.0.20200215

    I hopped back over to bugzilla, and according to Comment 111 , it's been commited. Here's a quote for brievity...

    Quote

    Comment111nutodafozo 2020-01-01 16:15:33 UTC

    Commit 'nvme: Discard workaround for non-conformant devices' have been applied to 5.4 and 4.19 stable kernels, i.e. 5.4.7 and 4.19.92.

     

    Comment 112hamelg 2020-01-02 19:15:31 UTC

    I've just upgraded to 5.4.7. I confirm the issue is solved :)

     

    Comment 113Andreas 2020-01-03 09:07:02 UTC

    Thanks for including the fix in 5.4.7, tested on Gentoo with gentoo-sources of the kernel.

     

    Comment 114MasterCATZ 2020-01-09 02:39:38 UTC

    5.4.8 and working

    So, I would think that (haven't tested yet) it *should* be fixed with an unRAID update. When I get around to updating the system with the issue, I'll edit/post the results!

     

    EDIT/UPDATE - No more errors with the 6.8.3 update on mine 🥰

  13. On 12/5/2019 at 12:50 AM, binhex said:

    Alternative approach to changing to SeaBIOS or switching to Cirrus:-
     

    1. mount iso for 'live cd' and boot vm

    2. once you get to the grub menu press 'e' and append the following, failure to do this will mean you wont be able to boot to x windows:-

    
    systemd.mask=mhwd-live.service

    3. press ctrl+x to save this change and the vm should boot.

    4. once booted then install to vdisk and shutdown (do not reboot it will get stuck unmounting iso)- may require 'Force Stop'

    5. once shutdown edit vm and remove the iso

    6. start vm, this will get stuck at a black screen, you now need to press ctrl+alt+F2 in order to get to command prompt

    7. login with root and the password you defined.

    8. issue the following command to remove the symlink to mhwd - note this cannot be done at step 4. as the symlink does not exist

    
    sudo rm -f /etc/X11/xorg.conf.d/90-mhwd.conf && reboot

    9. enjoy manjaro! - tested on 'cinnamon' and 'openbox' editions of manjaro.

    Thank you for this!! I can confirm this works and got Manjaro 18.1.5 KDE Plasma running using binhex's method.

  14. On 12/16/2019 at 5:35 PM, itimpi said:

    I do not believe that the error is Unraid specific (and that it is actually a Linux kernel issue), it is just that the type of workloads frequently run on Unraid servers seem prone to triggering it.  We should see a fix incorporated into the 6.9 Unraid release for which the first RC is reported to be imminent.

    ※Related to the "unexpected GSO type" issue on unRAID 6.8※

    Yes, related to unRAID's specific workload, hence the reason I worded it the way I did and linked what Tom wrote on that topic. For clarification, Tom in his own words... "This implies the bug was introduced with some code change in the initial 5.0 kernel.  The problem is that we are not certain where to report the bug; it could be a kernel issue or a docker issue.  Of course, it could also be something we are doing wrong, since this issue is not reported in any other distro AFAIK."

     

    On 12/16/2019 at 7:39 PM, testdasi said:

    I believe the SM controller patch was already included in 6.7 (so should still be in 6.8).

    The Intel controller I haven't seen a patch.

     

     

    That link is related to passthrough of an NVME device and was a seperate issue that has been resolved to my knowledge. The problem that we are discussing is related to IO_PAGE_FAULT being thrown when a NVME is trimmed, specifically to users who need to have IOMMU enabled. The current kernel patch information is located here https://bugzilla.kernel.org/show_bug.cgi?id=202665#c105

     

     

    On 12/17/2019 at 1:21 AM, bland328 said:

    Thanks for the update, @ryoko227. If/when I get some time, I'll also put some work into this, and will post here.

     

    EDIT: For the record, I'm on an ASUS PRIME X370-PRO + AMD Ryzen 5 2600, with a 500GB Kingston NVME drive in the motherboard slot, formatted BTRFS, and unassigned. Turning off IOMMU in the BIOS does stop the flood of page faults, but I need to turn that back on soon 😅

    Awesome! It looks like from the latest update on https://bugzilla.kernel.org/show_bug.cgi?id=202665#c107 that you need to build a custom kernel with the patch applied to it. I've never attempted that, but to be completely honest, I don't know how one would apply that into unRAID, www.

    • Thanks 1
  15. On 12/15/2019 at 1:42 AM, bland328 said:

    Just learned I'm also affected by this, and do need to keep IOMMU turned on.

     

    @ryoko227, did you have any luck with the patch? 

    I actually never got around to trying it TBH. The newer versions of unRAID were slated to jump into the 5.x kernels, so I was just holding off hoping that it would just come down the pipe, www. Unfortunately 6.8, with the 5.x kernels are having some new, weird, unRAID only error that was mentioned in this post "UNRAID OS VERSION 6.8 RELEASE PLAN"... so... I will have to look into this patching again when I get some free time.

  16. I know this is marked SOLVED, and that johnnie.black linked the bugzilla bug id in which it is being talked about, but since some people might find this topic who DO need to have IOMMU enabled, I wanted to give a quick update on the IO_PAGE_FAULT issue. From the bug ID in question, it seems this to not be specific to AMD, but more to the controller. There are from what I gathered, 2 different patches based on the Phishon controllers & the Silicon Motion controllers. This stuff isn't my forte, but they seem to be kernel patches.

     

    https://bugzilla.kernel.org/show_bug.cgi?id=202665#c87

     

    I also have a ASX8200PNP like someone on bugzilla that is kicking the IO_PAGE_FAULT when trimmed. So I plan to try out the patching they are talking about, and if it clears up my issue I guess ask unRAID to add the patch till this gets sorted on the kernel side of things.

  17. ^ agree with everything above. Unifi is the one docker I never rarely update, it just sits there staring at me. Watching the utter S-Storm when new "updates" (if you can call them that) come out over on their forums. Awesome hardware, terrible (most often broken) software. Still sitting on 5.8.3 since that's the last stable I've had 0 issues with. Love LIO for their hardwork trying to keep everything up and running though for us. o/