Database Info

[Q] Install Linux on Kindle Fire?

I'v read some post on about install Linux distribution(Ubuntu, Arch Linux ARM, Gentoo) into a tablet pc, and I wonder if I can install Linux on Kindle Fire... I've no idea about this kind of thing, so if you think it's possible, I'll learn how to do it... Thank you in advance...

I Think if Kindle fire run on linux arm kernel you can. but you must porting Ubuntu's package to ARM and install this. But It is not so easy and can make problem to device

What about extending, not replacing, android linux?
Shouldn't it be possible to add commands to the Linux that underlies android to give it the functionality of at least some version of full Linux while keeping the android layer on top of it? I'm not a developer, so I don't know what all the technical problems might be, beyond the following:
Some kind of compiler is necessary, but isn't that also needed to create an android ROM anyway?
Code:
Since the KF doesn't accept an SD card, space might be a problem, but maybe a USB memory stick (flash drive), an OTG adapter, and perhaps some change to the bootloader to allow the KF to go into USB host mode might work. And the solution would probably be easier if the external memory were used for data and apps, but not for any part of the OS?
Perhaps this discussion belongs under Android Development, either specifically for the KF1 otter or more generally. Maybe there already are such discussions on xda or elsewhere. Guidance from developers and others in the know would be appreciated.

This sounds like a Decent idea. I actually want to try that now.

[Q] Android x86 efi boot

So I tried out Android x86 for my PC. It works beautifully. I cannot boot it on my Surface Pro though... It seems like the Surface Pro was designed to only boot EFI boot loaders. Not BIOS boot loaders... I was wondering if somebody could lend a hand at helping me get past this issue. I really think Android x86 would be great for the Surface Pro, there are so many things I miss from my Nexus 7 but I don't want an Android device, if I could just dual boot it every now and then, I would be happy. Can someone please get the Android 4.2 x86 ISOs to boot via EFI? That would be appreciated.

sionicion said:
So I tried out Android x86 for my PC. It works beautifully. I cannot boot it on my Surface Pro though... It seems like the Surface Pro was designed to only boot EFI boot loaders. Not BIOS boot loaders... I was wondering if somebody could lend a hand at helping me get past this issue. I really think Android x86 would be great for the Surface Pro, there are so many things I miss from my Nexus 7 but I don't want an Android device, if I could just dual boot it every now and then, I would be happy. Can someone please get the Android 4.2 x86 ISOs to boot via EFI? That would be appreciated.
Click to expand...
Click to collapse
hmmm ... interesting you tried ...
and came out with a finding ...
following this thread on the possible development on this front ...
I've always dreamt of a Surface Pro on Android always ...
a reboot to Win7 for Work ... and back to Android !!!
going to be really very interesting ...
Hope the Android X86 team is peaking at this thread ...
Cheers!

Did you bother disabling secure boot?
Otherwise you can try "jar of beans" or "bluestacks" to run android applications for windows. There is a version of bluestacks which claims to be optimised for the surface pro, in reality its just bluestacks with proper windows 8 touch support.

SixSixSevenSeven said:
Did you bother disabling secure boot?
Otherwise you can try "jar of beans" or "bluestacks" to run android applications for windows. There is a version of bluestacks which claims to be optimised for the surface pro, in reality its just bluestacks with proper windows 8 touch support.
Click to expand...
Click to collapse
Of course I did, the problem is the Surface Pro's UEFI chip does not actually support booting BIOS-based bootloaders. It only boots EFI-based bootloaders like the Windows Boot Manager or Grub EFI, etc. Unless one was to emulate BIOS to boot Android, it needs a EFI bootloader to even boot it on the Surface Pro. Ubuntu boots fine on the Surface Pro, but it is booting from Grub EFI. I copied the Grub EFI file to my other flash drive, and Grub indeed boots. It is the trouble of getting Android x86 to boot because it isn't using a EFI-based bootloader.
Also, that wasn't the point. I want to run pure Android just for the experience of having Android right on my Surface so I don't miss having a Nexus 7. I tried it on my desktop PC and it runs beautifully, if only I could get it on my Surface...

