Fwd: Re: [gentoo-soc] Weekly Report: Portage Powered Android

Fwd: Re: [gentoo-soc] Weekly Report: Portage Powered Android

[Gunwant Jain]

[-- Attachment #1.1: Type: text/plain, Size: 51 bytes --]

Sorry, didn't cc gentoo-soc in the attached reply.

[-- Attachment #1.2: Type: message/rfc822, Size: 2703 bytes --]

[-- Attachment #1.2.1.1: Type: text/plain, Size: 1425 bytes --]

On 20/07/01 03:14PM, Benda Xu wrote:
> > I was supposed to integrate `bootstrap-init` and `sar-preinit` into
> > SharkBait this week. I couldn't quite do that.  `bootstrap-init` was
> > initially cross-compiled for aarch64 using NDK. So the first job was
> > to get rid of NDK and use a different "build-system".  I opted for
> > CMake and ported the project to use it [1]. But the binary compiled by
> > CMake on my phone (arm64 Gentoo), would not boot Android.  The build
> > rules can be inspected on [1].
> 
> Could you please remind me why we need a bootstrap-init?  Can we just
> exec the Android init when the lxc-guest starts?

Yeah sure. Apparently, Android needs to parse its device tree for early
mounting partitions, before exec'ing `init`. Plus even before dealing
with the dt, we need to mount `/system` and switch root to it.
I could create the environment for "using /system as root" w/o the help
of `bootstrap-init` but I couldn't deal with the device tree easily. 

`bootstrap-init` creates the entire environment for android to boot from
scratch and then finally exec's `init`. So I proposed to use it instead
of manually setting up the LXC container for system-as-root devices. 
That way the setup is clean as we only need a /dev directory and a static
`bootstrap-init` binary inside of the LXC rootfs.

Please let me know if this approach is unsatisfactory.

Regards,
Gunwant

[-- Attachment #1.2.1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Fwd: Re: [gentoo-soc] Weekly Report: Portage Powered Android

[Benda Xu]

[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]

Hi Gunwant,

Gunwant Jain <therealgunwant@gmail.com> writes:

>> Could you please remind me why we need a bootstrap-init?  Can we just
>> exec the Android init when the lxc-guest starts?
>
> Yeah sure. Apparently, Android needs to parse its device tree for early
> mounting partitions, before exec'ing `init`. Plus even before dealing
> with the dt, we need to mount `/system` and switch root to it.
> I could create the environment for "using /system as root" w/o the help
> of `bootstrap-init` but I couldn't deal with the device tree easily. 
>
> `bootstrap-init` creates the entire environment for android to boot from
> scratch and then finally exec's `init`. So I proposed to use it instead
> of manually setting up the LXC container for system-as-root devices. 
> That way the setup is clean as we only need a /dev directory and a static
> `bootstrap-init` binary inside of the LXC rootfs.

In principle you can choose your way of achieving things.  But
considering you got stuck in making a functional 'bootstrap-init', I
have 2 questions.

1. If you need to prepare a proper environment for Android to boot
   inside the LXC guest, please check out LXC container hooks in
   lxc.container.conf(5) manpage.  Another init seems an overkill for
   me.

2. Why bootstrap-init needs to be written in C++?  Would a shell script
   enough?

Benda

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Fwd: Re: [gentoo-soc] Weekly Report: Portage Powered Android

[Gunwant Jain]

[-- Attachment #1: Type: text/plain, Size: 2679 bytes --]

On 20/07/02 08:05AM, Benda Xu wrote:
> >> Could you please remind me why we need a bootstrap-init?  Can we just
> >> exec the Android init when the lxc-guest starts?
> >
> > Yeah sure. Apparently, Android needs to parse its device tree for early
> > mounting partitions, before exec'ing `init`. Plus even before dealing
> > with the dt, we need to mount `/system` and switch root to it.
> > I could create the environment for "using /system as root" w/o the help
> > of `bootstrap-init` but I couldn't deal with the device tree easily. 
> >
> > `bootstrap-init` creates the entire environment for android to boot from
> > scratch and then finally exec's `init`. So I proposed to use it instead
> > of manually setting up the LXC container for system-as-root devices. 
> > That way the setup is clean as we only need a /dev directory and a static
> > `bootstrap-init` binary inside of the LXC rootfs.
> 
> In principle you can choose your way of achieving things.  But
> considering you got stuck in making a functional 'bootstrap-init', I
> have 2 questions.

I would like to clarify first that bootstrap-init works fine, but due to
the nature of build-system it requires, I was having difficulties in
compiling it natively in arm64 Gentoo.
 
> 1. If you need to prepare a proper environment for Android to boot
>    inside the LXC guest, please check out LXC container hooks in
>    lxc.container.conf(5) manpage.  Another init seems an overkill for
>    me.

I was going with this approach initially, but the container configs just
don't seem apt for a process like this. I mean to mount the early
partitions only, I have no clue how I would approach parsing the device
tree using the LXC conf. 

Although I had made some slight edits to the original container hook
scripts, for keeping the rootfs clean after reboots and more. You could
check the modified scripts in [1].

> 2. Why bootstrap-init needs to be written in C++?  Would a shell script
>    enough?

I followed Magisk's approach of booting SAR Android. I thought of
rewriting the entire init but realised that that would be rather
inefficient. Therefore, I stripped all the "Magisk-y" code and put
forward the bare minimum required for functioning.
In theory, we could rewrite it all in shell, but then again, I would not
recommend it as it could be somewhat lengthy. 
Moreover, this setup is scalable and it could be extended later for any 
new boot-scheme Android pulls up.

If required by any situation, I can willingly rewrite it in shell as 
well.

Regards,
Gunwant

[1] https://wantguns.gitlab.io/blog/sharkbait/starting_android_in_gentoo/#install-lxc

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Fwd: Re: [gentoo-soc] Weekly Report: Portage Powered Android

[Benda Xu]

[-- Attachment #1: Type: text/plain, Size: 2090 bytes --]

Hi Gunwant,

Gunwant Jain <therealgunwant@gmail.com> writes:

>> In principle you can choose your way of achieving things.  But
>> considering you got stuck in making a functional 'bootstrap-init', I
>> have 2 questions.
>
> I would like to clarify first that bootstrap-init works fine, but due
> to the nature of build-system it requires, I was having difficulties
> in compiling it natively in arm64 Gentoo.

OK, good.

>> 1. If you need to prepare a proper environment for Android to boot
>>    inside the LXC guest, please check out LXC container hooks in
>>    lxc.container.conf(5) manpage.  Another init seems an overkill for
>>    me.
>
> I was going with this approach initially, but the container configs just
> don't seem apt for a process like this. I mean to mount the early
> partitions only, I have no clue how I would approach parsing the device
> tree using the LXC conf. 
>
> Although I had made some slight edits to the original container hook
> scripts, for keeping the rootfs clean after reboots and more. You could
> check the modified scripts in [1].

Now I understand, thanks.

>> 2. Why bootstrap-init needs to be written in C++?  Would a shell script
>>    enough?
>
> I followed Magisk's approach of booting SAR Android. I thought of
> rewriting the entire init but realised that that would be rather
> inefficient. Therefore, I stripped all the "Magisk-y" code and put
> forward the bare minimum required for functioning.
> In theory, we could rewrite it all in shell, but then again, I would not
> recommend it as it could be somewhat lengthy. 
> Moreover, this setup is scalable and it could be extended later for any 
> new boot-scheme Android pulls up.

Good.  That makes sense to me now.  

One last concern, what is your plan in the long run?  If Magisk update
his code, will you be able to easily cherry-pick to you code repository?

> If required by any situation, I can willingly rewrite it in shell as
> well.

I don't have strong opinions on this as long as it is understandable and
works.

Benda

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Fwd: Re: [gentoo-soc] Weekly Report: Portage Powered Android

[Gunwant Jain]

[-- Attachment #1: Type: text/plain, Size: 2491 bytes --]

On 20/07/02 03:47PM, Benda Xu wrote:
> Hi Gunwant,
> 
> Gunwant Jain <therealgunwant@gmail.com> writes:
> 
> >> In principle you can choose your way of achieving things.  But
> >> considering you got stuck in making a functional 'bootstrap-init', I
> >> have 2 questions.
> >
> > I would like to clarify first that bootstrap-init works fine, but due
> > to the nature of build-system it requires, I was having difficulties
> > in compiling it natively in arm64 Gentoo.
> 
> OK, good.
> 
> >> 1. If you need to prepare a proper environment for Android to boot
> >>    inside the LXC guest, please check out LXC container hooks in
> >>    lxc.container.conf(5) manpage.  Another init seems an overkill for
> >>    me.
> >
> > I was going with this approach initially, but the container configs just
> > don't seem apt for a process like this. I mean to mount the early
> > partitions only, I have no clue how I would approach parsing the device
> > tree using the LXC conf. 
> >
> > Although I had made some slight edits to the original container hook
> > scripts, for keeping the rootfs clean after reboots and more. You could
> > check the modified scripts in [1].
> 
> Now I understand, thanks.
> 
> >> 2. Why bootstrap-init needs to be written in C++?  Would a shell script
> >>    enough?
> >
> > I followed Magisk's approach of booting SAR Android. I thought of
> > rewriting the entire init but realised that that would be rather
> > inefficient. Therefore, I stripped all the "Magisk-y" code and put
> > forward the bare minimum required for functioning.
> > In theory, we could rewrite it all in shell, but then again, I would not
> > recommend it as it could be somewhat lengthy. 
> > Moreover, this setup is scalable and it could be extended later for any 
> > new boot-scheme Android pulls up.
> 
> Good.  That makes sense to me now.  
> 
> One last concern, what is your plan in the long run?  If Magisk update
> his code, will you be able to easily cherry-pick to you code repository?

I don't think we are in a position to cherry-pick upstream commits as I
have proposed to change the project structure for adapting a newer
build-system (vs NDK) in the cmake branch of the repo [1].
Nevertheless, I will surely addon and maintain it for future
versions of Android; either by following Magisk, or by implementing our
own way of doing stuff.

Regards,
Gunwant

[1] https://gitlab.com/WantGuns/bootstrap-init/-/tree/cmake

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Fwd: Re: [gentoo-soc] Weekly Report: Portage Powered Android

[Benda Xu]

[-- Attachment #1: Type: text/plain, Size: 629 bytes --]

Hi Gunwant,

Gunwant Jain <therealgunwant@gmail.com> writes:

>> One last concern, what is your plan in the long run?  If Magisk update
>> his code, will you be able to easily cherry-pick to you code repository?
>
> I don't think we are in a position to cherry-pick upstream commits as I
> have proposed to change the project structure for adapting a newer
> build-system (vs NDK) in the cmake branch of the repo [1].
> Nevertheless, I will surely addon and maintain it for future
> versions of Android; either by following Magisk, or by implementing our
> own way of doing stuff.

Go ahead. I respect your choice.

Yours,
Benda

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]