TWRP port attempt & help

[zefie altimitmine]

I am attempting to port TWRP to Android-x86. This in itself has a few challenges I have yet to address since most android devices use partitions and we use a single partition. That isn't the problem yet, I figured I'd address that once I got the GUI to boot, which IS my problem.

Things I've done so far:

• Hybrid sources from omni and android-x86
• Get build system to compile
• Modify android-x86 initrd to load recovery if RECOVERY=1 passed via kernel cmdline
  
• Modify android-x86 initrd's script to "detect android-x86" only on a writable partition if booting recovery (idea is to allow you to use TWRP from an ISO to modify an installed copy in case its foobar'd)
• No dependency on an existing or working system folder (modules/firmware in ramdisk)

But, I cannot actually load the GUI. It gets to stage "Loading page splash" then just dies with error 11 (segfault). The only info I have is that its "Loading page splash" as thats the last thing in recovery.log

I assume the problem is with minui and how android-x86 does graphics, and was hoping someone could give me a little more information on how exactly android-x86 does its graphics, and if I am missing a custom init.rc daemon to do so.

Once complete, while my TWRP is designed for my HP TouchSmart 300 nwfermi build, should be compatible with most Android x86 instances.

Anyone interested?

[zefie altimitmine]

Extra info because these forums don't have edit, and I just woke up and forgot:

android-x86 base: cm-14.1-x86

TWRP base: twrp-7.1

Target arch: x86 (due to my target's device's lack of SSE4, I figure an x86 build would be more compatible anyway)

[Jon West]

Let us know if you need any assistance or information

[zefie altimitmine]

Mostly just curious how the actual graphics system is initialized in standard, working Android x86. I think I am doing something wrong, as TWRP segfaults at the first attempt to draw.

This is what I have so far via recovery.log:

Starting TWRP 3.2.1-0-baeabc5b-dirty on Wed Jan 17 12:34:50 2018

 (pid 1731)

I:=> device id not found, using 'serialno'

BOARD_HAS_NO_REAL_SDCARD := true

TW_NO_REBOOT_RECOVERY := true

TW_NO_REBOOT_BOOTLOADER := true

RECOVERY_SDCARD_ON_DATA := true

TW_ALWAYS_RMRF := true

TW_NEVER_UNMOUNT_SYSTEM := true

I:Lun file '/sys/class/android_usb/android0/f_mass_storage/lun0/file' does not exist, USB storage mode disabled

I:Found brightness file at '/sys/devices/pci0000:00/0000:00:01.0/0000:01:05.0/drm/card0/card0-LVDS-1/radeon_bl0/brightness'

I:TWFunc::Set_Brightness: Setting brightness control to 149

I:TW_EXCLUDE_MTP := true

I:LANG: en

Starting the UI...

setting DRM_FORMAT_BGRA8888 and GGL_PIXEL_FORMAT_BGRA_8888

setting DRM_FORMAT_ARGB8888 and GGL_PIXEL_FORMAT_BGRA_8888, GGL_PIXEL_FORMAT may not match!

mmap() failed: Invalid argument

setting DRM_FORMAT_ARGB8888 and GGL_PIXEL_FORMAT_BGRA_8888, GGL_PIXEL_FORMAT may not match!

mmap() failed: Invalid argument

fb0 reports (possibly inaccurate):

  vi.bits_per_pixel = 32

  vi.red.offset   =  16   .length =   8

  vi.green.offset =   8   .length =   8

  vi.blue.offset  =   0   .length =   8

setting GGL_PIXEL_FORMAT_BGRA_8888

single buffered

RECOVERY_BGRA

framebuffer: 0 (1600 x 900)

Using fbdev graphics.

I:TWFunc::Set_Brightness: Setting brightness control to 149

I:Loading package: splash (/twres/splash.xml)

I:Load XML directly

I:PageManager::LoadFileToBuffer loading filename: '/twres/splash.xml' directly

I:Checking resolution...

I:Scaling theme width 0.833333x and height 0.750000x, offsets x: 0 y: 0 w: 0 h: 0

I:Loading resources...

I:Loading variables...

I:Loading mouse cursor...

I:Loading pages...

I:Loading page splash

