Discussion:
TWRP port attempt & help
(too old to reply)
zefie altimitmine
2018-01-17 18:25:20 UTC
Permalink
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?
--
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 android-***@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
2018-01-17 18:27:40 UTC
Permalink
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)
--
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 android-***@googlegroups.com.
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.
Jon West
2018-01-17 21:18:36 UTC
Permalink
Let us know if you need any assistance or information
--
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 android-***@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
2018-01-17 22:37:49 UTC
Permalink
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.
Post by Jon West
Let us know if you need any assistance or information
--
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 android-***@googlegroups.com.
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.
Mauro Rossi
2018-01-17 22:43:41 UTC
Permalink
Il giorno mercoledì 17 gennaio 2018 19:25:20 UTC+1, zefie altimitmine ha
Post by 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.
- 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?
Post by zefie altimitmine
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

}
Post by zefie altimitmine
Once complete, while my TWRP is designed for my HP TouchSmart 300 nwfermi
build, should be compatible with most Android x86 instances.
Anyone interested?
--
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 android-***@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
2018-01-17 22:56:48 UTC
Permalink
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.
Post by Mauro Rossi
Il giorno mercoledì 17 gennaio 2018 19:25:20 UTC+1, zefie altimitmine ha
Post by 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.
- 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?
Post by zefie altimitmine
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
}
Post by zefie altimitmine
Once complete, while my TWRP is designed for my HP TouchSmart 300 nwfermi
build, should be compatible with most Android x86 instances.
Anyone interested?
--
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 android-***@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
2018-01-18 01:03:43 UTC
Permalink
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
Post by 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.
Post by Mauro Rossi
Il giorno mercoledì 17 gennaio 2018 19:25:20 UTC+1, zefie altimitmine ha
Post by 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.
- 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?
Post by zefie altimitmine
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
}
Post by zefie altimitmine
Once complete, while my TWRP is designed for my HP TouchSmart 300
nwfermi build, should be compatible with most Android x86 instances.
Anyone interested?
--
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 android-***@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
2018-01-18 02:52:09 UTC
Permalink
Progress so far (getting there!):


(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 :)
--
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 android-***@googlegroups.com.
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.
Jon West
2018-01-18 21:14:28 UTC
Permalink
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.
Post by zefie altimitmine
http://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 :)
--
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 android-***@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
2018-01-18 22:02:29 UTC
Permalink
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.
--
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 android-***@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
2018-01-19 00:09:25 UTC
Permalink
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.


