zoggy

Members
  • Posts

    648
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

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

zoggy's Achievements

Enthusiast

Enthusiast (6/14)

21

Reputation

  1. For me I just had to go re-select the probes in settings > system temp. since the sensors names changed as newer linux kernel has better support for my mobo.
  2. after upgrading to 6.10 stable, when i go to "stats" it logs an error in unraid syslog:
  3. sharing above PSA since sandisk are not advisable. but anyways, since the drive is working for you it makes me just think your boot partition just needs re-doing once you have 6.10 installed. try running make_bootable script for your os.
  4. gt = guest tools for more info: https://github.com/virtio-win/virtio-win-guest-tools-installer
  5. If you actually click on the link the kernel bug report you would see that yes, while the mobo are similar one has to add the mobo string to the appropriate driver to make it the sensor info work. Its comically stupid and does not scale, which is about half of the chatter about with how dumb getting sensors data with asus is. Then if you would have clicked on the link I shared about the driver you would see even further proof of this. How even different variations of the same board have to be added due to how its checked. snippet: As you noted what mobo you have, can see others reporting same issue: ROG STRIX X570-F GAMING - https://bugzilla.kernel.org/show_bug.cgi?id=204807#c112 Your hwinfo noted that card has NCT6798D but nct6775 driver is to be used. While sensors-detect knows to associate the NCT67* to nct6775 it doesnt mean that the driver fully supports your mobo. Some of it is deciding which method to get the sensor data and which can use wmi and so on, where the whole whitelisting mobo name comes into play. Looking at that linux driver history for nct6775, can see that "ROG STRIX X570-F GAMING" was added: 2021-10-12 - https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/commit/drivers/hwmon/nct6775.c?id=6e2baac88cddbb440095c45058bc666df3108a1f Then you would have to see what kernel that then made it into, and if you are using it. Which is why I asked the other use if you just tried newer linux kernel to see if it works. As I've been in this same boat, where I had 0 support and then newer kernel exposed some sensor data.. so now I get cpu temp but still no mobo or fans (until 6.10x)
  6. you can just start the system up with newest rc, just dont start array if your worried about anything with your data/dockers/etc. then check to see if sensors/fans etc are working so you gather data and know. then revert back to stable release for actual peace of mind and daily use.
  7. unless you are both using the same motherboard then i dont see how you can use the logic that it wont make a difference. as ive even linked proof that x boards had improvements in detection of wmi sensors via kernel update.
  8. you should try upgrading to next release (6.10rc4) and see if everything is magically supported for ya (as it includes much newer linux kernel/drivers/etc).
  9. i would not recommend the acpi_enforce_resources=lax i've tried that before and it caused unraid to fail to boot until removed. which lead me to find this: about asus and the buggy issues with reading fan/temps: https://bugzilla.kernel.org/show_bug.cgi?id=204807 oct 2021 - lot of asus wmi boards got supported via NCT677x: https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/commit/?id=cd0b8e410937 so basically you just have to wait for newer kernel to get better support. you using 6.10rc3 ?
  10. for dynamix.system.temp -- noticed that this shows up in the unraid logs on unraid 6.9.2:
  11. In unraid, Settings > Management Access > Local TLD unraid's help says: Enter your local Top Level Domain. May be blank. But in FCP it is unhappy about a blank TLD. Easy enough to ignore, but I do not recall it used to complain about this.. is there a recent unraid change that requires the user to set this now?
  12. To note small change in output formatting, original gfjardim plugin had the time/speed/result right aligned: # # # Step 1 of 5 - Pre-read verification: [0:32:00 @ 417 MB/s] SUCCESS # # Step 2 of 5 - Zeroing the disk: [0:45:02 @ 296 MB/s] SUCCESS # # Step 3 of 5 - Writing unRAID's Preclear signature: SUCCESS # # Step 4 of 5 - Verifying unRAID's Preclear signature: SUCCESS # # Step 5 of 5 - Post-Read verification: [0:25:24 @ 525 MB/s] SUCCESS # # # # # ############################################################################################################################ # Cycle elapsed time: 1:42:29 | Total elapsed time: 1:42:29 # ############################################################################################################################ With new 'enhanced' version it is not: # Step 1 of 5 - Pre-read verification: [0:30:36 @ 436 MB/s] SUCCESS # # Step 2 of 5 - Zeroing the disk: [0:44:05 @ 302 MB/s] SUCCESS # # Step 3 of 5 - Writing Unraid's Preclear signature: SUCCESS # # Step 4 of 5 - Verifying Unraid's Preclear signature: SUCCESS # # Step 5 of 5 - Post-Read verification: [0:25:27 @ 524 MB/s] SUCCESS # # # #################################################################################################### # Cycle elapsed time: 1:40:11 | Total elapsed time: 1:40:12 # #################################################################################################### So far everything looks to be running the same, similar speed and no issues so far.
  13. The came from an outside source and I want to validate them. They are enterprise ssd with pretty high tbw, so doing a full drive write is trivial for them.
  14. I was noting that the change of going from preclear to UD Preclear means that I had to do an extra step now to get UD+ to remove the partition to clear, which is a change. Once a user is familiar with the process and the initial steps of getting UD, UD+, UD Preclear installed then it is not a huge deal.
  15. if a usb drive isnt booting its generally because its boot loader isnt right. you can either re-run the unraid usb creator ( https://unraid.net/download ) or just run the make_bootable file with it attached to your machine. now if its really only when that hdd is connected, perhaps its one of those esata/usb ports where they share and only one can be operational at once.. but not clear if your connecting the usb to external port or off usb header on the motherboard (which is whats recommended). if its external, move it to another usb port..