Ubuntu Touch Mainline Generic amd64 Issue

hacker1024

It sounds like a graphics issue, have you tried using different graphics adapters?
There's no such things as a "standard IMG" - img files are usually just raw, byte-for-byte copies of disks or partitions, so it's the filesystem/partition table that defines them. You should be able to use dd to write it to a disk/partition. (Try running fdisk -l /path/to/img for more info on its contents!)

nontrivial

@Keneda

With that logic you could argue that Android is a much better option for phones so why should anybody spend any time developing Ubuntu Touch? Ubuntu has been my daily driver since almost as long as it has existed and I would like to use the same operating system on my desktop as well as my phone. I also believe that I (and probably other people) would be more motivated to use Ubuntu Touch and contribute to it's development if they used it more often, and running it on the desktop accomplishes that.

nontrivial

@hacker1024

Thanks for the response. I have tried loading the image in VirtualBox and qemu, and the boot process hangs in the same spot for both. I would be happy to try other graphics adapters, but how do I do that in VirtualBox or qemu? I don't have a lot of experience with qemu. I had failed mounting the image as a loopback, but I figured out what my issue is so I will try digging into the contents to see what I can find. If you could point me to whatever or whoever generates the image (there isn't any information about that on the download page) I would be happy to contribute back anything I find.

I suspect that nobody is going to confess to creating the image and I'm not going to be able to find any documentation or repository for it, in which my plan B is to get Lomiri running on stock Ubuntu 18.04, but A) it looks like that isn't working right now either and I'm not sure you what if any Touch apps you can run with that setup.

nontrivial

For posterity, if anybody would like to try running the image with qemu, the command is

qemu-system-x86_64 -hda ubuntu-touch-mainline-generic-amd64.img -vga virtio -display gtk,gl=on -m 2G -enable-kvm

I had to remove the display option to make it happy (I think the stock apt-gettable qemu is not compiled with support for it) but doing so did not seem to make a difference in the results as far as getting the image to boot.

arubislander

The image is known to not run in VM's but even Marius was surprised by how well it ran on actual hardware. You could try dd-ing it to a spare USB drive and booting from that.

The author of Ubuntu Unity remix has also announced a Live boot only image based in 18.04 here

nontrivial

@arubislander

Thank you so much! That is extremely helpful.

Keneda

@nontrivial said in Ubuntu Touch Mainline Generic amd64 Issue:

With that logic you could argue that Android is a much better option for phones so why should anybody spend any time developing Ubuntu Touch?

Because androïd is not GNU, and some people don't want google to be their life owner, and prefer GNU/Linux + freedom to Android/Linux + crapware & data mining.

Ubuntu has been my daily driver since almost as long as it has existed and I would like to use the same operating system on my desktop as well as my phone.

I own my MX4 uTouch Edition since it was made availiable by canonical, 5 years ago now, but don't think it's relevant here.
And very good for you to love uTouch to the point you want to use it on your desktop too.
I'll wait untill convergence is full working in order to make my phone a second desktop.

I also believe that I (and probably other people) would be more motivated to use Ubuntu Touch and contribute to it's development if they used it more often, and running it on the desktop accomplishes that.

Most people that use uTouch, use it as it was designed in the first place, a mobile GNU/Linux OS.
Lot of them already have a GNU/Linux on their desktop computer, and use softwares that are not ported to uTouch.
Libertine not already fully fonctionnal.

Anyway, the only thing i did here in the first place, is to tell you why you should not be "shocked" that people using uTouch on their smartphone don't use it on their desktop too : there are already full working non touch native based device GNU/L distros for that, and for the moment, appart from testing, no real good reason for them to switch on it.

And don't forget not evenry GNU/Linux users like ubuntu on desktop, even if they use uTouch (as it's the most efficient GNU/L smartphone OS).

hacker1024

@nontrivial https://www.virtualbox.org/manual/ch03.html#settings-display

Unfortunately, I don't know any more about the image than you do. Here's the virtualbox docs on graphics adapters.

arubislander

Just to clear up any misunderstandings. It was never Canonical's goal, nor is it the aim of the UBports' project, to have Ubuntu Touch (the operating system) running on non mobile devices.

What is most definitely the goal is to have Lomiri, formerly known as Unity8, (the desktop environment) running on a wide range of devices, including desktop PC's and laptops.

This is being worked on with the push to get Lomiri packaged in other distributions like Debian, Arch and PostmarketOS.

I believe getting Lomiri easy to be installed in these distributions and their derivatives will increase exposure and get more developers interested in working on it.

Keneda

@arubislander

Yes. Adding to that, a side goal about uTouch is to achieve convergence.

nontrivial

So just to follow up, I wanted to get the amd64 port working for several reasons:

I really like Ubuntu, I really like Unity/UT/Lomiri, and I really like running the same OS on as many devices as possible.
I have a couple i386 netbooks that I still use occasionally and with Ubuntu 20.04 ending support for i386 I thought UT would greatly extend their usable life.
For the first time in a long time I have some spare time, I was thinking of spending at least some of that contributing, and I figured the easiest way to develop apps would be run UT in virtual machine.

After a bit of research it looks like even though amd64 is listed as a supported platform that just needs a config file to be contributed in order for it to be run, in reality it really isn't supported and there isn't much interest in supporting it. So the first two reasons are toast but I still plan on spending some time contributing to the project. I'm a pretty seasoned devop but I'm having trouble finding enough information to get started so it might take me a while to become productive.