Surface Pro comes with Windows 8 Pro and a CPU capable of second-level address translation. It is therefore capable of running Client Hyper-V, which is a hypervisor-based virtualization (rather than hosted VM) technology that allows you to run another OS in parallel with Windows. I believe it includes support for BIOS-based OSes. Perhaps you should try that?

GoodDayToDie said:
Surface Pro comes with Windows 8 Pro and a CPU capable of second-level address translation. It is therefore capable of running Client Hyper-V, which is a hypervisor-based virtualization (rather than hosted VM) technology that allows you to run another OS in parallel with Windows. I believe it includes support for BIOS-based OSes. Perhaps you should try that?
Click to expand...
Click to collapse
But what's the point in that? I don't want to virtualize. I want to run it natively... That's like saying hey use Bluestacks. I want Android running native on my Surface.
Anyway, guys I got it. Here it is.

First of all, running on a hypervisor is nothing like using Bluestacks. Android would then be running as "natively" as Windows at that point (Windows itself would also be running on the hypervisor), except that Windows would have first access to the display (Android would be able to use the graphics hardware nonetheless). When the virtual display was set to the Android machine, Android would be interacting with the input devices. As a plus side, you could switch back and forth rapidly...
That said, if you managed to get it working on bare metal, that's cool. Did you mean to include a link in your "Here it is "?

GoodDayToDie said:
First of all, running on a hypervisor is nothing like using Bluestacks. Android would then be running as "natively" as Windows at that point (Windows itself would also be running on the hypervisor), except that Windows would have first access to the display (Android would be able to use the graphics hardware nonetheless). When the virtual display was set to the Android machine, Android would be interacting with the input devices. As a plus side, you could switch back and forth rapidly...
That said, if you managed to get it working on bare metal, that's cool. Did you mean to include a link in your "Here it is "?
Click to expand...
Click to collapse
The tutorial is on the YouTube page. But the problem with the Hyper-V hypervisor is it uses that remote console. I only found it decent for running Windows with the guest drivers installed. Unless I'm just not executing it very well, Hyper-V isn't a good solution. Since VirtualBox is used much more in the Linux world, I would use that before using Hyper-V.
I'll investigate the virtual solutions though and let you know.

more recent linux kernel versions do support hyper-v, partly provided by microsoft believe it or not
I would assume that hyper-v support would carry over into android. Just a case of setting it up.

Worth trying. However, Android runs a somewhat customized kernel build that probably doesn't include a lot of the optional stuff such as the Hyper-V helpers. Of course, you could install the required kernel module for them...

SixSixSevenSeven said:
I would assume that hyper-v support would carry over into android. Just a case of setting it up.
Click to expand...
Click to collapse
I somewhat doubt the android platform itself has support for hyper-v.
Further, if you're looking to boot android directly would an android kernel and platform support booting via UEFI at all yet?
What partition would android be installed to? it likely wouldn't like being stuffed into an NTFS partition so you'd have to repartition the SSD and take some of the space from Windows, or boot android from an SDcard or USB memory stick.
EDIT: I see you did infact get it running, nice job, did you just use GRUB for a bootloader? did you have android run from the SSD or from elsewhere?
tbh if I had a surface pro I don't think i'd be installing android on it, slightly a waste.
by the way, a faster way of doing advanced reboot so you get the boot options is to hold shift and select the reboot option from the power menu.

So, after a short little flip around the web, I came across this
https://01.org/android-ia/downloads/2013/android-4.2.2r1-ia0
somehow.
I would love to have my Surface Pro dual-bootable between Android and Win8, but your tutorial has sort of overwhelmed me.
Are you using this code? Would it be better to?
Just wasn't sure where this development was going....

