12 hours ago, SimonF said:

How much free space do you have on the flash drive?

Found it, the USB drive is dying and need to be scanned in Windows. Going to do a replacement USB drive and try again

11 hours ago, SimonF said:

Would be nice to see pictures of original hardware.

This is the baby 🙂. 17 years young this month!
MD-1510/LI Gallery
Back when LT even built and tested the HW (I still went with Greenleaf for my 2nd box, having an experienced outfit put one of these things together is invaluable).
Was just taking a look last night at how I could use the other 2 DIMM slots and double the RAM 4->8 GB. Might come in handy yet.

Edited March 1Mar 1 by magic144

11 hours ago, itimpi said:

Tmux is a good alternative to screen and is already installed if you have the UD plugin (as most users do). There is even a tmux plugin to make it easy to handle tmux sessions.

Oh cool, thanks! I didn't realize. And funnily enough I just installed UD on here today too, since I have it on my newer array (not only, but also, for its little sibling, UD Preclear).
I still remember the good old days of having preclear_disk.sh as a manual script (provided by Joe L) and fighting through a series of Unraid OS updates to try and keep it working 🙃

Edited March 1Mar 1 by magic144

Upgrade no problem

Uneventful upgrade from 7.2.3 to 7.2.4.

Update went smooth and fast .

Thank you! =)

Since updating to v7.2.4 my server icon is missing, can this be fixed somehow?

Choosing a different server icon does not work permanently:

42 minutes ago, Taramu said:

Since updating to v7.2.4 my server icon is missing,

It's a known issue for custom images; it should be fixed for the next release. You can follow the progress here: https://product.unraid.net/p/case-model-is-broken-on-login-page

After the update the Pool, Disks and Arrays are not being displayed. Shares seem to work.

57 minutes ago, r_J said:

After the update the Pool, Disks and Arrays are not being displayed. Shares seem to work.

Try booting in safe mode or using another browser; if the same, please create a new topic in the general support forum with the diagnostics.

"I updated to Unraid 7.2.4 and all I got was this 7.2.4 version tag"


When does version 8 come out? ;)

parity check started with wrong type

not much i can say or offer in evidence about this, but having just updated to 7.2.4 i encountered a parity check started as the wrong type (i.e. "correct" vs "nocorrect") even though I very deliberately UN-checked the checkbox prior to starting

i have also just recently installed the Parity Check Tuning plugin (2026.01.09), in case that has any relevance here - am using MS Edge on Win 11 25H2, everything up-to-date

i had initially run a no-correct check, then cancelled it in order to do a flash backup with array stopped
after re-starting array and then (again having un-checked the box) manually starting (a new) parity check, i noticed that it was actually running a CORRECTING parity check
Tower2 kernel: mdcmd (36): check correct in the log

it might be some weird browser caching problem, i really don't know what to say
i stopped and started again and it was running nocorrect as i expected
i stopped and started again and it was running correct again frustratingly

this most recent time i tried it (after cancelling from a nocorrect condition), i deliberately did a CTRL-F5 re-load of the main page before de-selecting the correction check-box, re-started and i see nocorrect in the log

in any event, i will have to be very diligent when starting parity checks in future if it might be doing what i specifically DON'T want it to be doing!

---

update: it seems i can use the parity.check nocorrect command to initiate a parity check to have a degree of certainty in future

---

FWIW, here is the syslog: tower2-syslog-20260308-1521.zip
though it doesn't confirm anything about the state of the GUI checkbox at the times i was trying to initiate the checks
activity in the syslog AFTER Mar 8 09:00:21 was me cancelling/re-launching the parity check via the parity.check cmdline

Edited March 8Mar 8 by magic144

22 minutes ago, magic144 said:

offer in evidence about this

syslog would have worked as evidence.

Normally, it doesn't start a parity check when you boot, unless you have an unclean shutdown. If that is what is happening, then I think it's normal.

6 minutes ago, trurl said:

syslog would have worked as evidence.

Normally, it doesn't start a parity check when you boot, unless you have an unclean shutdown. If that is what is happening, then I think it's normal.

syslog uploaded

none of this is to do with a parity check running at boot - this is all (ONLY) about manually starting parity checks from the GUI main page