Post by 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.
--
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 android-***@googlegroups.com.
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.
Jon West
2018-01-19 02:11:48 UTC
Permalink
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.
Post by 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.
http://youtu.be/EyB9GjOa2mE
Post by 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.
--
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 android-***@googlegroups.com.
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.
Lambdadroid
2018-01-20 12:25:05 UTC
Permalink
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).
Post by 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.
Post by 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.
http://youtu.be/EyB9GjOa2mE
Post by 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.
--
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
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit 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.
To post to this group, send email to android-***@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
2018-01-20 19:16:10 UTC
Permalink
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.
Post by 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).
Post by 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
Post by Jon West
in this on finding solutions for you here. You can spot them easily by
what
Post by Jon West
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.
On Thursday, January 18, 2018 at 7:09:25 PM UTC-5, zefie altimitmine
Post by 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
Post by Jon West
Post by zefie altimitmine
that its both 20min long and slightly aggressive. The aggression comes
from
Post by Jon West
Post by zefie altimitmine
it being the 5th time of me filming, as my phone was really being a
rebel to
Post by Jon West
Post by zefie altimitmine
me and cutting off the videos.
http://youtu.be/EyB9GjOa2mE
Post by zefie altimitmine
There are too many dirty hacks in both TWRP, the initrd, and the
recovery
Post by Jon West
Post by zefie altimitmine
Post by zefie altimitmine
ramdisk to properly make a git repo setup without even more effort
that is
Post by Jon West
Post by zefie altimitmine
Post by zefie altimitmine
worse that hacking this to work. I'm not sure how I'm going to
distribute
Post by Jon West
Post by zefie altimitmine
Post by zefie altimitmine
the source.
As for progress, I bypassed a few issues using uvesafb, disabling
cursor
Post by Jon West
Post by zefie altimitmine
Post by zefie altimitmine
blink, and setting the console to tty2. Touch requires double tapping
at the
Post by Jon West
Post by zefie altimitmine
Post by zefie altimitmine
moment but it's usable.
More soon.
--
You received this message because you are subscribed to the Google
Groups
Post by Jon West
"Android-x86" group.
To unsubscribe from this group and stop receiving emails from it, send
an
<javascript:>.
Post by Jon West
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit 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.
To post to this group, send email to android-***@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
2018-01-20 22:45:29 UTC
Permalink
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.
Post by 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).
Post by 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
Post by Jon West
in this on finding solutions for you here. You can spot them easily by
what
Post by Jon West
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.
On Thursday, January 18, 2018 at 7:09:25 PM UTC-5, zefie altimitmine
Post by 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
Post by Jon West
Post by zefie altimitmine
that its both 20min long and slightly aggressive. The aggression comes
from
Post by Jon West
Post by zefie altimitmine
it being the 5th time of me filming, as my phone was really being a
rebel to
Post by Jon West
Post by zefie altimitmine
me and cutting off the videos.
http://youtu.be/EyB9GjOa2mE
Post by zefie altimitmine
There are too many dirty hacks in both TWRP, the initrd, and the
recovery
Post by Jon West
Post by zefie altimitmine
Post by zefie altimitmine
ramdisk to properly make a git repo setup without even more effort
that is
Post by Jon West
Post by zefie altimitmine
Post by zefie altimitmine
worse that hacking this to work. I'm not sure how I'm going to
distribute
Post by Jon West
Post by zefie altimitmine
Post by zefie altimitmine
the source.
As for progress, I bypassed a few issues using uvesafb, disabling
cursor
Post by Jon West
Post by zefie altimitmine
Post by zefie altimitmine
blink, and setting the console to tty2. Touch requires double tapping
at the
Post by Jon West
Post by zefie altimitmine
Post by zefie altimitmine
moment but it's usable.
More soon.
--
You received this message because you are subscribed to the Google
Groups
Post by Jon West
"Android-x86" group.
To unsubscribe from this group and stop receiving emails from it, send
an
<javascript:>.
Post by Jon West
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit 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.
To post to this group, send email to android-***@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
2018-01-21 01:42:25 UTC
Permalink
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.
Post by 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
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.
Post by 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).
Post by 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
Post by Jon West
in this on finding solutions for you here. You can spot them easily by
what
Post by Jon West
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.
On Thursday, January 18, 2018 at 7:09:25 PM UTC-5, zefie altimitmine
Post by zefie altimitmine
I posted this video trying to explain the current status, progress,
and
Post by Jon West
Post by zefie altimitmine
what I meant about it being a dirty setup to release source to.
Apologies
Post by Jon West
Post by zefie altimitmine
that its both 20min long and slightly aggressive. The aggression comes
from
Post by Jon West
Post by zefie altimitmine
it being the 5th time of me filming, as my phone was really being a
rebel to
Post by Jon West
Post by zefie altimitmine
me and cutting off the videos.
http://youtu.be/EyB9GjOa2mE
Post by zefie altimitmine
There are too many dirty hacks in both TWRP, the initrd, and the
recovery
Post by Jon West
Post by zefie altimitmine
Post by zefie altimitmine
ramdisk to properly make a git repo setup without even more effort
that is
Post by Jon West
Post by zefie altimitmine
Post by zefie altimitmine
worse that hacking this to work. I'm not sure how I'm going to
distribute
Post by Jon West
Post by zefie altimitmine
Post by zefie altimitmine
the source.
As for progress, I bypassed a few issues using uvesafb, disabling
cursor
Post by Jon West
Post by zefie altimitmine
Post by zefie altimitmine
blink, and setting the console to tty2. Touch requires double tapping
at the
Post by Jon West
Post by zefie altimitmine
Post by zefie altimitmine
moment but it's usable.
More soon.
--
You received this message because you are subscribed to the Google
Groups
Post by Jon West
"Android-x86" group.
To unsubscribe from this group and stop receiving emails from it, send
an
Post by Jon West
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit 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.
To post to this group, send email to android-***@googlegroups.com.
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.
Povilas Staniulis
2018-01-21 01:54:10 UTC
Permalink
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.
Post by 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.
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
https://github.com/zefie/android-x86_lineage_twrp_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
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.
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
<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).
On Fri, Jan 19, 2018 at 3:11 AM, Jon West
Post by Jon West
No worries man :) We're here to help in whatever way we can.
There's an
Post by Jon West
experienced few here in these groups that would be more than
happy to assist
Post by Jon West
in this on finding solutions for you here. You can spot them
easily by what
Post by Jon West
help they provide on the threads. All of them are pretty
responsive to
Post by Jon West
private messages as well, so don't be afraid to reach out.
On Thursday, January 18, 2018 at 7:09:25 PM UTC-5, zefie
Post by zefie altimitmine
I posted this video trying to explain the current status,
progress, and
Post by Jon West
Post by zefie altimitmine
what I meant about it being a dirty setup to release source
to. Apologies
Post by Jon West
Post by zefie altimitmine
that its both 20min long and slightly aggressive. The
aggression comes from
Post by Jon West
Post by zefie altimitmine
it being the 5th time of me filming, as my phone was really
being a rebel to
Post by Jon West
Post by zefie altimitmine
me and cutting off the videos.
http://youtu.be/EyB9GjOa2mE
On Thursday, January 18, 2018 at 5:02:29 PM UTC-5, zefie
altimitmine
Post by Jon West
Post by zefie altimitmine
Post by zefie altimitmine
There are too many dirty hacks in both TWRP, the initrd,
and the recovery
Post by Jon West
Post by zefie altimitmine
Post by zefie altimitmine
ramdisk to properly make a git repo setup without even
more effort that is
Post by Jon West
Post by zefie altimitmine
Post by zefie altimitmine
worse that hacking this to work. I'm not sure how I'm
going to distribute
Post by Jon West
Post by zefie altimitmine
Post by zefie altimitmine
the source.
As for progress, I bypassed a few issues using uvesafb,
disabling cursor
Post by Jon West
Post by zefie altimitmine
Post by zefie altimitmine
blink, and setting the console to tty2. Touch requires
double tapping at the
Post by Jon West
Post by zefie altimitmine
Post by zefie altimitmine
moment but it's usable.
More soon.
--
You received this message because you are subscribed to the
Google Groups
Post by Jon West
"Android-x86" group.
To unsubscribe from this group and stop receiving emails
from it, send an
Post by Jon West
Visit this group at
https://groups.google.com/group/android-x86
<https://groups.google.com/group/android-x86>.
Post by Jon West
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
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit 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.
To post to this group, send email to android-***@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
2018-01-21 01:59:30 UTC
Permalink
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.
Post by 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.
Post by 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.
Post by zefie altimitmine
My next post will be some bootable alpha isos for x86 AND x86_64.
Still working out some kinks.
More soon.
--
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 android-***@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
2018-01-20 20:26:14 UTC
Permalink
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.
To post to this group, send email to android-***@googlegroups.com.
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.
Povilas Staniulis
2018-01-20 22:11:28 UTC
Permalink
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.
Post by 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.
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
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit 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.
To post to this group, send email to android-***@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
2018-01-20 22:31:28 UTC
Permalink
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.
Post by 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.
Post by 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.
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)
Post by zefie altimitmine
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.
To post to this group, send email to android-***@googlegroups.com.
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.
youling 257
2018-01-21 03:57:59 UTC
Permalink
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写道
Post by 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.
Post by 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.
Post by 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.
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)
Post by zefie altimitmine
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.
To post to this group, send email to android-***@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
2018-01-21 04:21:31 UTC
Permalink
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.
Post by 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.
--
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 android-***@googlegroups.com.
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.
Mauro Rossi
2018-01-21 07:34:56 UTC
Permalink
Hi,