Purrsia said:
So, after a short little flip around the web, I came across this
https://01.org/android-ia/downloads/2013/android-4.2.2r1-ia0
somehow.
I would love to have my Surface Pro dual-bootable between Android and Win8, but your tutorial has sort of overwhelmed me.
Are you using this code? Would it be better to?
Just wasn't sure where this development was going....
Click to expand...
Click to collapse
You can try my guide in windows 8 development forums
Sent from my HTC One X+ using xda app-developers app
---------- Post added at 10:37 AM ---------- Previous post was at 10:36 AM ----------
feherneoh said:
Can't you add the lines which boot android-x86 into Ubuntu's GRUB? If it can be loaded, it could be used to load Android's kernel
Click to expand...
Click to collapse
Microsoft locked it, you can only use the stock bootloader for now
Sent from my HTC One X+ using xda app-developers app

rEFIit
Have you tried a rEFIit or rEFIitd? As the name subtly suggests, its a bootloader for EFI machines. I suggest having a look. I'm going to try this myself on a couple of machines tomorrow once I get to work. Good luck! Let me know how it turns out or if I lead someone down the right track!
rEFInd - An EFI boot manager utility: http://goo.gl/KRwzk
rEFIt: http://refit.sourceforge.net/
Agreed, Android on a Surface would be kick ass. Windows for work, Android for real life!

Hi Folks.....
Feeling a little nervous here seems I must have took a wrong turn somewhere to end up in the Microsoft Surface forum LOL.
Is anyone still wondering about this? I noticed the other day that the linux kernel 3.10 which is currently used by the android-x86 project has android efi drivers/patches which maybe what you require. I'd also have a poke around the Android-IA sources which is the official intel android open source project from what I recall there's more efiboot goodies in there.
As an extra bonus the 3.10 kernel also includes a patch for Binder which allows a 32bit userspace to function correctly with a 64bit PAE kernel which means "BIG RAM" so if you have more than 4 gig and a 64 bit processor you can get access to the full ram allocation, not quite the pure 64bit Android that I want but it'll do for now while I figure out the finer points of x86_64 assembly language.
If Anyone wants/needs a kernel rattling off with these options enabled just let me know and i'll well rattle one off!
Thanks

trevd said:
Hi Folks.....
...I noticed the other day that the linux kernel 3.10 which is currently used by the android-x86 project has android efi drivers/patches which maybe what you require. I'd also have a poke around the Android-IA sources which is the official intel android open source project from what I recall there's more efiboot goodies in there.
As an extra bonus the 3.10 kernel also includes a patch for Binder which allows a 32bit userspace to function correctly with a 64bit PAE kernel which means "BIG RAM" so if you have more than 4 gig and a 64 bit processor you can get access to the full ram allocation, not quite the pure 64bit Android that I want but it'll do for now while I figure out the finer points of x86_64 assembly language.
If Anyone wants/needs a kernel rattling off with these options enabled just let me know and i'll well rattle one off!
Thanks
Click to expand...
Click to collapse
If the offer still stands, I would be interested in this (..or even just a how-to).
I have a multiboot system with PCLinuxOS, Ubuntu, and Win8.1 running right now, and I can get the recent 4.4rc1 release from android x86 to boot if I switch to legacy bios and use legacy grub from PCLinuxOS or the android_x86 thumbdrive, but I cannot get it to boot from Ubuntu's EFI capable Grub2 (..d/t kernel panic). On my Acer m5-583p it works great in legacy mode (wifi, touchscreen, keyboard, etc), but I would like to be able to use an EFI bootloader so that I don't have to change to/from legacy/efi before selecting the OS at boot.
Thanks! :good:

Boot from SD card

