Cannot update to new beta OS

If you download your logs (Status > Logs > Download all Logs) and extract the zip contents what does your disk_usage.log look like?

Thanks for your help - here it is:

Filesystem            Size  Used Avail Use% Mounted on
/dev/md0              4.0G  707M  3.2G  19% /
tmpfs                  16K     0   16K   0% /USB
/dev/c/c              3.7T  1.6T  2.1T  44% /c

TBH the first thing I checked via CLI that I have enough space...

That looks fine.

Any clues in /var/log/frontview/error.log?:

# tail /var/log/frontview/error.log

Have you tried an OS Re-install?: http://www.readynas.com/kb/faq/boot/how_do_i_use_the_boot_menu

You should be able to go to System > Update > Local and update the firmware that way. However as a last resort if you wish to do it via the CLI, you can:

# cd /tmp
# wget http://www.readynas.com/download/beta/raidiator-x86/4.2.20/RAIDiator-x86-4.2.20-T32
# echo /tmp/RAIDiator-x86-4.2.20-T32 > /.cf_update_in_progress
# reboot

Note that the CLI method doesn't check to make sure the file was downloaded correctly so it is a last resort.

Yeah, CLI is the way I was searching for, thanks...

...however I suspected it's something about JF with my new switch, a Dell PowerConnect 2816 vs my onboard Realtek PCIe Gigabit crap vs Pro 6 so after updating my LAN drivers I let JF off (MTU is 1300 by default) then I was able to update.

Of course, turning on JF via Windows UI does not have any effect, netsh still reports 1300 MTU size:

PS C:\Users\szlevi> netsh interface ipv4 show subinterfaces

   MTU  MediaSenseState   Bytes In  Bytes Out  Interface
------  ---------------  ---------  ---------  -------------
4294967295                1          0     157337  Loopback Pseudo-Interface 1
  1300                1     224089    4181263  PHY1
  1500                1          0    4035179  VMware Network Adapter VMnet1
  1500                1          0    4036645  VMware Network Adapter VMnet8

Great, just great - typical PoS Microsoft quality...

Anyhow, update is done, I can see ALL shares now including the ones were hidden before (eg Squeezecenter) so I cleaned up the mess the previous stable (cough-cough) firmware left behind. I also quickly installed the Cacti plugin and now I will turn JF back and see WTF was this cockup... :twisted:

Wow: just turned JF back on my machine, fine.

PS C:\Users\szlevi> netsh interface ipv4 set subinterface "PHY1" mtu=9000 store=persistent
Ok.

PS C:\Users\szlevi> netsh interface ipv4 show subinterfaces

   MTU  MediaSenseState   Bytes In  Bytes Out  Interface
------  ---------------  ---------  ---------  -------------
4294967295                1          0     157337  Loopback Pseudo-Interface 1
  9000                1     568342    4328812  PHY1
  1500                1          0    4067853  VMware Network Adapter VMnet1
  1500                1          0    4069319  VMware Network Adapter VMnet8

Then I went to see if the Cacti installation that was spinning frozen in the browser has actually finished but it (Cacti) only opened an empty page...

...then I tried updating NASinfo which also became unresponsive so I reloaded the UI, went back and a popup told me the Nasmon update checksum was invalid so it's aborted.

And Frontview did not load at all anymore. Interesting; let's see in Firefox 10 instead of Chrome v18.5... of course it works. I hate Chrome's unreliable nature. :(
Guess what: Nasmon et al updated itself just fine and it even works fine (sans loadavg spitting out php errors but who cares, I only need NASinfo and maybe phpsysinfo.)

Cacti craps out, removed.

However now I cannot upload any file nor even copy files over CIFS to share.

Does this thing (Dell 2816 switch, that is) actually support proper 9k frames? It does not look like that...

Not a bug. The beta firmware doesn't fix the CIFS problem if it's already there. It only prevents it from happening again.

mdgm wrote:
Not a bug. The beta firmware doesn't fix the CIFS problem if it's already there. It only prevents it from happening again.

That's my point: it did happen again.