Yes, that is a proper and supported command from 08.0.80 and higher and will properly install the UFI components. Typically, I think Ruckus is recommending 08.0.90 builds currently 08.0.90d as their recommendation last I heard for this product family 7150, 7250, 7450, 7750... I think the 08.0.91 builds is new for a couple specific switches which do not even have an 08.0.90 build offered.
That said, I am aware 08.0.91 has been released and that there is a build that would run on the above switches, but personally I am waiting until at least 08.0.91b except on a test bench or lab.
Today, I just cleared upgrading our switches (described above) from 08.0.80e to 08.0.90d, and we will be installing the UFI support as well using the command you listed.
*****
I would recommend doing a show boot-pref to verify if it boots the primary or secondary. From there, I always do a copy flash flash secondary or a copy flash flash primary depending on which I want to copy and which I want to overwrite. Using the ? question mark it will tell you exactly which one means what.
I ALWAYS store Layer-3 in secondary and boot from secondary on Layer-3 devices as a matter of convention going all the way back to the Foundry days. Basically, in the global configuration I would do a "boot system flash secondary" to set that preference before I initially deploy a Layer-3 device.
For a Layer-2 device I just leave it as default. No need to set "boot system flash primary"; since, default tries primary first anyway.
In your case SPS08091ufi.bin is layer-2 "switching" firmware. The Layer-3 build would be SPR08091ufi.bin, which I doubt you want.
If I were upgrading from SPS08090c.bin being a layer-2 device I would have it booting from Primary.
I would do a copy flash flash secondary to copy the Primary -> Secondary as my backup.
Then I would do a "verif md5 primary" and a "verif md5 secondary"
Usually, I have the checksums saved to a textfile but ultimatey I am typically doing maybe 15 or 20 of these when I do them, so I do them in bulk really only checking the destination.
Only then do I execute my copy tftp flash xx.x.x SPS08091ufi.bin primary
Personally, I always then heck the primary out of habit though I would not be surprised if the switch already does a sanity or hash check as part of the built-in progress.
I also do a "show boot" to validate the bootrom is properly updated, too.
Lastly, I do a "write memory" just for good measure. This is because I want the startup-config to be as up-to-date as possible before going to the next release family. For example, if the startup-config is 08.0.70b for example and each boot it is loading 08.0.80c, then there are various pre-parse tasks that happen each time most likely stripping things like the depreciated dual-mode etc. and generating a new running-config.
It is just better to be as close as possible to the next build family before taking the leap; since, things are more completely tested by the developers whom undoubtedly have tested just about every command from 08.0.80x to 08.0.90x but much less so from say 08.0.60x to 08.0.90x
What you do not want is something that was depreciated a long long time ago to the point it does not convert and you end up with a configuration that is incomplete after an upgrade. For example, over the years there has been three (3) ways I have done trunking. Back on the old FastIron WS devices running 07.0.40x builds, was different than say 08.0.30x builds, and at some more recent build version they created a new virtual Lag interface.
You should have no issues going from 08.0.90c to 08.0.91, but please run a write mem first. That said personally, I would probably go from 08.0.90c to 08.0.90d UFI if it were my judgement call.