Could TWRP be used as an alternative way to install android-x86?
Mauro
--
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 android-***@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
2018-01-21 07:55:04 UTC
Permalink
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.
Post by Mauro Rossi
Hi,
Could TWRP be used as an alternative way to install android-x86?
Mauro
--
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 android-***@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
2018-01-21 07:55:58 UTC
Permalink
Sorry, from /lib. We want to load modules from /lib/modules and not
/system/lib/modules

Been a long day of failure.
Post by 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.
Post by Mauro Rossi
Hi,
Could TWRP be used as an alternative way to install android-x86?
Mauro
--
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 android-***@googlegroups.com.
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.
Jon West
2018-01-21 16:13:45 UTC
Permalink
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
Post by zefie altimitmine
Sorry, from /lib. We want to load modules from /lib/modules and not
/system/lib/modules
Been a long day of failure.
Post by 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.
Post by Mauro Rossi
Hi,
Could TWRP be used as an alternative way to install android-x86?
Mauro
--
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 android-***@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
2018-01-21 16:48:18 UTC
Permalink
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.
Post by 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
https://github.com/android-ia/bootable-live-installer/blob/master/Android.mk
Post by zefie altimitmine
Sorry, from /lib. We want to load modules from /lib/modules and not
/system/lib/modules
Been a long day of failure.
Post by 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.
Post by Mauro Rossi
Hi,
Could TWRP be used as an alternative way to install android-x86?
Mauro
--
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
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit 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.
To post to this group, send email to android-***@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
2018-01-21 17:37:11 UTC
Permalink
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.
Post by 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 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 android-***@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
2018-01-22 00:36:13 UTC
Permalink
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.
--
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 android-***@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
2018-01-22 02:55:52 UTC
Permalink
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.
First of all, thank you for sharing it.
Post by zefie altimitmine
Sorry, was mobile, to elaborate, before announcing this project one of
the
Post by zefie altimitmine
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
Post by zefie altimitmine
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
Post by zefie altimitmine
the ramdisk as the same location worked fine, so I assume r/w is needed
for
Post by zefie altimitmine
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.
1. A script run by init in initrd.img
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)
Post by zefie altimitmine
disk, chances are our kernel is not compatible with the modules
installed in
Post by zefie altimitmine
the user's install. Therefore we need to provide and load our own
modules.
Post by zefie altimitmine
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?
--
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
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit 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.
To post to this group, send email to android-***@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
2018-01-22 04:23:55 UTC
Permalink
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. :)
Post by zefie altimitmine
The TWRP build with your auto detect worked except drm so I just made it
so
Post by zefie altimitmine
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
--
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
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit 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.
To post to this group, send email to android-***@googlegroups.com.
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.
Pedro
2018-03-05 23:33:52 UTC
Permalink
Thanx, very exciting project!