Note that the parity.check command is part of the parity check tuning login - not a standard part of Unraid. Although it can start/stop an array operation it is definitely not the recommended way to do this (although I find it useful in testing). If you do a lot of commands via that method then make sure you use the 'parity.check monitor' command to make sure the plugin has the latest status. The 'parity.check status' option is then useful to check the status without affecting what is running, and if there is a check running to confirm what type of check it is. By making sure you take the time of an action in the GUI, and correlating that with the time you do the 'parity.check monitor' and 'parity.check status' it should make it easier to confirm exactly what is happening.

yeah i mostly wanted to report here in case the GUI correct/nocorrect switch was an OS issue (not specifically related to the Parity Check Tuning plugin)

i haven't noticed this before (Unraid starting the WRONG correct/nocorrect) type of parity check DESPITE the GUI checkbox when starting a manual check from the main page

i only tried the parity.check nocorrect command as a means of ENSURING the right kind of check was going to be started, in the face of this uncertainty from the GUI/checkbox (which i have always used in the past, not ever having the Parity Check Tuning plugin ever installed before)

@itimpi , if i do start parity check via cmdline this way, won't that be the same as if i had started via the GUI? - i assume if i start it via the parity.check cmdline, i will still have the benefits of being able to resume after a shutdown, etc

i don't know how to debug the basic behaviour (bug) from the non-plugin (OS-builtin) parity start mechanism from the main page - it just seems to have been the "wrong" type sometimes - I ALWAYS want to use a "nocorrect" test as part of my monthly parity verification ritual BEFORE i decide what to do next if there is an error

Edited March 8Mar 8 by magic144

3 minutes ago, magic144 said:

@itimpi , if i do start parity check via cmdline this way, won't that be the same as if i had started via the GUI? - i assume if i start it via the parity.check cmdline, i will still have the benefits of being able to resume after a shutdown, etc

the plugin uses the same command to start a parity check as the GUI. The resume capability of the plugin is thus the same regardless of how a check was started.

sounds good - thanks for the confirmation

well, meanwhile if anybody has a way for me to definitively debug the OS-builtin main page parity check correct/nocorrect (via checkbox/start button) behaviour, I'm all ears and a willing victim/participant

22 hours ago, magic144 said:

not much i can say or offer in evidence about this, but having just updated to 7.2.4 i encountered a parity check started as the wrong type (i.e. "correct" vs "nocorrect") even though I very deliberately UN-checked the checkbox prior to starting

This is a very old bug, since at least 7.0, probably even before that.

It happens the first time you run a check on the 2nd or later array start, e.g.

• 1st array start, uncheck the box, and it works correctly.

• 2nd or later array start, run a correcting check first and then a non-correcting one; it will work correctly

• 2nd or later array start, uncheck the box, and it will incorrectly run a correcting check

It's a very corner case, and IMO parity checks should most times be correcting anyway, but there was an old bug report for this, I can't find it now, and since there's a new tracker, you can create a new report there if you like Unraid OS Bug Reports | Unraid

Just out of curiosity - I've never seen the "Requires verification to update" or the "Verify to Update" button before?

Is that a 7.2.3 change?
I probably just missed an update, I just get a bit paranoid when the process changes 🤣

Well, for every 10 that have no problem there's always 1 that does 🤔. Today that was me. After plugin updates, docker stop, VM stop, array stop, I triggered the installation after clicking on the "Verify" button. It started, but it never came back from "Please keep this screen open while we update some things". I waited for an hour, then logged i [...cut...]

I triggered it again. The only active process in top is "node /usr/local/unraid-api/dist/main.js"... while "Please keep this window active...". So, I have yet another sweat outbreak...

ℹ️ Note to developers: Add to the upgrade instructions to "Disable Browser Tracker Blockers".

In my Vivaldi browser, the update only offered the "Confirm" window after I had selected "No blocking" on the URL. This refreshed and then allowed me to confirm and start the upgrade.

Edited March 15Mar 15 by dmindfuse

1 hour ago, dmindfuse said:

"Disable Browser Tracker Blockers"

Good idea to whitelist your Unraid webUI in general, not just for upgrading.

10 hours ago, trurl said:

Good idea to whitelist your Unraid webUI in general, not just for upgrading.

👍

Good advise. I mean unraid is trustworthy right? Otherwise we wouldn't be using it right?

Upgraded from 7.1.4 to 7.2.4 without any immediately apparent issue, VMs and dockers all came up just fine. Glad to see my ARC PRO B50 is finally detected properly with the kernel update so now I've gotta get it used.... Specs in signature for the curious.

Upgraded from 7.0.1 with no issues.