-
Posts
61460 -
Joined
-
Last visited
-
Days Won
646
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Report Comments posted by JorgeB
-
-
This is a plugin, not part of the OS, please use the existing plugin support thread:
-
Recommend changing the docker network to ipvlan, if you really need macvlan disable bridging for eth0, more info here:
https://docs.unraid.net/unraid-os/release-notes/6.12.4/#fix-for-macvlan-call-traces
-
No, Unraid cannot mount ntfs, you can keep passing through the device to a VM, or format it with a supported filesystem if you want to use it in a pool.
-
50 minutes ago, Maitresinh said:
Microsoft basic data
This is a Windows filesystem, so it will never mount with Unraid, maybe you were passing through that device to a VM?
-
This looks more like a general support issue, post the output of:
blkid
and
fdisk -l /dev/nvme1n1
-
Memtest is only definitive if it finds errors, if you have multiple sticks try with just one, if the same try with a different one, that will basically rule out bad RAM.
-
Btrfs is detecting new data corruption, since memtest is only definitive if it finds errors, and since you have multiple sticks, fix the corrupt files and reset the stats and and try with just one stick of RAM, if the same try with a different one, that will basically rule out bad RAM.
-
Unfortunately there's nothing relevant logged, this usually points to a hardware issue, one thing you can try is to boot the server in safe mode with all docker containers/VMs disabled, let it run as a basic NAS for a few days, if it still crashes it's likely a hardware problem, if it doesn't start turning on the other services one by one.
-
You can downgrade to a known good release and re-test, or run memtest in case there's a bad DIMM.
-
Unraid driver crashing is almost always a hardware issue, though there have been users that only saw them with a specific kernel/release, is this a new server, or one that was previously running fine with this release?
-
OK, going to close this for now, please re-open and let us know if you find anything else.
-
I cannot reproduce that, are you sure the share settings used were those? Or that the dataset didn't already exist?
Creating a new share with primary storage set to a pool only creates the dataset in the pool:
Try deleting the share and recreating again double checking the settings
-
What were the share settings for that share when it was created? You can post a screenshot of the current settings if they were not changed.
-
1 hour ago, JorgeB said:
Run a scrub and delete/restore from a backup the corrupt files,
Also make sure you do the above, and reset the btrfs stats to see if new corruptions are detected.
-
Diags appear to be after a reboot, when it happens again post new diags before rebooting.
Also see that btrfs is detecting data corruption in the pool:
Apr 14 16:58:16 Tower kernel: BTRFS info (device sdb1): bdev /dev/sdb1 errs: wr 0, rd 0, flush 0, corrupt 526, gen 0
Run a scrub and delete/restore from a backup the corrupt files, also a good idea to run memtest
-
Update the Chinese language pack or uninstall and re-install.
-
Enable the syslog server and post that after a crash, together with fresh diagnostics.
-
Apr 12 11:44:20 Netheril kernel: BTRFS info (device sdb1): bdev /dev/sde1 errs: wr 2244, rd 14, flush 285, corrupt 2142, gen 0
This means one of the pool devices dropped offline in the past, run a correcting scrub and check that all errors were corrected, also see here for better pool monitoring.
-
Changed Status to Solved
-
Still constant crashes, this looks like an hardware issue to me, if it's not RAM the next suspects would be board or CPU.
-
Not seeing anything logged that points to a software issue, one thing you can try to run the server with a single RAM stick, if the same try the other one, that will basically rule out a RAM problem, you can also boot the server in safe mode with all docker containers/VMs disabled, let it run as a basic NAS for a few days, if it still crashes it's likely a hardware problem, if it doesn't start turning on the other services one by one.
-
Enable the syslog server and post that after a crash.
-
If you really need macvlan you can still use, just disable bridging for eth0, for more info see here:
https://docs.unraid.net/unraid-os/release-notes/6.12.4/#fix-for-macvlan-call-traces
-
Apr 9 22:29:07 Tower kernel: macvlan_broadcast+0x10a/0x150 [macvlan] Apr 9 22:29:07 Tower kernel: ? _raw_spin_unlock+0x14/0x29 Apr 9 22:29:07 Tower kernel: macvlan_process_broadcast+0xbc/0x12f [macvlan]
Macvlan call traces will usually end up crashing the server, switching to ipvlan should fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enabled, top right)), then reboot.
[6.12.10] User scripts - Rename file not working
in Stable Releases
Posted
Changed Status to Closed
Changed Priority to Other