Skip to content
This repository has been archived by the owner. It is now read-only.

Porting Motorola Moto G 2014 "titan" #53

Closed
PabloCastellano opened this issue Jun 4, 2017 · 11 comments

Comments

Projects
None yet
3 participants
@PabloCastellano
Copy link
Member

commented Jun 4, 2017

Hello.

I love your project and would like to contribute porting my Moto G 2014 device.

In addition to opening issues about minor bugs, I've also pushed the current work to my device-motorola-titan branch banch.

What's still missing?

  • deviceinfo_flash_offset_base value
  • kernel
  • testing

According to titan.yml this device is using android_kernel_motorola_msm8226 but since my lack of knowledge I don't know how to continue.

Any help is appreciated!

@PabloCastellano

This comment has been minimized.

Copy link
Member Author

commented Jun 4, 2017

This script requires a shell more modern than all the shells that I found on your system. Please tell bug-autoconf@gnu.org about your system, including any error possibly output before this message. Then install a modern shell, or manually run the script under such a shell if you do have one.

https://pastebin.com/nF2X22ea

@ollieparanoid

This comment has been minimized.

Copy link
Member

commented Jun 4, 2017

What is your host system?

@PabloCastellano

This comment has been minimized.

Copy link
Member Author

commented Jun 4, 2017

vermuth:~$ lsb_release -d
Description:	Linux Mint 17 Qiana

(based on Ubuntu 14.04)

@ollieparanoid

This comment has been minimized.

Copy link
Member

commented Jun 4, 2017

You have tried building with pmbootstrap build linux-motorola-titan first, right?
Looks like device nodes are missing in your chroot. As suggested in #52: try to zap your chroot and re-create it (pmbootstrap chroot will re-create it). pay attention to whether the device nodes get created correctly in the log.

@ollieparanoid

This comment has been minimized.

Copy link
Member

commented Jun 4, 2017

CARCH=x86_64 abuild -d <- this is not how it is intended, the dependency resolving should be done with pmbootstrap

@PabloCastellano

This comment has been minimized.

Copy link
Member Author

commented Jun 4, 2017

JFTR: I changed the chroot directory and the issue that was preventing me from building binutils went away

@lawl

This comment has been minimized.

Copy link
Contributor

commented Jun 4, 2017

So this is an issue with ecryptfs. Should probably file a bug on ecryptfs and maybe add a message to pmbootstrap if it detects it. An easy way would be to check if the system can handle long paths.

@lawl

This comment has been minimized.

Copy link
Contributor

commented Jun 4, 2017

@PabloCastellano Do you want to report this upstream in ecryptfs that it has issues with special devices?

@ollieparanoid

This comment has been minimized.

Copy link
Member

commented Jun 4, 2017

@lawl: I have added ecryptfs to the Troubleshooting wiki page. I don't think implementing a check for it is worth it right now, but if there are lots of users having this problem in the future, we should do it.

If we do implement a check, it should really check if /dev/random etc. work after creating them, instead of assuming, that if the filename length is limited, it must be ecryptfs (reminds me of these bad browser checks: if you can't do that, you must be browser xy).

@ollieparanoid

This comment has been minimized.

Copy link
Member

commented Jun 5, 2017

@PabloCastellano: Your ecryptfs issue seems to be solved now (that newer version of eCryptFS seems to work), and further steps are described in the porting guide. I see that you have already created a device page and written down your porting status in the wiki (thanks!).

Do you have any more questions? Otherwise we'd close this ticket (the porting status is already on the wiki page, and otherwise this ticket would get quite long - so better open up a new one for specific issues). Thanks for your porting efforts so far :)

@ollieparanoid

This comment has been minimized.

Copy link
Member

commented Jun 5, 2017

Closing, as discussed on IRC.

ollieparanoid added a commit that referenced this issue Jun 6, 2017

Fix #61: Check whether device nodes exist, after they have been created.
As reported in #53, it appears that older versions of eCryptfs don't
really create the device nodes, although `mknod` does not fail on
the commandline. That's fixed now with this extra check.

PureTryOut added a commit that referenced this issue Feb 21, 2018

Fix #61: Check whether device nodes exist, after they have been created.
As reported in #53, it appears that older versions of eCryptfs don't
really create the device nodes, although `mknod` does not fail on
the commandline. That's fixed now with this extra check.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.