Maybe your posted ISO is not bootable?
I would like to try but im not able to boot this ISO.
Post by 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.
- 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?
--
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 android-***@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
2018-04-08 07:04:15 UTC
Permalink
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.
Post by 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.
Post by 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.
- 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?
--
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
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit 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.
To post to this group, send email to android-***@googlegroups.com.
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.
Genx
2018-04-11 08:49:14 UTC
Permalink
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.
--
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 android-***@googlegroups.com.
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.
youling 257
2018-04-11 08:59:36 UTC
Permalink
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写道
Post by 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.
--
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 android-***@googlegroups.com.
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.
youling 257
2018-04-11 09:06:32 UTC
Permalink
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写道
Post by 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.
--
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 android-***@googlegroups.com.
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.
Dan Sagen
2018-05-31 05:24:56 UTC
Permalink
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?
--
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 android-***@googlegroups.com.
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.
h***@gmail.com
2018-08-13 08:39:35 UTC
Permalink
Can anyone share for me iso android x86 rooted and have twrp?

On Wednesday, January 17, 2018 at 11:25:20 AM UTC-7, zefie altimitmine
Post by 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.
- 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?
--
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 android-***@googlegroups.com.
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.
Hunter Breathat
2018-08-13 08:49:49 UTC
Permalink
Sounds cool
Post by h***@gmail.com
Can anyone share for me iso android x86 rooted and have twrp?
On Wednesday, January 17, 2018 at 11:25:20 AM UTC-7, zefie altimitmine
Post by 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.
- 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?
--
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
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit 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.
To post to this group, send email to android-***@googlegroups.com.
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.
Noire Black
2018-09-11 08:52:26 UTC
Permalink
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
--
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 android-***@googlegroups.com.
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.
Continue reading on narkive:
Loading...