On Dec 01, 2016, at 03:55 AM, Mitchell Reese wrote:
>> You want "--build 0 --maximage 121"
>>
>Didn't work for me. Seems not possible to roll back updates with the
>system-image-cli tool. As near as I can tell, this tool allows you to force
>an upgrade to a certain version that's greater than
On Nov 30, 2016, at 06:11 PM, Michał Sawicz wrote:
>Correct, but --build 0 is overriding the "current version", so 121 is
>higher than that.
>
>I've confirmed, though, that the --maximage option doesn't seem to work
>well when it would be a full upgrade, because the upgrade path just has
>one
On Aug 01, 2016, at 01:02 PM, Peter Bittner wrote:
>Interesting, the update popped up after I had switched the "Download
>automatically" option to "Always" (instead of "WiFi only"), and
>manually checked for updated again twice. Is this related to roaming,
>by mistake or by design, maybe?
On Jul 15, 2016, at 12:51 PM, Michał Sawicz wrote:
>system-image-cli always goes to the latest, there's no way to override
>that atm.
Kind of. As I mentioned earlier, there is the -m/--maximage flag. Let me
elaborate on that a little bit.
The way s-i works is that it first calculates all the
On Feb 21, 2016, at 09:12 PM, Matthias Apitz wrote:
>I've checked the archives and my log files: I do not receive any mail
>from the list after this one:
I don't know why that is; I'm seeing several messages to this mailing list
today. Let's see if I get this response...
>What can I do as this
On Jan 28, 2016, at 05:30 PM, Łukasz 'sil2100' Zemczak wrote:
>Could you type this command into a terminal on the device? (or while
>accessing it through adb/ssh). Requires password:
>
> sudo system-image-cli --dry-run
Try it also with increasing levels of -v for more information about update
On Jan 28, 2016, at 05:09 PM, Nekhelesh Ramananthan wrote:
>When I tried system-image-cli -n -v, I got,
>
>[systemimage] Jan 28 21:36:57 2016 (16704) No valid image master key
>found, downloading
>[systemimage] Jan 28 21:36:57 2016 (16704) [0xb5fa4710] Requesting
>group download:
>
> [systemimage] Jan 28 18:40:08 2016 (8741) system-image-cli exception
> Traceback (most recent call last):
> File "/usr/lib/python3/dist-packages/systemimage/main.py", line 350, in main
> state.run_until('download_files')
> File "/usr/lib/python3/dist-packages/systemimage/state.py", line
On Aug 27, 2015, at 07:17 AM, Thomas A. Moulton wrote:
From watching the various updates my Tablet (flo) has received, aren't
the OTA updates deltas? If so, then would it be expected to have 500MB
of changes between updates often? In the most recent update I think I
saw about 148MB downloaded.
On Aug 27, 2015, at 08:56 AM, Sergio Schvezov wrote:
This could be solved with having an entry in channels.ini
We should really get touch on system-image 3.0. I think it doesn't help us
that snappy and touch use different versions of this tool. In si 3.0, this
would be a set in a file in
On Jul 07, 2015, at 02:39 PM, John McAleely wrote:
What happens when an alias is retargetted between a channel with (say)
build 200 at the tip, to one with 50 at its tip (for the same device)?
That's supported. On an alias change, we squash the device's build number to
0 so it will do a full
On Jul 07, 2015, at 02:50 PM, John McAleely wrote:
What does the user see? I had build 200, and now I have build 50? Or I had
build 200, and now I have 201?
The si client is just reporting whatever information ends up in the .ini files
after the update, so in this case the user will see build
On Jul 07, 2015, at 12:03 PM, John McAleely wrote:
My take away is that the system has the capability (via alias channels) to
publish channels were the build numbers do make arbitrary jumps backward or
forward, and we currently succeed in not using that capability (mostly).
Going backward within
On Jun 17, 2015, at 11:42 AM, Sergio Schvezov wrote:
Can't we block system image updates from happening if .writable-paths is
set? Or maybe a less happy path of forcing full updates instead of deltas,
breaking the user's mods but not the system.
As I mentioned internally, you only want to do
Hi folks.
The system-image client (or si for short) is the component on devices that
performs the check for availability of system upgrades, downloads and verifies
the upgrade, and (on touch) reboots into recovery so that the upgrade can be
applied. There is both a command line version and a
LP: #1383539 describes a bug with phased-updates, and is a candidate for rtm.
system-image 2.5.1 is a candidate for fixing this bug.
The new version is available in a vivid silo (although it will be a sync to
rtm); this is a call for additional testing.
The silo with the (architecture
On Oct 22, 2014, at 09:37 AM, Olivier Tilloy wrote:
Just tried to upgrade my krillin from #120 to #122, and I’m getting a
popup that says:
Installation failed
Sorry, the system update failed.
[OK]
The log under /var/log/system-image has the following:
[systemimage] Oct 22
On Oct 21, 2014, at 09:55 AM, Pete Woods wrote:
Is there any chance the magical internet fairies could do the same for
system images as they already do for the archive mirrors?
They wouldn't have access to the private keys that sign the system image
files, so device updates should properly fail
On Oct 11, 2014, at 03:48 PM, Vojtech Bocek wrote:
I've just removed the broken image (version 82) from my
s-i.tasemnice.eu server (the one for hammerhead and deb). The same
thing applies - if you've already downloaded it, don't install it. It
_should_ be safe to update to version 81 though.
I
On Oct 11, 2014, at 04:48 PM, Oliver Grawert wrote:
we have abilities to do that ... but only stgraber knows the exact steps
that dont break the world (last time we had this issue i simply did a
copy-image of the former working image to become newer than the broken
one, but that caused havoc with
On Oct 09, 2014, at 12:47 PM, Łukasz 'sil2100' Zemczak wrote:
https://wiki.ubuntu.com/citrain/LandingProcess
Good work! Lots of great details there for self-serve passengers.
We will add new things to it today as well, but we're open to suggestions.
Note that we also have the FAQ:
system-image is the core component that handles the client side of image based
upgrades. From a user perspective, it is two tools (both have extensive
manpages):
* system-image-cli - the command line executable
* system-image-dbus - the D-Bus service, used by the System Settings u/i
Version
As I prepare system-image 2.4 for the citrain, I wanted to mention that I am
deprecating the `--dbus` option for system-image-cli. I doubt anybody
actually uses this option, and I plan on removing it in system-image 2.5,
whenever that happens.
Note that this has nothing to do with
On Jul 29, 2014, at 12:46 PM, Larry Griffin wrote:
I have a problem setting up a Nexus 7 WIFI to Dualboot. I'd like to use it to
help with testing. I originally installed dualboot on this Nexus 7 about two
months ago, and it used the trusty channel. Now I can't change the channel to
utopic. I'm
The system-image package provides the component on touch devices that checks
for and performs system updates. Version 2.3.1 is ready for wider testing.
Below are the list of changes for this new release. If all goes well, I
intend for this to be the version for RTM, and as this is a rather
On Jul 08, 2014, at 12:23 PM, Sergio Schvezov wrote:
On martes 8 de julio de 2014 10h'58:26 ART, Jamie Strandboge wrote:
On 07/08/2014 03:45 AM, Oliver Grawert wrote:
Am Montag, den 07.07.2014, 22:45 +0200 schrieb Alexander Sack:
...
To be clear, we are wanting to support devices that are
As you may be aware, we are transitioning autopilot to Python 3 by default so
that we can remove Python 2 from the touch images. The key to this is to
complete the port of the default install click app tests to Python 3, which
will allow us to drop Python 2 dependencies from the default autopilot
On May 02, 2014, at 05:55 PM, Steve Langasek wrote:
This does not impact the unity7 desktop autopilot usage. My understanding
is that autopilot python2 support will continue to be maintained for
compatibility with unity7. But as unity7 is not on the phone,
python-autopilot shouldn't be there
On Apr 30, 2014, at 08:59 PM, Robert Park wrote:
I also landed thomi's new autopilot-legacy, which is a fork of
autopilot containing python2 code that will soon be dropped from
autopilot, however I don't think this is actually used anywhere or
seeded just yet so this shouldn't impact image #6.
On Apr 30, 2014, at 04:43 PM, Chris Gagnon wrote:
I have a merge proposal to fix the gallery app flakyness here:
lp:~chris.gagnon/gallery-app/autopilot-fix-flakyness-and-make-work-on-desktophttps://code.launchpad.net/%7Echris.gagnon/gallery-app/autopilot-fix-flakyness-and-make-work-on-desktop
On Apr 03, 2014, at 02:15 PM, Timo Jyrinki wrote:
Note that this is all AP:s run after one another without reboots or
sleep:s, except for that one I did when mediaplayer_app encountered a
problem. There were no new crash files in /var/crash, but this wasn't
a wiped update so I had four .crash
On Apr 03, 2014, at 04:33 PM, Didier Roche wrote:
I think it's still the same than the one we have for weeks in the
dashboard. Lukasz should have poke you multiple times about it. (this is the
/var/log/syslog permission issue):
On Apr 03, 2014, at 05:10 PM, Łukasz 'sil2100' Zemczak wrote:
Right. I tried fixing that myself some time ago, but the problem was
that system-image-dbus is started by python-dbusmock. I didn't see any
easy way of overriding the system .service files. Starting it manually
won't help as dbusmock
On Mar 13, 2014, at 06:43 PM, Łukasz 'sil2100' Zemczak wrote:
I also tried poking around the system-image-dbus crasher we're
encountering all the time. Barry is taking a look at it as well, but it
seems to be a really really strange error in overall. Even when making
/var/log/system-image and
On Mar 06, 2014, at 02:13 PM, Alejandro J. Cura wrote:
So, while the updates are downloading, how is s-i kept alive if the
user switches to other apps? Is it somehow escaping the app lifecycle?
Yes, because s-i isn't an app. It's a system bus service itself which is
invoked by system settings
I have a new version of system-image in my PPA that should fix the traceback
Alan was seeing while manual downloading was enabled. This is a follow up to
the previous fix (in s-i 2.1) for automatic downloading. The scenario is
outlined in Test B in the s-i test plan:
On Mar 03, 2014, at 02:50 AM, Alejandro J. Cura wrote:
You mention that you don't like the download manager doing the
installation, but to put it more strictly: the download manager is
actually just running a command given by the scope when a given
download is completed. And the installation
On Mar 02, 2014, at 06:50 PM, Зонов Роман wrote:
The default update mechanism is therefore image based. We build new images
on our build infrastructure, generate diffs between images and publish the
result on the public server. - part of Stéphane Graber's post. Fox example,
I have...1036 build of
On Mar 01, 2014, at 06:54 PM, Łukasz 'sil2100' Zemczak wrote:
I wonder then why the silo was marked as 'Tested: Yes' if the basic
testplan wasn't completed? It was also my fault for letting it through
and I'm really pissed about that. Apologies here.
My guess is that we were so focused on fixing
On Feb 26, 2014, at 01:58 PM, Manuel de la Pena wrote:
Yup, looks good to me too. I ran the u-s-s AP tests and they all passed,
and did a manual update.
We can release this when the embargo is lifted IMO. I'll watch out for
that.
+1 too from the udm side.
All systems go! Thanks for all
On Feb 26, 2014, at 03:37 PM, Bill Filler wrote:
I'm looking at this with the help of Omer. It's very strange as the
failure is simply trying to switch from the main view to the Albums tab
(via the ubuntu-ui-toolkit-emulator classes) and that operation does not
succeed. It's getting a time out
On Feb 24, 2014, at 11:50 PM, Bill Filler wrote:
- gallery_app (Bill Mathieu)
- test_album_title_fields
cyphermox and I ran all tests on the device without failure
I haven't seen this one either when testing on amd64.
-Barry
--
Mailing list: https://launchpad.net/~ubuntu-phone
Post to
I've been testing landing #10, which includes a new system image update stack
(system-settings, system-image, and ubuntu-download-manager). I'm
specifically looking at fixing LP: #1277589 and LP: #1284217.
https://bugs.launchpad.net/ubuntu-system-image/+bug/1277589
On Feb 24, 2014, at 06:03 PM, Dimitri John Ledkov wrote:
* ubuntu-ui-toolkit
https://code.launchpad.net/~xnox/ubuntu-ui-toolkit/py32ap/+merge/207757
( needs to land )
You'll need one small patch. See my comment in the mp.
-Barry
--
Mailing list: https://launchpad.net/~ubuntu-phone
Post to
On Feb 20, 2014, at 01:10 PM, Iain Lane wrote:
That'll make it hard to verify Barry's fix. Barry, I've made a CI train
request - line 47 on the spreadsheet. To that I added a revert in
ubuntu-system-settings which re-enables the functionality. Would you be
able to add your s-i branch(es) to this
On Feb 20, 2014, at 04:11 PM, Loïc Minier wrote:
Should we build some kind of remote recovery channel to remotely fix
any screwups in the system-image updates stack? There was a workaround
this time, but it could happen that we lock production users out of all
updates.
Do you mean, like a
Over the last week or so, we've had a lot of reports of folks not being able
to update their devices using System Settings. This has been quite tricky to
track down. I think I have a fix, and I'd like to ask the adventurous among
you to test it out. If you do, please follow up here, or in LP:
On Feb 19, 2014, at 05:58 PM, Manuel de la Pena wrote:
As from my part I can let you know that I have proposed a new branch that
does what is requested + it ensure that no to files will ever write in the
same temp path via a mutex. This does no have a huge performance impact. I
hope to land this
On Feb 13, 2014, at 03:51 PM, Pat McGowan wrote:
[1] FileNotFoundError: /var/lib/system-image/blacklist.tar.xz
https://bugs.launchpad.net/ubuntu-system-image/+bug/1277589
See comment #40 if you want the all gory details.
-Barry
--
Mailing list: https://launchpad.net/~ubuntu-phone
Post to
On Feb 10, 2014, at 11:16 AM, Alan O'Dannel wrote:
At the end of the update I receive a message indicating that a file was not
found. (FileNotFoundError:/var/lib/system-image/blacklist). The name appears
to truncated.
Is this unique to my device (mako), or is there a problem with the OTA image?
On Feb 10, 2014, at 02:56 PM, Stéphane Graber wrote:
I did a quick wget test on my laptop here and they all download fine and
all .asc signatures match with the .tar.xz so they don't appear to be
corrupted.
The next thing to try, for folks who are seeing this problem, is to compare
the checksums
On Feb 10, 2014, at 12:47 PM, Alan O'Dannel wrote:
All, I just tried the update again, this time I received the error (system
image.gpg.SignatureError).
Okay, so here's the thing to do:
Take a look at your /etc/system-image/client.ini file to find the locations of
the image_master,
On Jan 29, 2014, at 09:40 AM, Michel Renon wrote:
While being also very disappointed by lack of Python support in Ubuntu Touch,
I recognize it's only a pragmatic decision : having several python runtime
running was not possible on a mobile device.
That will change as mobile devices inevitably
On Jan 27, 2014, at 11:42 PM, Sam Bull wrote:
I thought there was a plan to support python3 in 14.04?
...
Using Python over our existing Java implementation would reduce our app
size by around 100x (assuming python3 is pre-installed), and create a
much more reliable, stable and efficient app.
On Jan 13, 2014, at 10:28 AM, Didier Roche wrote:
Agreed, not sure about what we can do about that one though (apart from
--overwrite in those branches everytime on ubuntu:foo).
I'm not sure there's anything we can *easily* do about it (except perhaps to
make it clear in the documentation -
On Jan 09, 2014, at 08:34 AM, Didier Roche wrote:
So, the idea that we enforced from this process are quite simple:
source package name == project name. So, if you have foo source package in
Ubuntu where we are upstream for, you know that you can confidently bzr
branch lp:foo and that's what is
On Jan 07, 2014, at 02:50 PM, Dimitri John Ledkov wrote:
Whilst the emulator improvement work is on-going, I've spend some time
getting autopilot tests execution using the emulator running.
Nice work! A quick note: run-tests.sh will fail if you *also* have a physical
device plugged in, e.g. via
On Jan 08, 2014, at 09:36 AM, Robert Park wrote:
https://wiki.ubuntu.com/DailyRelease/InlinePackaging has been on the
wiki for a while now (nearly a year I think). The landing team has
been making these changes to the various canonical-upstream projects
as we add them to the daily_release
On Dec 13, 2013, at 11:05 PM, Dimitri John Ledkov wrote:
dbus apis are hard, hence a few dbus apis are provided as shared-libraries
(essentially generate client code and compile it into shared library). When
looking at dbus api, as if it's a compiled generated shared library the
ABI/API break is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Dec 17, 2013, at 02:25 PM, Alberto Mardegan wrote:
In fact, it was not necessary: the ApplyUpdate() could have stayed as it was,
and yet be processed asynchronously, allowing the main loop to continue
running. I'm not sure if that's possible to
On Dec 17, 2013, at 10:50 PM, Alberto Mardegan wrote:
But if I got it right, Barry needed an asynchronous method *implementation*,
on the server side.
Correct.
Actually the tutorial you linked if mentions that it's possible, however it
doesn't document it:
Thanks for the followup Leo! I don't have much more to add, but let me
comment quickly on a few things.
On Dec 16, 2013, at 06:26 PM, Leo Arias wrote:
If we have to change the test client for the tests to pass, we will need to
communicate it to all our known clients. Ideally, getting a +1 on
I'm writing this email in response to LP: #1260712, mostly as a post-mortem
and so we as a team can discuss ways to improve our processes so that we avoid
such problems in the future, not just with system-image and system-settings,
but across all our mobile components. Apologies in advance for
On Nov 13, 2013, at 01:50 PM, Barry Warsaw wrote:
I think system-image 2.0 is ready for release, and would like to request a
landing slot.
In the meantime, if you want to test it:
https://launchpad.net/~barry/+archive/experimental/+packages
Cheers,
-Barry
signature.asc
Description: PGP
On Nov 14, 2013, at 08:21 AM, Didier Roche wrote:
With all our testing down (CI infra not available), I would love to wait for
getting the first test results since last week before we start landing this
one. Also, can you please file the landing spreadsheet with those info (your
manager can help
On Oct 31, 2013, at 06:35 PM, Barry Warsaw wrote:
There's a catch though: I have to change the D-Bus API slightly. The current
API is documented here:
https://wiki.ubuntu.com/ImageBasedUpgrades/Client
The affected method is ApplyUpdate(). Currently this is defined as a
synchronous method
On Oct 24, 2013, at 02:04 PM, Oliver Grawert wrote:
yes, try to use the following command while connected via USB:
adb shell system-image-cli -c trusty -b 4 -v
that will switch you to trusty and install build #4 (all further trusty
updates can happen through the GUI now, you will only need ot
On Sep 13, 2013, at 10:32 AM, Omer Akram wrote:
cool thanks. I think we need to change it to be -c instead of --channel or
change system-image-cli to use --channel argument.
system-image-cli -c and --channel are synonymous if you have at least version
1.3 (with 1.5.1 being the latest release).
On Sep 06, 2013, at 12:39 PM, Robert Park wrote:
I just did this and it bricked my phone (screen black, can't get it to
turn on regardless of what combinations of button presses i might hold
down). Here was the error message during flashing:
It's bricked my Nexus 7 in the past. I got it working
On Aug 29, 2013, at 11:11 AM, YC Cheng wrote:
I put those information on https://wiki.ubuntu.com/Touch/Install as a
section Check version after install.
On my n4 install 20130827.2, the client.ini content:
[service]
base: system-image.ubuntu.com
http_port: 80
https_port: 443
channel: daily
On Aug 28, 2013, at 05:45 PM, Sergio Schvezov wrote:
System images also create /etc/ubuntu-build
and /etc/system-image/channel.ini
So the media-info is from cdimage and the channel/ubuntu-build is from the
system image which don't necessarily match. On the same system:
# cat
On Jul 25, 2013, at 06:42 PM, Василий Алексеенко wrote:
please help.
# phablet-flash --ubuntu-bootstrap
adb shell system-image-cli not work.
# adb shell system-image-cli
Traceback (most recent call last):
File /usr/bin/system-image-cli, line 9, in module
On Jun 18, 2013, at 01:18 PM, Josh Leverette wrote:
I'd really like to know if Canonical has any more information they
can share about their plans for full OS updates in the future?
We're calling these Image Based Upgrades and everything's public. There's a
wiki page for the spec:
73 matches
Mail list logo