Boot from SD card
This is a placeholder for some work I was doing on booting and alternate copy of Windows RT from SD card
by adding extra entries in the bcd store and a ‘copy’ of windows on the SD card
(or a reinstalled version of Windows RT installed onto the SD card)
Note it actually still boots from the system partition on the internal flash but tries to boot an alternate Windows installation from \windows on the SD card
However having problems getting it to find the SD card volume at boot time
Still working on that
and on how to use the recovery environment to install the OS onto SD card
Best to have a Class 10 SD card
But now moved on to dual booting Windows RT and RT 8.1 (both from internal flash)
http://forum.xda-developers.com/showthread.php?p=43062190#post43062190
Also working on booting a full OS from USB stick

That'd be quite cool. It'd also be an important part of a Linux or Android port to Surface RT. You could make an extremely-stripped-down Windows RT installation that boots just enough to run some exploit automatically. The exploit could load a kernel driver to do the equivalent of kexec() into Linux.
Such an installation on a USB stick could be a bootable Linux live "CD" as well.

Myriachan said:
That'd be quite cool. It'd also be an important part of a Linux or Android port to Surface RT. You could make an extremely-stripped-down Windows RT installation that boots just enough to run some exploit automatically. The exploit could load a kernel driver to do the equivalent of kexec() into Linux.
Such an installation on a USB stick could be a bootable Linux live "CD" as well.
Click to expand...
Click to collapse
Someone just needs to actually come up with that exploit first. I'd totally convert my surface to a Linux device if it was available ... Windows is nice and all, but I love that warm, fuzzy feeling of having full control of hardware I own. I got CyanogenMod on just about every Android device I have, and getting out of the restricted RT arena would be awesome.

southbird said:
Someone just needs to actually come up with that exploit first. I'd totally convert my surface to a Linux device if it was available ... Windows is nice and all, but I love that warm, fuzzy feeling of having full control of hardware I own. I got CyanogenMod on just about every Android device I have, and getting out of the restricted RT arena would be awesome.
Click to expand...
Click to collapse
The general idea behind netham45's exploit (which originates with a Google guy) would actually work for this. If you control the entire boot image, you can make cmd.exe start a script and cdb very early. There exists a modification to the technique to do the exploit without the two-minute instability problem.
If Microsoft doesn't lock out the 8.0 bootarm.efi, this would keep working after 8.1's release--just boot 8.0 to do this part.
The difficult part of this entire thing to me is how the hell to write Linux drivers for hardware we know nothing about.

Myriachan said:
The general idea behind netham45's exploit (which originates with a Google guy) would actually work for this. If you control the entire boot image, you can make cmd.exe start a script and cdb very early. There exists a modification to the technique to do the exploit without the two-minute instability problem.
If Microsoft doesn't lock out the 8.0 bootarm.efi, this would keep working after 8.1's release--just boot 8.0 to do this part.
The difficult part of this entire thing to me is how the hell to write Linux drivers for hardware we know nothing about.
Click to expand...
Click to collapse
Linux for tegra might be a start, think that is now upto tegra 3 specs. But there are still several unknowns like you say. Some disassembly might clear up a few more unknowns (is the screen DSI or LDVS, which interface is used for the storage as there is more than one which would be capable for eMMc usage).
We do know that all the sensors are i2c devices at least.
But yeah, there is alot of work for a community to do in order to port linux to the surface. Not unless microsoft release a few datasheets which they have no reason to. Making matters worse, not all RT devices would be the same so the surface RT would need a different port than dells qualcomm based tablet. Even the tegra based tablets might need a different BSP to each other.
I do think though that if there was linux on the surface RT then I would probably consider getting one. Would at least double the chances at any rate.

