kana

Members
  • Posts

    24
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

kana's Achievements

Noob

Noob (1/14)

0

Reputation

  1. I cannot second that. I run Big Sur on my Bare Metal Ryzen 5600X, and it's rock solid. A virtual machine, once configured correctly, shouldn't be worse. However, all the reports here of the issues with the new MacInABox version have convinced me I rather wait with my VM installation until that has settled.
  2. kana

    Kernel Panic

    Wasn't aware of that, I have changed the settings according to these hints and will observe it for the next days..
  3. kana

    Kernel Panic

    I do have a Ryzen based server. It would work fine at first for the first months, but along the line while installing programs, extensions, plugins and beta OS, it would start crashing. There was no HW change since. I attached the diagnostic zip file to my original post.
  4. kana

    Kernel Panic

    I'm running 6.9.0-rc2 and I regularly (after a few hours) and reproducibly get a kernel panic. That even happens when no share is mounted on any external computer, so it's unlikely that any share services have to do with this. However, it is possible that the parity check is running at that time. Usually the connected monitor is blank, but this morning it showed the last log output on the screen which I attached. Is there anything in the log that catches your eye? BTW, I found out only this morning how to enable the syslog mirror on the flash which I activated, so I'm hoping to get more information soon. Update: attached diagnostis zip file unraid-diagnostics-20210106-1127.zip
  5. Ouch, that easy.. I don't have any (the nerd tools is the only plugin whose description shows ssh*, but that shouldn't count). Seems I'm stuck now.
  6. Same problem, no solution here yet. The delete /boot/config/ssh part is clear, but what are ssh plugins and how would I delete them? I'm on 6.9.0 beta 35.
  7. My data storage path indeed points correctly to /mnt/user/appdata/gitea, but I still see the same issue, all context is gone after an update. When I look in /mnt/user/appdata/gitea/gitea, I see gitea.db which has not changed for 16 days now (I made approximately 10 updates in that time), and inside the "sessions" folder I see several folders with time stamps all before my today's commit, some are several days old, so the data itself seems to be persistent. Looks like gitea loses the ability to access that data with every update. Can the reason be that I'm using unraid 6.9.0-beta35 rather than the official version? Oh, btw, the command section of the Gitea update windows shows me "root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='Gitea' --net='bridge' -e TZ="Europe/Berlin" -e HOST_OS="Unraid" -p '3022:22/tcp' -p '3000:3000/tcp' -v '/mnt/user/appdata/gitea':'/data':'rw' 'gitea/gitea' da7e22c307253a32b7c2a0121a80a97ccba831315ec2a698d56cb8f678077d12 The command finished successfully!" The reference to the appdata folder in there looks ok, I see no indication the update itself screws things up.
  8. I recently installed Gitea. This container seems to be upgraded every day, and with every update, Gitea gets installed anew, so the users and repositories, everything is gone. Do I have to backup/restore it manually before every update?
  9. Is there no more support from dmacia for this plugin? I'm having the same issue for several weeks now (I'm on the Unraid beta). Aas for the reddit post: there is one post deleted, is it right to assume the did something with pihole? I do not have pihole installed, so it can't be that in my system.
  10. "Not specifying multiple default gateways", what you are actually suggesting, is exactly what my command line accomplishes by deleting superfluous ones, so why do you call it wrong? Besides, regardless of the issue at hand, the GUI in general seems to have a bug that prevents you from deleting routing entries, for that, my proposed command is a working way indeed and thus not wrong. [EDIT] Sorry, now I got you, you were referring to 905jay's screenshot with still two gateways in it and not my suggestion. Never mind... @905jay I'm pretty much a beginner myself, so I think @ken-ji 's suggestion to have only one default route in the system and specific routes for the others is perfectly sufficient and does the job.
  11. I've had the same problem. Try the command line to delete it. This command may or may not be right, you might have to play around with it: ip route del default via 10.15.83.1 dev br2
  12. I had similar problems that were due to wrong routing using more than one NIC. Can you post a screenshot of the bottom part of the network config with the routing? What exactly do you see when you ping/traceroute out? Is there a difference between IP adresses and host names?
  13. I'm quite a newbie, so I'm not sure this is a bug (actually several bugs), but I believe it is. My setup is a motherboard with an internal NIC connected to the internet and a Solarflare Card with 2 NICs, one connected to just a single host on the other side. Consider the network configuration on the screenshot eth0 is pretty straightforward with DHCP setting, however, eth1 has assigned a static route, no gateway (0.0.0.0) and a metric of 255. The issue now is how this seems to be interpreted in the routing (see 2nd screenshot). The 1st probable bug in "eth1 via 255" is that the metric "255" is somehow misinterpreted as an interface or an IP address. The 2nd bug is that I cannot delete this route with the trash icon next to it. It asks for confirmation which I give, but nothing happens. An "ip route" command yields ip route default via 192.168.1.1 dev br0 proto dhcp src 192.168.1.2 metric 1 default dev eth1 metric 255 192.168.1.0/24 dev br0 proto dhcp scope link src 192.168.1.2 metric 1 192.168.2.0/24 dev eth1 proto kernel scope link src 192.168.2.3 The command ip route del default dev eth1 is able to delete the route indeed. There is another presumed 3rd bug, that is after I had added the network card and rebooted Unraid, it was unreachable from the outside world. I had to log in locally and noticed that the network setting was completely screwed up (DHCP wasn't enabled anymore, so I had to statically assign the IP and, due to my incapability to resolve it on the command line, would then use the GUI network settings to adjust it again). Can somebody confirm these are bugs?
  14. In some cases, namely the Macinabox VM, the configuration in the GUI may and will destroy entries in the underlying XML, the two ways are incompatible. Many users have fallen into this trap, the impact is not low. The best solution would be to have the GUI only touch the sections in the XML that it is asked for. If that is not possible, maybe the next best solution is to have a switch where the config GUI can be completely disabled by the author so that only the XML editor can be used.
  15. Ok, it was not obvious to me that this is a restriction in Unraid and not in MacInABox. Will do! [update +15min]: the Forum is "Feature Requests". You are welcome to add your thoughts about impact, possible solutions etc.