Release notes for Excito Bubba 2&3 software version 2.6

[Henri]

Ḧi

Thank you Excito team for finally launching the new backup. I have been waiting this for a long time.

Just did the update and don't have yet experience how this new backup actually works.

It would be nice though, if you could add a possibility to let user select a folder which is needed to backup.
With this setup my "important" files are left outside backup. I can't select to backup "storage" because it is too big for my backup drive and contains hundreds of gigabytes of files, which don't need to be backup.

Great job. Keep on going.

[jobbe]

I need some advise. Bubba 2. upgrade froze at 42%..Powercycled and boots ok. However I cannot log on to Shell. User accounts with shell enabled does not work.

When I try to run upgrade again it fails

Package name Package version
bubba 2.6
bubba-album 2.6
bubba-backend 2.6
bubba-frontend 2.6
bubba3-kernel 1:2.6.39.4-13
filetransferdaemon 0.55
logitechmediaserver 7.7.2.dfsg1-

Error message when trying to run upgrade again

Failures found in package (dpkg) database, unable to continue with upgrade
Error!
toggleFailures found in package (dpkg) database, unable to continue with upgrade

[jobbe]

Gents,

I have a B2, that crashed. After installing a new harddrive I have tried to get from 2.4.1 to 2.6.

Please, will you advise if this is possible?
I have tried through WEB interface and failed. The initial WEB fault looks to be related to hotfixe, gathering data for remote analysis . From CLI I can issue apt-get dist-upgrade, reboot followed by apt-get update.

I get from:

2.4.1
Detailed information
Package name Package version
bubba 2.4.1
bubba-album 2.4
bubba-backend 2.4.1
bubba-frontend 2.4.0.7
bubba3-kernel 1:2.6.39.4-9
filetransferdaemon 0.54
logitechmediaserver 7.7.1.dfsg1-7

To:
Package name Package version
bubba 2.6
bubba-album 2.6
bubba-backend 2.6
bubba-frontend 2.6
bubba3-kernel 1:2.6.39.4-13
filetransferdaemon 0.55
logitechmediaserver 7.7.2.dfsg1-1

But I am still unable to run WEb interface update.

Thanks

Jakob

[Gordon]

I have a B2, that crashed. After installing a new harddrive I have tried to get from 2.4.1 to 2.6.

Please, will you advise if this is possible?
I have tried through WEB interface and failed. The initial WEB fault looks to be related to hotfixe, gathering data for remote analysis . From CLI I can issue apt-get dist-upgrade, reboot followed by apt-get update.

<snip>

But I am still unable to run WEb interface update.

Do you get an error message when attempting update? The versions you show appear to be correct, so attempting a web update at this point will likely do nothing at all.

[jobbe]

I get no error messages but have later found issues with accounts (wrong security) also cannot access storage from XP / UBUNTU or Win 7 clients but can see dir structure exist. Been forced to return to 2.4.1 as 2.6 is unuable as it is. Hope someone in the forum will come up with a good advise as I am not sure where to look. Currently my B3 deals with users but I would like to bring B2 back to service with the new HD and ver.2.6.

Thx,

Jakob "jobbe"

[GodfatherB]

Would it be possible to include this version as the reinstall image on the dowloads page? The last one published is 2.4.1.1...

[Ubi]

I agree with this suggestion.

[ingo2]

I agree with this suggestion.

Same here!

Additional info:
just today Debian released security fixes for GnuPG, see here: http://www.debian.org/security/2013/dsa-2773 for Wheezy and Squeeze. is there a chance to get those also into B3?

[GodfatherB]

Johannes, will new install images be available?

[johannes]

We did not plan to do this, no. The reason is that it is quite a lot of work of testing, and to install and then upgrade manually (using the button in the web UI) is easy, so there should be no big need for an image with 2.6, right?

[Ubi]

well, the thing is, it looks kinda sloppy using this two-step install. It is also a little error-prone.
But I agree, LVM support in the rescue disk is more important than an up-to-date installer.

[johannes]

you are right, and my response was sloppy as well. Didn't mean to sound lazy, but it's all a matter of prioritisations, as always, where we thing we can spend development efforts better. We have always done this (fewer installer releases than software update releases) for this very reason.

[Ubi]

pragmatism is always a good thing.

Is there any possibilty to mimic the B3 as a virtual machine in Qemu or something like that, so as to speed up testing the installer disk? The alternative would be serial-enabled machines. Dunno if these show the pre-boot data as well though.

[johannes]

I don't think (but don't know really) that emulating ARM embedded systems are easy (it's not even easy to cross-compile most of the stuff, we actually build most stuff directly on the B3). But yes, we have serial ports on some dev machines to trouble-shoot low-level stuff.

Testing installers however is mainly a manual, time consuming effort, we have a list of test cases we go through, testing all features both for regressions against known previous issues, and for new features. Basically we install a few devices (some with small disks, some with large, with and without wifi etc.) and test in different environments. As you can imagine the matrix of test cases quickly gets enormous so we try to be intelligent and test the stuff most likely to have broken, but to keep a decent quality level we spend a lot of time testing. And adding an installer to each release again doubles all test work, this is why we don't.

[Ubi]

Well, to stay pragmatic, one possibility is to test only on a limited set of cases and call the installer "experimental" and release with warning wrapped around it. If it gives funky results, tell user to used the 'production" installer, and label the error. Those users who do not like to gamble can use the foolproof version, those willing to risk it can take the bleeding-edge edition.