SixSixSevenSeven said:
Linux for tegra might be a start, think that is now upto tegra 3 specs. But there are still several unknowns like you say. Some disassembly might clear up a few more unknowns (is the screen DSI or LDVS, which interface is used for the storage as there is more than one which would be capable for eMMc usage).
We do know that all the sensors are i2c devices at least.
But yeah, there is alot of work for a community to do in order to port linux to the surface. Not unless microsoft release a few datasheets which they have no reason to. Making matters worse, not all RT devices would be the same so the surface RT would need a different port than dells qualcomm based tablet. Even the tegra based tablets might need a different BSP to each other.
I do think though that if there was linux on the surface RT then I would probably consider getting one. Would at least double the chances at any rate.
Click to expand...
Click to collapse
I'd imagine focusing on one at a time would keep you from getting overwhelmed, and I would think the stock Microsoft Surface RT is the one that makes the most sense to start with, at least get a proof of concept working. As far as "hardware we know nothing about", the Tegra itself is pretty well documented and I imagine it operates essentially the same as it does anywhere else.
I would imagine stages to doing this:
1) Figure out the exact sequence to stop Windows and disengage the kernel, watchdogs, or whatever else in a stable way to start executing arbitrary code in RAM, with some kind of POC demo, e.g. getting data out over I2C or something, which we ultimately will need to debug a kernel.
2) Once this has been accomplished, start playing with ARM-based Linux bootloaders, with console output happening over I2C or whatever else works. This can allow for just trying to get the kernel to run, even if at first this renders a completely non-interactive device.
3) If you get this far, obviously now it's all about getting the magic mix of drivers...
With an actual kernel running, most likely a lot of hardware would become more easily identifiable, and we could at least figure out where we stand. Of all these things, I imagine #1 is the most difficult to overcome, but there's been some suggestions.

southbird said:
2) Once this has been accomplished, start playing with ARM-based Linux bootloaders, with console output happening over I2C or whatever else works. This can allow for just trying to get the kernel to run, even if at first this renders a completely non-interactive device..
Click to expand...
Click to collapse
I dont think anyone knows the exact pinout but there is i2c on the connector for the touch/type covers, they are themselves i2c devices. If someone knew the pinout, theres your access. Stick some magnets on some card with a few pieces of wire sticking out of it, should be able to hold against the connector. But that doesnt matter so much.
I've heard of linux consoles being accessed over UART (infact I have done this with a raspberry pi) but not i2c. The tegra does have at least 1 UART though (I have a feeling it might have 3 or 4). Whehter you would have to tear a surface apart to get at it though is another matter. I know that several devices actually make the uart externally accessibly via either the USB or audio jacks with a quick pinmux. A nexus 4 for example you stick a certain resistor between the mic and ground channels on its audio jack and I think the left audio channel becomes Tx and right Rx or vice versa. A few android tablets (I think HTC are big on this) use the microUSB, certain resistor value between the sensor and ground lines as is often used for enabling USB host triggers D+ and D- to become Tx and Rx instead. No microUSB on the surface though. My guess if they ran one externally it would either be on the cover connector (there are 5 connected contacts yet only worked out a purpose for 4 of them, then there is 1 pin not connected to anything for some reason, probably future expansion, perhaps this 5th pin enables a UART instead of i2c???) or the audio jack, there might well not be one accessible externally at all :/
I would assume the surface screen is either LDVS or DSI, the prior is more likely to be documented than the latter (DSI isnt even fully standardised, in theory it is but in practise DSI devices are rarely compatible even with the same res, colour depth etc). May well be possible to output direct to that initially.
With the keyboard being i2c it may well be possible to write a driver to use it on linux on an existing device, not sure how well USB-i2c adaptors work but the pi has 2 native i2c buses.
I do agree that the surface is the logical starting point. Its probably sold the most units at any rate and is the first thing people think of when you say windows RT. Other tegra devices would be the most logical to follow on with, qualcomm would perhaps be able to reuse step 1 but step 2 you would likely have to start from scratch all over :/
Oh well, 1 hurdle at a time. Honestly though, the existance of a functioning linux port for the surface would make me tempted to buy one. That or microsoft unlocking RT to literally be windows 8 on ARM not windows 8 stuck in a cage.