At this point it is "killed with signal 11" and loops. Each time it tries to start, my framebuffer is wiped, but shell still works in the background, so to get around the looping issue and actually debug, I usually "mv /sbin/recovery /" so that "cannot find /sbin/recovery, giving up" or whatnot.

[Mauro Rossi]

Il giorno mercoledì 17 gennaio 2018 19:25:20 UTC+1, zefie altimitmine ha scritto:

I am attempting to port TWRP to Android-x86. This in itself has a few challenges I have yet to address since most android devices use partitions and we use a single partition. That isn't the problem yet, I figured I'd address that once I got the GUI to boot, which IS my problem.

Things I've done so far:

• Hybrid sources from omni and android-x86
• Get build system to compile
• Modify android-x86 initrd to load recovery if RECOVERY=1 passed via kernel cmdline
  
• Modify android-x86 initrd's script to "detect android-x86" only on a writable partition if booting recovery (idea is to allow you to use TWRP from an ISO to modify an installed copy in case its foobar'd)
• No dependency on an existing or working system folder (modules/firmware in ramdisk)

But, I cannot actually load the GUI. It gets to stage "Loading page splash" then just dies with error 11 (segfault). The only info I have is that its "Loading page splash" as thats the last thing in recovery.log

Do you have the logcat output?

 

I assume the problem is with minui and how android-x86 does graphics, and was hoping someone could give me a little more information on how exactly android-x86 does its graphics, and if I am missing a custom init.rc daemon to do so.

libEGL and libGLES are provided by mesa, with few modifications from upstream project

HAL gralloc module: gralloc.drm, with external/drm_gralloc local project 

extract of init.sh in device/generic/common

function init_hal_gralloc()
{
	case "$(cat /proc/fb | head -1)" in
		*virtiodrmfb)
			if [ "$HWACCEL" != "0" ]; then
				set_property ro.hardware.hwcomposer drm
				set_property ro.hardware.gralloc gbm
			fi
			;;
		0*inteldrmfb|0*radeondrmfb|0*nouveaufb|0*svgadrmfb|0*amdgpudrmfb)
			if [ "$HWACCEL" != "0" ]; then
				set_property ro.hardware.gralloc drm
				set_drm_mode
			fi
			;;
		"")
			init_uvesafb
			;&
		0*)
			;;
	esac

	[ -n "$DEBUG" ] && set_property debug.egl.trace error 

[zefie altimitmine]

Thanks for the response. I tried logcat but is was not functional. You mention gralloc but these sources are not used on twrp-minimal. I have some TWRP building experience as I have modified TWRP to fix a few device-specific quirks in my LG G6, which required me to build it from scratch. Those manifests don't use gralloc either.

However I think I mistakenly started with the omni minimal manifest rather than AOSP or lineage. I'm not sure it would make much of a difference, since I am replacing any still-used repos with android-x86's, but now that I think of it, this is leaving some hybrid omni/aosp build system, so I am going to start over with the AOSP minimal manifest, and see if I get any different results.

[zefie altimitmine]

