Glycerine

Is the layout for UD decided in the plugin or inheriting from elsewhere? On latest Firefox and safari, noticed the UD items did not have the left margin space other items have (see the difference in attached screenshot between the flash drive menu and UD. Particularly "DEVICE" title and device entry/icons)

Thank you. That didn't occur to me since the debian.org were http. Figured it was a key that wasn't getting downloaded. And the ubuntu docker works without that. However, while that "can't be done securely" error no longer exists, I keep getting 404 errors for the particular additional repos I've enabled; amd64 for the vm and arm for the pi's. This seems like an apt/apt-mirror configuration error rather than something with your container however. I'll go hunting through the docs and report back for others if i find the issue. Thanks for your help @ich777

Pulling my hair out a bit trying to get the debian-mirror working. I keep getting apt update errors on the theme of: Ign:1 http://192.168.1.21:980/debian bookworm InRelease Ign:2 http://192.168.1.21:980/debian bookworm-updates InRelease Ign:3 http://192.168.1.21:980 bookworm-security InRelease Err:4 http://192.168.1.21:980/debian bookworm Release 404 Not Found [IP: 192.168.1.21 980] Err:5 http://192.168.1.21:980/debian bookworm-updates Release 404 Not Found [IP: 192.168.1.21 980] Err:6 http://192.168.1.21:980 bookworm-security Release 404 Not Found [IP: 192.168.1.21 980] E: The repository 'http://192.168.1.21:980/debian bookworm Release' does not have a Release file. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details. Source file: deb http://ftp.us.debian.org/debian bookworm main contrib deb http://ftp.us.debian.org/debian bookworm-updates main contrib #local mirror #deb http://192.168.1.21:980/debian bookworm main contrib non-free #deb http://192.168.1.21:980/debian bookworm-updates main contrib non-free # security updates deb http://security.debian.org bookworm-security main contrib # local mirror #deb http://192.168.1.21:980 bookworm-security main contrib That works as is as it should on a bookworm VM. If I comment out the debian.org and uncomment the local mirror pieces, i receive the errors above. Ping, curl etc. to that IP/port works. What I have done: mirror.list edits - Uncomment the amd64 and armel architectures. Changed armel to arm64. (Have some rpi's running around i want to also update. Verified they're using arm64 with dpkg --print-architecture. They show similar errors on apt update. Blown away docker, config, image and repo download and started from scratch. No joy. I also have the ubuntu mirror docker setup separately (read a comment in this thread about that being best practice) and it works flawlessly. Only other item of note is i've read in this thread and others about cnf issues with the ubuntu docker. Upon reinstall/fetch of packages of the debian docker, i noticed this in the docker log: Processing cnf indexes: [CCC] Downloading 0 cnf files using 0 threads... Begin time: Sat Jan 27 02:01:47 2024 [0]... End time: Sat Jan 27 02:01:47 2024 Again, ubuntu mirror docker works flawlessly. And from what i can tell the apt-mirror version in the debian docker is 5.4.2 which contained the fix for the cnf download issues. Any ideas where to look for a solution?

Moved the card over a slot and got 8x in BIOS, but speeds were still wonky. Placed new HBA card into that same slot, still at 8x, and getting a solid 150MB/s on parity with a total of 2.7GB/s r/w. I would think this means it's running at 4x since 8x ought to be around 4.5GB/s total unless UNRAID itself is slowing down the reads? Maybe because two parity? 150MB/s seems to be the mark on a majority of parity speeds i've seen here so I'm assuming it's running full speed. Just over a day estimated to do 16TB dual parity check In either case, i'm chunking this up to HBA HW failure and marking as resolved.

Well it's finally completed its rebuild and i was able to poke around once more. It's definitely something in the card. BIOS reports the M1015 as 1X PCIe. That jives with what i saw at the end of the rebuild, where it was reading from one device and write speeds went up dramatically, but total read/write stayed within that 500MB/s total. At this point, i think the card is roasted unless there's other ideas? I have a new one coming this weekend and should be able to test then.

Hmm nothing should be writing to the array. Did you mean disk12? That's the data drive that's being rebuilt. I've shutdown the VM service. Docker shouldn't be writing to the array but it does have a process going with an unassigned drive at the moment. Will shut that down too when complete to see if there's any effect. Thanks! EDIT: Disabling Docker/VM had no effect. I really think it's something to do with the HBA. Waiting on a replacement to confirm...

That's what I was kinda wondering. If i hit some sort of limit on the number of array drives. It's just seems like an odd coincidence that 500MB/s is the top, since that is the top speed of PCI 1x. If it was at 8x, it should be giving me the numbers i got before. I think my m1015 is silently failing. Got 850W PSU so it should have enough juice for everything and then some. Got another m1015 on the way to test and will update afterwards, but i think you and I might be in the same boat. Hopefully this fixes it and i won't have week long parity checks any more

I've got 2 parity disks (16TB Seagate ST16000NM001G's) connected to the main board (supermicro X10SLM+-F SATA 6G ports), and various array disks (shucked WDs and a few Seagates) connected to Norco 4224 backplane via flashed m1015 and RES2SV240 expander. A while back I upgraded the parity disks to those 16TBs. Adding first went really slow for rebuild (26 MB/s), but the second parity went around 220 MB/s (as it had been doing regularly before the upgrade). Since added a couple of 16TB seagates and seeing the 26MB/s again during parity checks and now a rebuild. All disks are CMR, verified write cache on for everything with sdparm, m1015 has no error LEDs or anything in the log i can see and is in the 8x slot. Turbo write doesn't seem to do anything but i tried toggling it off auto anyways. Nada. Overall reads during the parity check/rebuild show at 500 MB/s and 26MB/s write to the disk. When writing to/between unassigned disks (attached via m1015/RES/backplane, i get 250 MB/s writes. Is 500MB/s some cap on my HBA? I thought maybe a breakout cable is having issues but i don't see anything obvious, or possibly the PCI slot is at a slower speed (nothing in BIOS to manually set 8x that was obvious to me). Everything is snug in its slot or connector. All the above is what i've been able to figure out to check from the forums here, however now i'm stumped. Anything else i should be checking? wolfwood-diagnostics-20230325-1650.zip