southbird said:
1) Figure out the exact sequence to stop Windows and disengage the kernel, watchdogs, or whatever else in a stable way to start executing arbitrary code in RAM, with some kind of POC demo, e.g. getting data out over I2C or something, which we ultimately will need to debug a kernel.
Click to expand...
Click to collapse
There is already a method of running any unsigned EFI file (for example a GRUB loader). But it works only on Asus tablets and requires USB stick inserted on boot and Bitlocker turned off in Windows (as the "trusted boot environment" is broken). I'll publish it later - probably after 8.1 official release, as it can be easily closed by Asus in a next firmware update that may be required for 8.1.

[Q] re:custom os on x86 android tablet?

I have searched lots on the subject of getting a full linux distro running on an android device most of which were really not really what I am looking for, almost everything I find on the subject seems to be some kind of hybrid solution where running linux side by side or on top of android but imo that just seems messy and may as well just be using andorid with it's apps than do that.
I ran into interesting information about modding chromebooks some of when were the similar side-by-side solution but others actually more what I was looking for, they enable legacy seabios while not enough to get windows installed seems to work fine to boot into linux and another guy had baked his own custom seabios replacing the chrome bios entirely.
my question, the atom tablets Im seeing pop up a few places are standard x86 right ? is it possible to either
1/run a modded sea bios similar to chromebook mods? then boot a stock ubuntu distro installation maybe from external storage?
2/or somehow have the existing/modded bootloader boot linux kernel/ubuntu install ?
can't help think if it were that simple maybe someone would have done it already but also thinking the hardware (drivers) are supported by android so they should be supported by linux right ? and if it is standard x86 can't be too much a stretch right ?
I don't own an atom tablet but was thinking it may be desirable (and add more use) if I could get a full linux distro installed and be a lot more affordable than full fledged windows based tablet.
anyway thanks
ps:that captcha is harcore

They are kinda standard. But they are not following PC architecture. They are so called Intel MID (Mobile Internet Device). On such devices you may find neither EFI nor ACPI. They have so called SFI which is a complete disaster. But Intel Merrifield is more or less supported by upstream kernel and Yocto (thanks to Intel Edison platform). You may try to gather information about those devices (official name of SoC is Intel Atom Z34xx).

Progress but still not quite there with my Lenovo X1 Tablet

