Problem with magic-device-tool and Nexus 5
Flohack last edited by
@tH3f0rC3 Actually the mdt is my preferred way since you cannot to it wrong TWRP will not install UBports at all...
Thats right, but you can move the file structure of UT to the device and installing UT in this way. You can find a description here: https://askubuntu.com/questions/767323/how-to-install-ubuntu-on-meizu-pro-5-that-was-originally-with-android
Unfortunately I don't know if this way still works with the UBports image.
MDT might be the easiest way, but as soon as something goes wrong, you can't really figure out where the problem comes from.
I followed the instruction without succeed. Maybe someone else knows more and can help me.
well it's not that difficult to pull the magic out of the tool ( sorry )
Read through from here
to ... I don't know where it leads you, probably
and execute the actual commands manually to narrow down what fails where.
@tH3f0rC3 Both the Canonical way and the MDT sometimes have problems due to the cache content. I have used this workaround for MDT with success:
- Switching the device off and leave it off for a while (30 seconds or so).
- Remove your ~/.cache/ubuntuimages and all its content.
- Start up in fastboot mode.
- Re-run the MDTool.
Repeat the steps if it fails a few times (5 times or so). Also make sure bootfast tells you that it is unlocked.
The same kind of workaround also worked for me with the Canonical procedure.
It's of course better to dig down to the actual problem, but sometimes saving some time is also very useful.
Two good ideas, thanks! I will first try hans
idea than doinks
I will give an update afterwards.
I still get the error message:
err: fork/exec /usr/bin/xz: cannot allocate memory
Again and again after cleaning cache and running MDT. Bootloader is unlocked.
I just checked the MDT code. The installation sticks at the following line:
ubuntu-device-flash --server=http://system-image.ubports.com touch --channel=ubp
- orts-touch/legacy --device=hammerhead --bootstrap
And now I found the solution. As simple as it is...
Using su not sudo...
Good to hear that it worked!
I didn't really get what solved it now. In the command you posted there was neither a su nor a sudo.Would be nice if you feed back to mdt what they did wrong and what needs to change such that it just works for the next guy
@tH3f0rC3 It's very nice that you found a solution for you, but I don't really understand why that worked for you. I followed the instruction, with sudo, just a couple of weeks ago and the only problem I had was that I had to remove the cache a couple of times before it worked.
Maybe it worked for me, because I used a Raspberry Pi with Ubuntu Mate. I'm not quite sure how the user and sudoers group management works there.
I'm pretty sure that by using a "fully prepared" working system, this error does not occur.