How does one make sure timing is correct i.e. unassigned devices is not killed during shutdown, thus unmounting my vmdk during or prior to coping by User Scripts?

10 minutes ago, AndroidCat said:

How does one make sure timing is correct i.e. unassigned devices is not killed during shutdown, thus unmounting my vmdk during or prior to coping by User Scripts?

When we upgrade through the unRAID webGUI, it doesn't reboot like some other software might. It just tells you that you need to reboot. At that point can't you manually run whatever script?

 

Maybe you should start another thread so someone with similar interests can help. There is a subforum for Virtualizing unRAID here:

 

https://lime-technology.com/forums/forum/46-virtualizing-unraid/

 

 

How does one make sure timing is correct i.e. unassigned devices is not killed during shutdown, thus unmounting my vmdk during or prior to coping by User Scripts?

I can only give you my experience that it just worked without issue.

Sent from my LG-H815 using Tapatalk

looking at the changes, it seems like this is more of a 6.4.2 not a 6.5. why the minor bump?

 

Edited March 7, 20188 yr by zoggy

6.3.5 to 6.4 was a pretty huge upgrade but 6.4 to 6.5 seems much smaller in terms of new features/ internal feature redesign etc.
With zoggy on this one. Just curious.


Sent from my iPhone using Tapatalk

24 hours and no call traces. thanks for the patch!

4 hours ago, ars92 said:

6.3.5 to 6.4 was a pretty huge upgrade but 6.4 to 6.5 seems much smaller in terms of new features/ internal feature redesign etc.
With zoggy on this one. Just curious.


Sent from my iPhone using Tapatalk

 

10 hours ago, zoggy said:

looking at the changes, it seems like this is more of a 6.4.2 not a 6.5. why the minor bump?

 

 

From: 

 

 

Stable releases are numbered <major>.<minor>.<patch>

 

Patch releases are reserved primarily for CVE (security) and other critical bug fixes.

 

This release is neither a critical bug fix or a CVE patch. It's some minor tweaks, which fits perfectly in with their versioning schema

 

Perhaps 6.4 should've been 7.0! Who knows

 

37 minutes ago, nexusmaniac said:

This release is neither a critical bug fix or a CVE patch. It's some minor tweaks, which fits perfectly in with their versioning schema

 

I guess spectre and meltdown  and all that are not really critical fixes.... ¯\_(ツ)_/¯

20 minutes ago, 1812 said:

 

I guess spectre and meltdown  and all that are not really critical fixes.... ¯\_(ツ)_/¯

 

It's far more than just those fixes though. There's web UI changes, funnily enough there's a big long list known as a changelog

 

Details all the non-critical things which have been added/removed/fixed/patched, etc.  

11 hours ago, zoggy said:

looking at the changes, it seems like this is more of a 6.4.2 not a 6.5. why the minor bump?

 

It's because of large number of base package updates.

 

I know if we released as 6.4.2 a large number people will complain, "That is a really long change list for a patch release, WTF?"

And if we release as 6.5.0 another set of people will complain, "No big new feature for a minor release, WTF?"

 

Personally, I put zero emphasis on release numbering (as in I don't care about it all, that is to say, it's largely meaningless).

 

There is a separate topic available for discussing this:

 

2 hours ago, limetech said:

 

It's because of large number of base package updates.

 

I know if we released as 6.4.2 a large number people will complain, "That is a really long change list for a patch release, WTF?"

And if we release as 6.5.0 another set of people will complain, "No big new feature for a minor release, WTF?"

 

Personally, I put zero emphasis on release numbering (as in I don't care about it all, that is to say, it's largely meaningless).

 

There is a separate topic available for discussing this:

 

 

Working in software I can totally relate!

 

May I suggest you switch to the "<Year>.<Month>.<ReleaseNumber>" then it pleases both parties.

18 minutes ago, Tango said:

 

Working in software I can totally relate!

 

May I suggest you switch to the "<Year>.<Month>.<ReleaseNumber>" then it pleases both parties.

 

That's what Docker has starting doing since last year.

2 minutes ago, limetech said:

 

That's what Docker has starting doing since last year.

Also the versioning scheme of our plugins. Not trying to make a case either way.

There's clearly not a lot wrong with this rc since much of the discussion here is about how it's numbered. That's a good thing!

2 hours ago, John_M said:

There's clearly not a lot wrong with this rc since much of the discussion here is about how it's numbered. That's a good thing!

 

Works for me.  Main server updated OK, no issues so far.

 
It's because of large number of base package updates.
 
I know if we released as 6.4.2 a large number people will complain, "That is a really long change list for a patch release, WTF?"
And if we release as 6.5.0 another set of people will complain, "No big new feature for a minor release, WTF?"
 
Personally, I put zero emphasis on release numbering (as in I don't care about it all, that is to say, it's largely meaningless).
 
There is a separate topic available for discussing this:
 

Probably frowned upon now but I used to do software releases as YYYY.MM.DD when I did some shareware stuff back in the DOS days as I ran into the same issues but not as drastic due to the smaller crowd.

13 hours ago, digiblur said:

 

Probably frowned upon now but I used to do software releases as YYYY.MM.DD when I did some shareware stuff back in the DOS days as I ran into the same issues but not as drastic due to the smaller crowd.

 

 

Prob no one remembers, unRAID-1 and unRAID-2 were versioned like this:

  UnRaid-2.060315.zip

 

Then starting with unRAID-3 I introduced the versioning we have today, eg, there was

unRAID Server 3.0-beta1.zip

...

unRAID Server 3.0.zip

 

This was done because the s/w had grown to the point where I felt "beta" releases were necessary in order to test new stuff before unleashing on the entire user base.

 

Can't remember why I simply didn't use "UnRaid-3.YYMMDD-betaN".  Probably was due to a complaint

I upgraded to this and now my server won’t boot. It’s stuck on bzoot ok. I have taken a backup but it’s a backup of the server before I changed from 8tb to 12tb hdd.

Can I restored the usb from my backup?


Sent from my iPhone using Tapatalk

10 minutes ago, pras1011 said:

I have taken a backup but it’s a backup of the server before I changed from 8tb to 12tb hdd.

Can I restored the usb from my backup?

NO. In fact it might even be dangerous to attempt. If you have reused parity as a data disk, and you boot with a configuration that thinks that old parity disk is still parity, it will overwrite the data with parity. And even if you don't have this disastrous scenario, if any of your disk assignments have changed it won't know about the new configuration.

 

Normally the upgrade copies the previous version into a /previous folder on flash. Try restoring that instead by copying all its files to the top folder on flash.

Upgraded from rc1 with no issues, ooo and the guitar is back which is good to see, all good so far

is this anything worth worrying about?

 

Mar 8 02:56:16 Tower kernel: CE: hpet2 increased min_delta_ns to 20115 nsec
Mar 8 02:56:16 Tower kernel: CE: hpet4 increased min_delta_ns to 20115 nsec