hi, Am Mittwoch, den 17.06.2015, 09:08 +0200 schrieb Matthias Apitz: > Hi, > > El día Tuesday, June 16, 2015 a las 07:23:39PM +0200, Oliver Grawert escribió: ... > > the solution is pretty simple, don't tinker with the device if you need > > to rely on it ... the OTAs are binary diffs between two predefined > > readonly images, if you changed the base image of this diff process in > > any way nobody can tell what happens ... > > (could you please explain a bit, how these binary diffs are produced and > loaded into the device later, i.e. how the update works; thanks)
i think that is described in the client section of https://wiki.ubuntu.com/ImageBasedUpgrades ... > ... but: even if you have not tinkerered your device (and I did not), > for some reason you may end up with a not booting device, for example > power fail while updating, broken battery, ... > > and for this case one needs a strong guiding about what to do now; I know > there are a lot of places with very(!!!) useful documentation and hints > and I have them pulled together here as an example: > > > Installing adb and fastboot: > > http://bernaerts.dyndns.org/linux/74-ubuntu/328-ubuntu-trusty-android-adb-fastboot-qtadb > wow, what a horrible doc ... sudo add-apt-archive ppa:phablet-team/tools sudo apt-get update sudo apt-get install ubuntu-device-flash that will give you everything you need without tinkering in udev rules or other config files (and will make sure you get the changes if additional features show up or fixes are added to the tools etc). ... note that ubuntu-device-flash is written in go ... which makes it portable to any system you like (there just hasn't anybody stepped up for a mac or windows (or even bsd) port yet) > Installation and flashing: > > http://sturmflut.github.io/ubuntu/touch/2015/05/07/hacking-ubuntu-touch-index/ > : > -- Hacking the bq, Part 1: Bootloader, Fastboot and Recovery > -- Hacking the bq, Part 2: Factory Mode > -- Hacking Ubuntu Touch, Part 1: ubuntu-device-flash > -- Hacking Ubuntu Touch, Part 2: Devices and Images > -- Hacking Ubuntu Touch, Part 3: How images are flashed > -- Hacking Ubuntu Touch, Part 4: Developer mode and ADB > -- Hacking Ubuntu Touch, Part 5: adb shell vs. phablet-shell > -- Hacking Ubuntu Touch, Part 6: Logfiles > -- Hacking the bq, Part 3: Supported media plugins and codecs > -- Hacking Ubuntu Touch, Part 7: System and process monitoring tools > (part 1) pretty advanced but IMHO the best set of docs we have yet ... > > Flashing the E4.5: > > http://askubuntu.com/questions/602035/how-do-i-use-ubuntu-device-flash-with-the-bq-aquaris-e4-5-and-aquaris-e5 > > but all this amount of very good stuff, is not what you need in a case > of emergency; in this case you need a clear step by step guide 1....nn > which must start with how to enable adb and adb-fastboot (keep in mind > not all of us are Ubuntu-users or Ubuntu-experts, but users of Linux or > in my case FreeBSD; well, if you are able to set up your own BSD system i pretty much trust you to have the knowledge to find your way around ... for the general ubuntu user, adding the PPA and following the above askubuntu question is enough ... for the average windows user who perhaps doesnt even know what adb or fastboot are ... call bq, there is support ... > > > this is why we use askubuntu, you are able to improve what's there if > > you feel the need ;) > > I'm in the good position to have a second broken BQ E4.5 which I must return > in > the next week to BQ.com for repair/change; I will try to test a > procedure with this flashing it to factory state again before returning > the device to BQ. you will likely never be able to do that at home, the factory images are installed by factory tools (dont ask me what the factory in china uses, i have no clue, but surely not ubuntu-device-flash (most likely some automated binary blob flashing windows tool)) a factory process needs to be a lot faster than an enduser tool (and run automated QA tests etc) but i think bq offers the factory images and a windows enduser tool somewhere on their site to get you as close as possible to this setup.at least. note though that there are 100s of manhours put into automated and manual QA and upgrade tests of a new image (way more time than for development i would claim) and while things can slip though (like the alarms for example) i would say it is highly unlikely that ever something that mass-bricks devices can slip through (the same setup on the same (unchanged) device you have at home is upgraded dozens of times with the same procedure the enduser gets by the testers). you can not protect from races that are not reproduceable in such a test scenario and are caused by a certain combination of things on the users phone, you can not protect from people tinkering with their phones since we explicitly allow that, but for the majority of devices that have not been tinkered with and do not have the fatal combo of events (like the upstart logging bug some people had with the first OTA) you will simply not see something like reboot loops etc. these fatal breakages are corner cases that indeed can happen but are not the rule (and are often enough caused by people changing the system) this OTA was a full distribution release upgrade, up to now we have heard from two persons having bigger issues (reboot loops) ... while this is awful for the people involved, it is still quite a small percentage ... something we haven't achieved on the desktop with package based updates in ten years :) this is one of reasons why the evolved phone technology in the form of snappy will be used for future desktops and phones btw ... ciao oli -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
