Should "GUI auto update" be folllowed by a "Dublicate bootup slice"?

Tillebeck

I have read in this forum that the embedded versions runs with two partitions and that one will be boot partition. The other is a spare. The two partitions share the config file.

Upgrade using the GUI AUTO update will update the spare partion and then set that as boot partition. After the upgrade the box will reboote and now be on the previous spare that now is the current boot partion and latest version too. The old boot partion is unchanged and one can manuelly revert back to that partion if the newly upgraded spare partions for some reason is no good as boot partion.

Ok. So far I get it. But what's next?

If everything is OK should I then just do nothing?
Somehow repeat the upgrade for the current spare?
Dublicate the current boot to the spare
Dublicate the current boot to the spare AND change boot slice back to 1 (is 1 better?)
Something completely different?

BR. Anders

stephenw10

The slices have no priority, 1 is not better than 2 in any way.

No you probably don't want to duplicate the slice. If your new upgrade turns out to be problematic for some reason you need to keep the previous version so you can revert to it if necessary.
The only time you might want to duplicate the slice is if you've had to boot the backup because the current has been corrupted somehow.

Others may have a different opinion.

Steve

Tillebeck

OK, thanks.

I was in doubt because when visiting:
Diagnostics -> NanoBSD -> View upgrade log

then first line would read:
"NanoBSD Firmware upgrade in progress…"

but that must just be log info written at the time the system was beeing updated.

Thanks again to clarify the procedure.

phil.davis

After running a new official release for "some time" (as judged by you), and finding that it works well (or at least better than the previous version), I would duplicate the slice, switch to it and reboot (so I know the duplicated slice works). Then if "something odd" happens to the currently booted slice, I can always switch slices (from GUI, or manually) and reboot using the other slice.
But as stephenw10 says, there will be varied opinions about what is best system management practice.

stephenw10

@phil.davis:

switch to it and reboot (so I know the duplicated slice works).

That is a good call. You don't want to find out your backup slice is corrupt only when you boot to it in a crisis!
I've yet to experience a corrupt slice though so perhaps my habits may change if/when that happens. ;)

Steve

Tillebeck

Thanks for input. +1 for dublicating after a "burn in" period.

Other argument to do so
If booting the other slice means booting an old version, then it just might need the old config (from backup) to be restored at the same time. And if the old slice cannot boot without the old config then one will end up with only one functional slice.

conclusion:
dublicating slice so there is two identical slices that can use the same config file seems to be the preferred solution.