Good day all. Hope this messages finds you safe and well in these challenging times.
I'm hoping to find some help a goal I have to have a single tablet PC that serves as both my daily driver PC running my OS of choice (Linux) and having the ability to dual-boot into Android for things like media consumption, reading books, etc.
I was fortunate to be gifted a Lenovo X1 Tablet 3rd Gen PC from a family member, and I'm truly enjoying it from the perspective of the form factor (it's similar to probably a Microsoft Surface tablet). Spec's can be found here:
[https://www.lenovo.com/gb/en/tablet...es/ThinkPad-X1-Tablet-3rd-Gen/p/22TP2CP0113#)
But it's essentially an 8th Gen Core i7 with vPro, Intel 620UHD Graphics driving a 3:2 aspect ratio 3000x2000 native resolution touch screen with WACOM digitizer, 16GB RAM, 1TB NVMe SSD, etc.
I have tried just about every ISO that BlissOS offers (as well as other such as Android X86) and simply cannot get anywhere in the installation. Occasionally the boot process will get as far as displaying some of the boot sequence, and then he screen will go black and either have a flashing or solid cursor in the upper left corner. On the newer ISO's, I could get to the point where I can hear some audio. And in some cases, the screen will sort of flash lighter and then darker (like the backlight is getting brighter and then dimmer). But at no point did I ever see an Android desktop.
I tried to boot the ISO as a Qemu VM, and this does seem to work (as I can see the full boot sequence and get to a point where I'm looking at an Android desktop). Unfortunately, I'm not sure how to configure the VM for proper touch support. Ideally, I'd rather have Android running natively on the device.
I'm finding references to others who have tried this on the Lenovo X1 Tablets and had either moderate or no success. A no point could I find a guide or reference on what combination would allow BlissOS (or any Android X86 based solution) to boot and install on this hardware.
To anyone who could help me get BlissOS running and installed on this tablet, I'd be truly in your debt.
Thanks in advance.
---
Update:
After some more research and experimentation, I was successful in getting Bliss OS installed and running on the bare metal of my Lenovo X1 tablet 3rd gen. However, the install isn't ideal as I leveraged an install script from JAXPARROW on Github (https://github.com/jaxparrow07/Android-x86-Installer-Linux) to complete the install. While this allows me to install and boot BlossOS (and other Android X86 releases) on the tablet, it's installing into a folder of the existing Linux ext4 filesystem and using the existing grub to boot. Ideally, I'd want the Android install in its own partition and ultimately use something like Refind as the boot manager.
I've attached an image of the grub entry that the JAXPARROW scripted install creates. Unfortunately, I cannot figure out what his script is doing that allows me to boot and install Android X86 on this hardware that a native boot and install won't work (black screen with a non-blinking cursor).
If anyone has any thoughts or feedback, I'd be grateful. I'm excited by the prospect that at least now I know I can run Android X86 on this hardware. And BlissOS is an amazing desktop implementation of Android.
Hardware is 2018 edition of the Lenovo Thinkpad X1 Tablet 3rd Generation:
ThinkPad X1 Tablet Gen 3 | 2-in-1 Laptop Tablet
The ThinkPad X1 Tablet Gen 3 delivers the best 2-in-1 tablet performance with a large 13" screen, detachable keyboard, and premium security features for work.
www.lenovo.com
Graphics are Intel 620 HD
3:2 aspect ratio
3000x2000
Thanks in advance.
[Image of grub entry ](https://photos.app.goo.gl/ysssaikm54cyhMpF8)

Hi @tech101, I am interested in buying a used thinkpad x1 tablet 3rd gen and planned to dual android or chrome os with windows.
Have you been able to successfully make android work?
this link https://github.com/jaxparrow07/Android-x86-Installer-Linux does not exist anymore.

Hello, I'm the developer of the mentioned project. I'm glad to see you're able to boot after installing via the installer. The installer has been updated recently with bug fixes and other distro support ( comes as a single executable instead of an installer ).
@tech101 said:
While this allows me to install and boot BlossOS (and other Android X86 releases) on the tablet, it's installing into a folder of the existing Linux ext4 filesystem and using the existing grub to boot. Ideally, I'd want the Android install in its own partition and ultimately use something like Refind as the boot manager.
Click to expand...
Click to collapse
You can do that by mounting them beforehand via cli or by a FileManager and then choosing in the Installation Partition in the installer.
Mounting a partition e.g : In Dolphin, you can do that by right clicking a partition
​
Basic help such as finding your filesystem name ( sda5 etc.,. ) is available in the installer's help menu
Help menu ( Ctrl + H or Help > Help in the menu)
​
@tech101 said:
I've attached an image of the grub entry that the JAXPARROW scripted install creates. Unfortunately, I cannot figure out what his script is doing that allows me to boot and install Android X86 on this hardware that a native boot and install won't work (black screen with a non-blinking cursor).
Click to expand...
Click to collapse
If you take a look at the line which has linux in it. It loads the kernel. With some parameters, it's possible to boot the android.
Bash:
linux /{name}/kernel quiet root=/dev/ram0 androidboot.selinux=permissive SRC=/{osname}/ noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable no_stf_barrier mds=off intel_pstate=disable mitigations=off
As explained by @Night(SG) in this commit. We removed the unnecessary ( in most cases ) kernel parameters ( ig which used to help you boot in this case ).
You can test the latest release and let us know if you're able to boot. If not, I'll add an option to enable the extra parameters while installing.
yeahman45 said:
this link https://github.com/jaxparrow07/Android-x86-Installer-Linux does not exist anymore.
Click to expand...
Click to collapse
OP made a typo, here's the correct link :
https://github.com/jaxparrow07/Androidx86-Installer-Linux
( unnecessary "-" after Android caused this )
If you guys have any questions related to androidx86, ask us on our forum : AOPC ( formerly SupremeGamers )