arubislander

A part of the Convergence story is that apps written for Ubuntu Touch should be able to run on different form factors. They should be 'convergent' or as it has become.known in web parlance 'responsive'. To that aim it is not necessary to run Ubuntu Touch in a VM to develop apps for it.

Have you already taken a look here to get you started on app development?

nontrivial

@arubislander

Well, yeah, my ultimate goal was to try and use UT apps as my "daily driver" desktop environment. I never got far enough getting Lomiri running to see if that was possible, but hopefully it will get to that point eventually. I just assumed that to get the apps running I needed full UT running on the hardware.

I found that page on developing first, and that page has a lot of details but I was hoping for an (updated) overview. For example, the page that explains the Web App explains the webapp-container command, but nothing on where to run it or how to submit an app to the store. Various other documents mention clickable, the Ubuntu SDK, and some places mentions that some tools work on different Ubuntu versions and some aren't supported. I'm still not sure where clickable fits in. It all kind of assumes you know what all the tools are for, their history, how they fit together, and that you just need basically the man page of a tool instead of telling you what tool you need use in the first place. I did come across the UT programming course, but it mentions a lot of things that I think are out of date, so I'm not sure it is the best source. But I'm making progress and hope to be productive soon. My current best guess is it looks like you need to be running UBuntu 16.04 and use the Ubuntu SDK.

cela

@nontrivial said in Ubuntu Touch Mainline Generic amd64 Issue:

@arubislander

Well, yeah, my ultimate goal was to try and use UT apps as my "daily driver" desktop environment. I never got far enough getting Lomiri running to see if that was possible, but hopefully it will get to that point eventually. I just assumed that to get the apps running I needed full UT running on the hardware.

I found that page on developing first, and that page has a lot of details but I was hoping for an (updated) overview. For example, the page that explains the Web App explains the webapp-container command, but nothing on where to run it or how to submit an app to the store. Various other documents mention clickable, the Ubuntu SDK, and some places mentions that some tools work on different Ubuntu versions and some aren't supported. I'm still not sure where clickable fits in. It all kind of assumes you know what all the tools are for, their history, how they fit together, and that you just need basically the man page of a tool instead of telling you what tool you need use in the first place. I did come across the UT programming course, but it mentions a lot of things that I think are out of date, so I'm not sure it is the best source. But I'm making progress and hope to be productive soon. My current best guess is it looks like you need to be running UBuntu 16.04 and use the Ubuntu SDK.

I found this video tutorial helpful by CiberSheep https://forums.ubports.com/topic/3347/videotutorial-first-steps-with-clickable

nontrivial

@cela Oh wow, thank you, that helped so much. I went down a rabbit hole of information on native verses web apps because that was mentioned before clickable and by the time I figured out I was on the wrong track I was completely lost. I proposed some changes in the Getting Started section to make that more clear.

arubislander

@cela I had forgotten that resource is available! Considering it is the back of my head there in full view

ignne

For the record, I just gave ubuntu-touch-mainline-generic-amd64.img a try on my Intel tablet (Dell Venue 8 Pro).

After downloading I wrote the image to an USB stick with dd, connected the stick using an OTG adaptor and selected it in the boot device dialog [1].

It booted into gui mode just fine, but lots of stuff (like the orientation sensor or turning off the screen) doesn't work. It's a cool proof of concept anyway, especially since the performance is really good, considering that this is an old Atom tablet and booting from a slow USB drive.

YMMV, because this tablet has some quirks even without UT.
I think this might be worth looking into, because there are a lot of x86 tablets around that are to slow for a heavy Linux desktop with Gnome and all its bells and whistles, but would be ideal as a fast, modern UT device.

Oh, btw, you can make it run in a recent VirtualBox. I had to convert it using something like:

VBoxManage convertfromraw ubuntu-touch-mainline-generic-amd64.img ubports.vdi --format vdi

Make sure to enable multitouch input in the VM settings, if you have a tablet or convertible

[1]: The tablet originally ran regular Win 8 (or 10), and has a "normal" BIOS/EFI.

alaskalinuxuser

@nontrivial said in Ubuntu Touch Mainline Generic amd64 Issue:

Download latest ubuntu-touch-mainline-generic-amd64.img.xz file from https://ci.ubports.com/job/rootfs/job/rootfs-generic-amd64/
Uncompress it with unxz
Convert to VirtualBox VDI disk image: VBoxManage convertdd disk.img disk.vdi

The boot process appears to hang on "Starting virtual private network daemon".

By the way, I know this is a thread from four years ago, but if you web search running UBports image in VirtualBox, it leads here, so I thought I would update it to help the next person save some time...

After you run the convert line:
$ VBoxManage convertfromraw /home/alaskalinuxuser/snap/utqemu/common/ubuntu-touch-mainline-generic-amd64.img ./ubports.vdi --format vdi

And you try to launch it in VirtualBox, you will still hang at Starting virtual private network daemon, but the real issue is the graphic card settings, as @hacker1024 pointed out, but didn't offer the solution. What worked for me was:

Display settings in VB:
Video Memory 32 MB
Graphics Controller VMSVGA
Enable 3D acceleration
RDS and Recording (don't matter, but I use) disabled.

Setting the RAM to 1536MB and using the converted VDI drive seems to work great for me. Hopefully that helps the next person....