I think I figured out a solution to the Container is not connected to the Internet error on Ubuntu 16.04.

It seems that LXD switched to setting up its default bridge lxdbr0 as link-local only (no Internet connection) around the beginning of April 2016: article explaining the change here. From what I can tell, this decision was reversed before the release of 18.04 because the issue does not occur there. I'll see if I can submit a patch to Crossbuilder to fix this.

Fix "Container is not connected to the Internet"

To set up the bridge on your system, run sudo dpkg-reconfigure -p medium lxd. If you like you can carefully answer each question, but mashing enter to get through the setup works too. This will add an IPv4 and IPv6 subnet to your bridge.

After setting up the bridge, your crossbuilder container still won't be set up correctly. Delete it by running crossbuilder delete.

Once you complete these steps, you should be able to run crossbuilder successfully.

@stefano That was answered last time. There is currently nothing in the Edge channel that is interesting to anyone but halium porters.

https://forums.ubports.com/topic/206/will-you-port-to-device-x

I'm really quite upset with the turn this thread took, so I'm locking it now.

The reason Rodney even became aware of this thread is because I complained about the tone it had taken in its last few posts. I get (probably unnecessarily, it's a personal failure) upset when people suggest that "thing x should be critical because it affects me". I also get upset about answering questions about specific bugs in the Q&A. Before long, the sessions become long talks about how Bluetooth is in a bad state because of greater market reasons, or how Libertine (which we acknowledge is experimental, but we put in the image for exactly that reason) isn't working in exactly the way someone wants. More than that, we don't have a full understanding of why some bugs occur so we end up speculating for too long in front of the audience. It's not fun for the viewers and it's certainly not fun for the team.

As for whether things are a priority or not, we've put forward our major ideas for the next few releases in the milestones. I grant you that they aren't filled with specific bugs, but they say the "big things" we're working on.

The reasoning for Bluetooth being in a poor state is not for lack of trying or for lack of impact. We know that Bluetooth is an important function of a smartphone. However, it is an unreliable (at best) protocol with tons of vendor-specific "gotcha!"s and weirdness. It's likely that fixing a bug with one device by tweaking a timing or changing a message will actually break another device. Personally, this bums me out. I love to use Bluetooth car kits and other gadgets. Not having them with UT is unfortunate.

Even the big players have trouble with Bluetooth. Look at the one-star reviews for any Bluetooth car kit and you'll find lots which say "this worked with iOS 10 but not 11" or "my Android updated and now this broke, what a piece of crap". These are companies who can devote entire teams to the protocol and, honestly, it's still terrible.

We may have paid developers, but this is still an open source community and our team is still extremely small. There's a huge amount of power in the "scratching an itch" factor. Bugs are fixed most completely when an interested developer picks them up and pulls them through to completion.

Let me be very clear: I'm not trying to attack anyone with this message. If you feel that I am, PM me and let me know so I can edit any ambiguity out. I'm also not saying that Bluetooth is not important, rather that it is an undue amount of effort for little forward movement. In more concrete terms, we could spend the time to fix Bluetooth for one gadget or tackle OTA-5.

If you'd like to solicit feedback about a specific Bluetooth device, please open another thread in the Support section. If you want to discuss anything I've said in this message, opening a thread in General is probably the best course of action. Opening megathreads like this is not conducive to good discussion in this forum software.

To be clear, redirection of 15.04/rc and devel to 16.04 does not start until next Monday, the 3rd. Until then, switching channels like that will not upgrade you to 16.04

These steps will help you upgrade your device running Ubuntu Touch OTA-3 to OTA-4.

Please note that there are still apps which have not been rebuilt and packaged for the OpenStore on 16.04. It is a good idea to open the apps you need most at the OpenStore website and check whether or not a download is available for Xenial. Also make sure you have read the release announcement and are able to deal with the known issues.

With that, let's get started.

1. Get the UBports Installer by clicking "Install Ubuntu Touch" on this page. The device model listed doesn't matter at this point.
2. Start the UBports installer and follow the instructions to get to the "Ready to install!" page
3. Click "Change options" and select 16.04/stable as your channel. DO NOT CHECK WIPE. Click "Close".
4. Under "Install options", ensure that 16.04/stable is listed as your channel and Wipe is set to No.
5. Click "Install" to start the installation process. Follow the installer's prompts to complete the process.

After your phone goes through the "Installing Update" screen and reboots, you'll have Ubuntu Touch 16.04!

Ah, I see that it's probably better to fix the problem in Crossbuilder than invent a new way to do all of this... Looks like some work is going on on the front. I'll see if I can look up any more information on it and come back to this.

I have this USB 3.0 hub / network adapter combo. It appears to use the fairly standard r8152 driver. I tested using it on the Fairphone 2, Nexus 5, and Nexus 7 2013 WiFi. These were the steps I used to make it work:

1. Plug it in
2. That is it.

Unfortunately, there is no interface built in to Ubuntu Touch for managing wired Ethernet devices. However, a network with DHCP should connect with no issues whatsoever if you have a fairly standard Ethernet adapter. Are you having any issues with your setup?

This is a proposal to change the UBports release workflow by adding a new "edge" channel to our rootfs builds. I'd like to know the thoughts of the people who it will affect: mainly Halium and Ubuntu Touch developers.

What is currently not working?

Currently, images are promoted from devel to rc to stable. This creates a pipeline where a known good image on devel will eventually become the release image, which is overall good for setting user expectations. It also encourages developers to keep packages included into devel stable as they are candidates for promotion at any time.

We've found that this system is great when we are only introducing small features and fixing bugs, which realistically has been the majority of our work over the past year. However, we're starting to see the cracks. We are not able to introduce large changes to the devel channel for risk of breaking the experience for users there. Some projects we are going to undertake after the OTA-5 (not 4) release will require these large changes. These projects include:

• Upgrading Libhybris
• Upgrading Mir
• Upgrading Unity8
• (most importantly) Fixing Issue 404, "Ubuntu Touch does not run on unmodified Halium" and 494, "Mir servers fail to run on devices that ship with CAF's Android for MSM 7.1"

What will be changed?

I propose that we augment our current release channels, stable, rc, and devel, with a new channel called edge. This channel will be built daily for all devices using an edge rootfs.

The edge rootfs will be built from a branch extension of xenial, possibly xenial_-_edge. This will ensure that only specifically selected packages will diverge from the normal image.

edge images will not be candidates for promotion to any other channel. Instead, pull requests will be made from xenial_-_edge to xenial. After a PR has been accepted, the package will need to be removed from xenial_-_edge so that it will no longer diverge.

We will be very clear that the edge channel is expected to break at any time for any device. It is for developers, not users.

How is this different than using qa-scripts?

The edge channel is primarily useful for Halium developers. It is much more convenient for them to download a single image and install it than the currently required hacks and reinstalls of packages. Since the channel will also be available for all devices, it provides a good testing ground to ensure that changes that fix Halium devices do not break our officially supported devices.

Personally, I'll usually run the commands to build the software via an adb shell session rather than using Crossbuilder. I haven't been able to run crossbuilder yet.