Okay I rebuilt my build setup using the Lineage TWRP minimal manifest, since AOSP is "wip" (and it doesn't even load their bootable/recovery).. anyway same exact issue so its not anything to do with that, but now I can more easily show you the manifest, since this one is a bit less confusing.

Base manifest: https://github.com/minimal-manifest-twrp/platform_manifest_twrp_lineageos
Local manifest: https://pastebin.com/8qmwxESF

If there is anything you think Android-x86 needs (that isn't normally used in TWRP) let me know

[zefie altimitmine]

Progress so far (getting there!):
https://youtu.be/1MZUrh8Sc60

(Yes, the restored data backup is functional :D)

There is definitely something up with graphics, that was with "nomodeset vga=(i forgot, some invalid value and I pressed t in the menu list)". Also not sure why it sees touch but doesn't wanna work correctly, but one thing at a time :)

[Jon West]

Do you have any of this work pushed to your github yet? I'd love to take a look and see if we can help you figure things out.

[zefie altimitmine]

There are too many dirty hacks in both TWRP, the initrd, and the recovery ramdisk to properly make a git repo setup without even more effort that is worse that hacking this to work. I'm not sure how I'm going to distribute the source.

As for progress, I bypassed a few issues using uvesafb, disabling cursor blink, and setting the console to tty2. Touch requires double tapping at the moment but it's usable.

More soon.

[zefie altimitmine]

I posted this video trying to explain the current status, progress, and what I meant about it being a dirty setup to release source to. Apologies that its both 20min long and slightly aggressive. The aggression comes from it being the 5th time of me filming, as my phone was really being a rebel to me and cutting off the videos.

https://youtu.be/EyB9GjOa2mE

[Jon West]

No worries man :) We're here to help in whatever way we can. There's an experienced few here in these groups that would be more than happy to assist in this on finding solutions for you here. You can spot them easily by what help they provide on the threads. All of them are pretty responsive to private messages as well, so don't be afraid to reach out.

[Lambdadroid]

The DRM/KMS graphics implementation of the AOSP recovery is pretty
much broken, which might be why you can only boot with "nomodeset".

I had to fix quite a few things to get the DRM graphics implementation
working properly on my Intel Baytrail Android tablet using a recent
kernel.
The DRM related changes are at
https://github.com/me176c-dev/android_bootable_recovery/commits/drm-fix
and might help you with the crashes if you boot without the
"nomodeset" kernel parameter.

However, note that these are still written against the Android 7.1
version from TWRP. They merged the Oreo branch recently, which changed
the graphics implementation significantly, and I still need to remake
them for the newer version. If you want to apply them, you'll need to
revert to an older version of TWRP (to be exact c0c5c3a1a, "Merge "Fix
typos / inconsistencies in German language" into android-7.1", the
commit before the drm commits on the branch above).

> --
> You received this message because you are subscribed to the Google Groups
> "Android-x86" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to android-x86...@googlegroups.com.
> To post to this group, send email to andro...@googlegroups.com.
> Visit this group at https://groups.google.com/group/android-x86.
> For more options, visit https://groups.google.com/d/optout.

[zefie altimitmine]

Thanks for the info and the code. I tried to fork but there is a strange issue with github where if you already have a repo with the same name, it just does nothing, rather than offer options such as "merge branch" or "fork with new name", so I manually cloned it into a separate repo (you are still credited in the commits but it won't show I forked from you).

I cloned your repo and applied my existing modifications to your code, which worked flawlessly (or at least took my modifications patch flawlessly). I have not yet tested a build at the time of this post as I am trying to address the issues I pointed out in my 20 min video, so that I can offer a proper build system (or somewhat proper, there is still going to be a post-build script that will need to be run to inject stuff into the finished ramdisk-recovery.img since I am not prolific enough to modify the android build system to do it for me).

So far the following is now available (not yet ready to properly build):

https://github.com/zefie/android_bootable_recovery_x86target (your patches + my patches)
https://github.com/zefie/android-x86_device_generic_x86 (twrp config for device tree, I'm only targeting x86 since that is all I can test against, but should work if you apply my commits to x86_64 as well)

More soon.

[zefie altimitmine]

I'd like Chih-Wei Huang's opinion, as they seem to be the project leader, as to which direction the recovery should take. I'm not sure how to (or if its possible to) tag people on this forum.

My question is, going forward, should I:

1. Aim to make the recovery system buildable in the current android-x86 structure (when you build the main OS iso, it also creates recovery (I will have to learn to inject stuff in ramdisk-recovery.img))
   
2. Aim to make it a separate project (build a TWRP-only iso, which would allow install to an existing android-x86 install, but users are to install android-x86 separately) (will likely use a kernel with modules disabled, and all built in to the primary kernel binary)
3. Or possibly not even bother if there is no interest in including a recovery for android-x86

[Povilas Staniulis]

You can CC the post to Chih-Wei directly if you want.

I personally do think the recovery would be useful for things like doing
backups and flashing zip files. It's not really critical to have a
recovery on Android x86 (unlike on a retail Android device, especially
if you mess up the ROM), but it would be a nice addition.

On 2018.01.20 22:26, zefie altimitmine wrote:
> I'd like Chih-Wei Huang's opinion, as they seem to be the project
> leader, as to which direction the recovery should take. I'm not sure
> how to (or if its possible to) tag people on this forum.
>
> My question is, going forward, should I:
>

> 1. Aim to make the recovery system buildable in the current

> android-x86 structure (when you build the main OS iso, it also
> creates recovery (I will have to learn to inject stuff in
> ramdisk-recovery.img))

> 2. Aim to make it a *separate *project (build a TWRP-only iso, which

> would allow install to an existing android-x86 install, but users
> are to install android-x86 separately) (will likely use a kernel
> with modules disabled, and all built in to the primary kernel binary)

> 3. Or possibly not even bother if there is no interest in including a
> recovery for android-x86
>

> --
> You received this message because you are subscribed to the Google
> Groups "Android-x86" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to android-x86...@googlegroups.com

> <mailto:android-x86...@googlegroups.com>.

> To post to this group, send email to andro...@googlegroups.com

> <mailto:andro...@googlegroups.com>.

[zefie altimitmine]

Flashing zips was the original reason I started this, after realizing how much of a pain it was to manually do things like install xposed.

Although the backup and restore is also useful, already used it once when I bootlooped my install by misconfiguring substratum.

I'm not sure how to CC on here, I use the groups.google.com site, not email.

[zefie altimitmine]

Just a followup on this, your drm patch seems to work beautifully. 

Thank you very much, this is very helpful.

I will leave the uvesafb option as a fallback (like the android-x86 normal boot's nomodeset option, but uvesafb is required because TWRP wouldn't start for me with nomodeset alone).

As for the state of the project, it is now buildable, but still not complete.

Advanced users and devs willing to compile can sync the following manifest: https://github.com/zefie/android-x86_lineage_twrp_manifest

Trying to build will complain that "device/common/x86/bzImage" is missing, because I haven't implemented full kernel builds yet, just copy the "kernel" file from your install and put it in it's place (device/common/x86/bzImage)

The issue then is that I have not implemented a proper initrd.img patch or the ramdisk modules, so while you'll have a functional ramdisk-recovery.img with the current state of the git repo, it will not be bootable because:

1. The unmodified initrd.img does not know what to do with RECOVERY=1 or ramdisk-recovery.img
2. There are no kernel modules available

Devs or enthusiasts in dire need of recovery, or who want to help dev, could possibly boot it in its current state by backing up ramdisk.img and putting ramdisk-recovery.img in its place, but it will depend on the modules in /system/lib/modules.
Those wanting TWRP who arent devs should just wait a little longer. Sorry.

I'm trying to figure out the best way to do the client-side modifications shown in my video, within the build system.

On Saturday, January 20, 2018 at 7:25:22 AM UTC-5, lambdadroid wrote:

[zefie altimitmine]

I've decided to go with a TWRP-only (uninstallable) iso approach. Due to how unoften we will likely be booting TWRP, I don't see a problem with it being a seperate ISO.

Trying to merge it into the main system would require more trial and error testing and a longer build time, and the benefit isn't really worth it IMO.

Rather, instead, a generic external ISO that works with existing installs.

My next post will be some bootable alpha isos for x86 AND x86_64. Still working out some kinks.

More soon.

[Povilas Staniulis]

It would be pretty easy to permanently integrate your images to boot
process. It's just a matter of extracting the FS and Kernel/Initrd
somewhere (eg. an additional partition) and adding an extra entry to
grub. Not noobie friendly but doable.

In order to really integrate TWRP into the build process, we need your code.

> 1. The unmodified initrd.img does not know what to do with
> RECOVERY=1 or ramdisk-recovery.img
> 2. There are no kernel modules available

> <https://groups.google.com/group/android-x86>.

> > For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "Android-x86" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to android-x86...@googlegroups.com

> <mailto:android-x86...@googlegroups.com>.

> To post to this group, send email to andro...@googlegroups.com

> <mailto:andro...@googlegroups.com>.

[zefie altimitmine]

I've sorted the code issue and figured out how to make the build system do the client side tasks.

It is still not 100% ready but when I release the ISOs, the code will also be able to build the same ISOs.

In the meantime, if you want to browse around my current progress:

Repo manifest: https://github.com/zefie/android-x86_lineage_twrp_manifest
https://github.com/zefie/android-x86_installer (mucking with the initrd)

https://github.com/zefie/android-x86_device_generic_common (TWRP device config, now in common instead of just x86)

https://github.com/zefie/android-x86_platform_build (Modified to inject modules into recovery ramdisk)

https://github.com/zefie/android-x86_kernel_4.9 (the mmap patches are for xposed on nougat compatiblity, it also has my nwfermi patch, can use the original kernel, nothing special for TWRP)

https://github.com/zefie/android_bootable_recovery_x86target (The modified TWRP)

I'm still sorting out booting TWRP from ISO and detecting the installed Android-x86.

[youling 257]

i need flash systemless zip，what is systemless、system-ly？it not change only-read system.

systemless-ly  magisk，magisk xposed，systemless supersu，not change only-read system.

what is the Best only-read system，it is sfs.

i used lineage os 32bit system.sfs with systemless  supersu，magisk 14 systemless-ly.

if there a Best way to flash zip，flash magisk modules.

在 2018年1月21日星期日 UTC+8上午6:31:28，zefie altimitmine写道：

[zefie altimitmine]

It might work with system.sfs, we are checking to see if the mount point is read write, not specifically system itself.

Its not going to work on liveCDs, but a HDD install or USB install with system.sfs should work, but is untested.

[Mauro Rossi]

Hi,

Could TWRP be used as an alternative way to install android-x86?
Mauro

[zefie altimitmine]

Not in its current state, no, as it looks for an existing system directory or file.

The last thing I'm having trouble with is loading the drm drivers. If any devs wanna take a look at my code and see why all drivers except graphics seem to autoload.

I'm testing on a system with radeon, i see its in /system/etc/modprobe.blacklist, but im sure the system/core is trying to load from /system/lib/modules instead of /system/lib, so I need to figure out how to properly process "deferred" modules. The current code does not work, but if you build the ISO and boot into DEBUG and manually load your drm driver it will work.

Taking a break for now.

[zefie altimitmine]

Sorry, from /lib. We want to load modules from /lib/modules and not /system/lib/modules

Been a long day of failure.

[Jon West]

Instead of using ramdisk for it, it seems as though you might be able to incorporate most of your changes for recovery much like Android-IA does for their vendor.sfs file. take a look here: https://github.com/android-ia/bootable-live-installer/blob/master/Android.mk

[zefie altimitmine]

I tried putting module in sfs before, it broke my touchscreen. So at least some modules expect the modules directory to be writable, which the ramdisk can do. That's not really the problem though.

--
You received this message because you are subscribed to a topic in the Google Groups "Android-x86" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/android-x86/TZlAFbjavKg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to android-x86...@googlegroups.com.

To post to this group, send email to andro...@googlegroups.com.

[zefie altimitmine]

Sorry, was mobile, to elaborate, before announcing this project one of the things I tried was creating a "recovery-modules.sfs" containing "modules" and "firmware", and mounting it on /lib. It would load everything but my touchscreen would not appear. In normal operation, "modprobe nw_fermi" will load the module and create a /dev/nwfermi0 device. When using the sfs, it loaded, but never created the /dev/nwfermi0 device. Placing the modules in the ramdisk as the same location worked fine, so I assume r/w is needed for at least some modules, since nothing else was different.

It really doesn't matter because

1. Both the ramdisk and squashfs are gzip compressed, so while doing it in ramdisk does require some extra ram (about 128mb more), if the client has less than 256mb ram they are likely going to have more issues with Android-x86 than just my edits.
2. The modules would be in /lib either way, which is the problem.

Android-x86 (and android in general) is designed to look for modules in /system/lib/modules, but since we are going to be an independent bootable disk, chances are our kernel is not compatible with the modules installed in the user's install. Therefore we need to provide and load our own modules. Manipulating the system to put them back in /system/lib/modules, even via symlink, is off limits as we do NOT want to modify (in any way, even temporarly) the user's /system folder, as this will create headaches with backups.

The TWRP boot MUST be modified to only load from /lib/modules and not /system/lib/modules.

[zefie altimitmine]

I believe I have addressed most issue and can now release an alpha "it works for me" ISO.

Known issues:

1. Touch may require double tap, or not work at all. Mouse should.
2. Manually installing TWRP and trying to boot anything other than TWRP from the modified initrd.img is untested.
3. x86_64 TWRP builds not provided, and are untested. x86 TWRP should work on x86_64 installs.
4. "USB Drives" are just sdb and sdc, so if you have multiple hard drives, they may show instead.
5. Cannot partition or format USB Drives, but can wipe them if they are already a known filesystem.
6. Will hang at boot if it cannot find an Android-x86 installed on a read/write medium.
7. Untested with system.sfs images, but may work.
8. Probably many other things

Build: https://github.com/zefie/android-x86_lineage_twrp_manifest
Binary: https://files.persona.cc/zefie/files/android-x86/TWRP_v3.1.1_android-x86_zefie_rel1.iso

Taking a break from the project, been working on it straight since I started it.

[Chih-Wei Huang]

First of all, thank you for sharing it.

2018-01-22 1:37 GMT+08:00 zefie altimitmine <rkuc...@gmail.com>:
> Sorry, was mobile, to elaborate, before announcing this project one of the
> things I tried was creating a "recovery-modules.sfs" containing "modules"
> and "firmware", and mounting it on /lib. It would load everything but my
> touchscreen would not appear. In normal operation, "modprobe nw_fermi" will
> load the module and create a /dev/nwfermi0 device. When using the sfs, it
> loaded, but never created the /dev/nwfermi0 device. Placing the modules in
> the ramdisk as the same location worked fine, so I assume r/w is needed for
> at least some modules, since nothing else was different.
>
> It really doesn't matter because
>
> Both the ramdisk and squashfs are gzip compressed, so while doing it in
> ramdisk does require some extra ram (about 128mb more), if the client has
> less than 256mb ram they are likely going to have more issues with
> Android-x86 than just my edits.
> The modules would be in /lib either way, which is the problem.
>
> Android-x86 (and android in general) is designed to look for modules in
> /system/lib/modules, but since we are going to be an independent bootable

Not exactly correct.

Currently Android-x86 uses two ways to load modules:

1. A script run by init in initrd.img
(ref: https://osdn.net/projects/android-x86/scm/git/bootable-newinstaller/blobs/oreo-x86/initrd/scripts/0-auto-detect
)
2. The ueventd daemon (by listerning kernel uevents)

Method 1 looks modules in /lib/modules
However, method 1 is considered deprecated.
It's only used in DEBUG mode now.
I'm still thinking a way to remove it completely.

Method 2 loads modules in /system/lib/modules.
But it's just a simple define
(see system/core/libcutils/probe_module.c)
This is not a big deal. You can just change it to /lib/modules.
(you should note we have a symlink /lib -> /system/lib)
So it's not "designed to" but just an arbitrary choice.

For Android in general (AOSP), it doesn't have any way
to auto load modules. AOSP only provides the
insmod command (in init.rc) which can load a module
in any path. (i.e., you need to specify a full path to insmod)

> disk, chances are our kernel is not compatible with the modules installed in
> the user's install. Therefore we need to provide and load our own modules.
> Manipulating the system to put them back in /system/lib/modules, even via
> symlink, is off limits as we do NOT want to modify (in any way, even
> temporarly) the user's /system folder, as this will create headaches with
> backups.
>
> The TWRP boot MUST be modified to only load from /lib/modules and not
> /system/lib/modules.

How do you load modules exactly?
Did you use the above method 1 or 2?
Or another method you wrote?

[zefie altimitmine]

The TWRP build with your auto detect worked except drm so I just made it so TWRP mode doesn't exclude drm_kms like default. There are a few modifications I made to the initrd. All the current code in the iso I released is on my git with the links in a previous post.

[Chih-Wei Huang]

2018-01-22 10:55 GMT+08:00 zefie altimitmine <rkuc...@gmail.com>:
> The TWRP build with your auto detect worked except drm so I just made it so
> TWRP mode doesn't exclude drm_kms like default. There are a few
> modifications I made to the initrd. All the current code in the iso I
> released is on my git with the links in a previous post.

Yes. We exclude loading drm and sound modules
in the auto_detect script on purpose to workaround
some issues.
You won't encounter these issues in recovery mode
so you can just load them.


--
Chih-Wei
Android-x86 project
http://www.android-x86.org

[zefie altimitmine]

I've tried to make my modifications not break existing functionality in case you desire to more TWRP into future releases but I may have missed some stuff. After about 4 days straight working on it I needed as break but wanted to get as public build out. :)

[Pedro]

Thanx, very exciting project!

Maybe your posted ISO is not bootable?
I would like to try but im not able to boot this ISO.

Am Mittwoch, 17. Januar 2018 19:25:20 UTC+1 schrieb zefie altimitmine:

I am attempting to port TWRP to Android-x86. This in itself has a few challenges I have yet to address since most android devices use partitions and we use a single partition. That isn't the problem yet, I figured I'd address that once I got the GUI to boot, which IS my problem.

Things I've done so far:

• Hybrid sources from omni and android-x86
• Get build system to compile
• Modify android-x86 initrd to load recovery if RECOVERY=1 passed via kernel cmdline
  
• Modify android-x86 initrd's script to "detect android-x86" only on a writable partition if booting recovery (idea is to allow you to use TWRP from an ISO to modify an installed copy in case its foobar'd)
• No dependency on an existing or working system folder (modules/firmware in ramdisk)

But, I cannot actually load the GUI. It gets to stage "Loading page splash" then just dies with error 11 (segfault). The only info I have is that its "Loading page splash" as thats the last thing in recovery.log

I assume the problem is with minui and how android-x86 does graphics, and was hoping someone could give me a little more information on how exactly android-x86 does its graphics, and if I am missing a custom init.rc daemon to do so.

Once complete, while my TWRP is designed for my HP TouchSmart 300 nwfermi build, should be compatible with most Android x86 instances.

Anyone interested?

[zefie altimitmine]

There was a bug in my ISO building script, so the boot command got botched. Use grub to edit the boot command, and delete the last variable with "REC" in it and replace it with RECOVERY_ISOBOOT=1

The "VER" got replaced with the date when it should not have.

--

[Genx]

Have you look into Phoenix-OS Initrd.img ,it's able to use graphics and update the os with updater-script.i have seen traces of twrp in its initrd.img.

[youling 257]

i only see twrp folder image and xml files in Phoenix os initrd.img.

but its init script，

check_ota()

{

 remount_rw

 #debug_shell debug-found

 if [ -e "data/media/0/autoupdater/otapackage.zip" ]; then

  #load module

  auto_detect

  x86update 2>&1 > /dev/null

 fi

compare with remix os check ota，https://github.com/JideTechnology/remixos-bootable-newinstaller/blob/jide_x86_marshmallow/initrd/scripts/5-remixos

在 2018年4月11日星期三 UTC+8下午4:49:14，Genx写道：

[youling 257]

x86-update binary Phoenixos

x86-update binary remixos，https://github.com/JideTechnology/remixos-bootable-newinstaller/blob/jide_x86_marshmallow/initrd/bin/x86update

在 2018年4月11日星期三 UTC+8下午4:49:14，Genx写道：

Have you look into Phoenix-OS Initrd.img ,it's able to use graphics and update the os with updater-script.i have seen traces of twrp in its initrd.img.

[Dan Sagen]

This is awesome stuff and I have been waiting for TWRP to appear for Android x86 for years. Is this a dead project or is it still being worked on?

[herman...@gmail.com]

Can anyone share for me iso android x86 rooted and have twrp?

[Hunter Breathat]

Sounds cool

--
You received this message because you are subscribed to the Google Groups "Android-x86" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.

[Noire Black]

As much as I think this is a cool project, I feel like an app would be perfectly adequate. Just something to "flash" recovery disks and a basic backup manager

[Joe Stranger]

I am interested in your android build for touchsmart. Do you have a link to an available iso. Thanks.

[zefie altimitmine]

Hi, this is an old abandoned project, but you are welcome to continue work on it. The github links I posted should still be up.
Any links I posted with "files.persona.cc", just replace "files.persona.cc" with "archive.midnightchannel.net".

also note mid-thread I announce that there is a glitch in the boot config of the iso.

[Huy Minh Bui]

Seems like the project is dead for a long time......
But I've found out some great projects as alternatives to TWRP, one maybe youling257's Magisk with ability to swap component like Mesa and grallocs using Magisk's module
The other project is from my friend AXON called Gearlock. It's a ncurses toolbox that have it's own package manager. But recently he added zip flashing ability and can use it as a recovery
It's a great tool for me.
https://groups.google.com/forum/m/#!searchin/android-x86/Gearlock/android-x86/5wZsT1F5ygM
https://supreme-gamers.com/resources/gearlock-custom-recovery-replacement-for-android-x86.40/

[İlhan Atahan]

😀
24 Haziran 2020 Çarşamba 20:40:56 UTC+3 tarihinde Huy Minh Bui yazdı: