I assume you are using 4.0
The hacks work as advertised: they are the same.
So you have probably messed something up.
I suggest you restore the original stubdom0-linux-rootfs from your
backup.
I do not suggest repeating the process over and over.
Make sure you understand what it is you are trying to do.
Then take it slowly, checking at each stage.
If you see any error messages, note them down and report them here.
yup 4.0.4.
Yes I likely messed something up.
I’m doing the process on fresh install to get it correct before I do it on my daily.
Is this process correct as documented here?: notes/InstallingAndroid.md at master · unman/notes · GitHub
My mind flees, maybe I skipped it and went right to the other users method. But if you tell me that process definitely works, I’ll try it again and report back.
Thank you.
@unman apologies for resurrecting this, but I’m going to try your method on a test system and try to get this working again. I’m now using btrfs instead of LVM, do I need to take this into account using your implementation or is this irrelevant? Thanks.
irrelevant
@unman I did the process again on a fresh install of Qubes OS on a test system. Inside the AndroidX86 Installer it says “There is no hard drive to edit partitions”. I also did auto detect. And I tried the advanced options such as “automatically install to hard drive”. None can find a drive.
I really took my time this time around. Before there was a possibility I missed that there is init_patch and patch_init, so I could’ve previously ran this command once thinking I am only dealing with one file. However this time I triple checked to make sure I inputted everything correctly.
The only error that I saw that differs from your instructions is at step 4. that says cp /usr/lib/xen/boot/stubdom-linux-rootfs stubdom-linux-rootfs.orig
I recieved cp: cannot create regular file ‘subdom-linux-rootfs.orig’ Permission denied. I did a sudo on that command and then did an ls to verify a .orig file now exists. Not sure how this could mess anything up other then having no backup.
Is there something that may be different about my Qubes install because of hardware?
I’m not really sure how to troubleshoot, so any ideas would be greatly appreciated!
Thank you.
Looking at unman’s patch, your qube must start with the name “react”
Otherwise restore the backed up stubdom, edit init_patch1, change “react” to what your qube name starts with, and try again.
To verify it’s using IDE, you can start a shell in the stubdomain and look at the qemu args to verify if=ide is present for the -drive options:
In dom0:
$ sudo xl console <a86qubename>-dm
(hit enter to activate shell prompt)
# busybox strings /proc/`busybox pidof qemu`/cmdline|grep -A1 ^-drive
( ctrl+] gets you out, don't type exit )
If it’s properly setup as IDE you shall see (if=ide):
-drive
if=ide,media=disk,file=/dev/xvda,id=disk0,format=host_device,cache=writeback,readonly=off
If not (the default), you’ll see (if=none):
-drive file=/dev/xvda,if=none,id=disk0,format=host_device,cache=writeback,readonly=offThank you! ‘react’ is likely the solution as I named my qube “reaction”. I’ll give it a try and report back.
If your qube was already named “reaction” that is fine because the only requirement in the patch was for the name to begin with react.
Drop into the <a86qube>-dm shell with xl console like explained above and run:
# grep react /init
That should indicate if the init script even got patched to include the logic checking for “react”.
Since I couldn’t figure out the command to restore the .orig stubdom backup I just reinstalled the OS and started fresh. If you could share how to restore from the .orig the might help in the future.
And I went through the entire unman process again but this time doing qvm-create “react” instead of reaction.
Upon booting, I still receive “No hard drive found”
I then did your sudo xl console for the android qube to see if=ide. Unfortunately it says if=none for id=disk0.
There are other drives listed, not sure if it’s relevant but I’ll write those outputs now just in case.
-drive file=/dev/xvda,if=none,id=disk0,format=host_device,cache=writeback,readonly=off
-drive file=/dev/xvdb,if=none,id=disk1,format=host_device,cache=writeback,readonly=off
-drive file=/dev/xvdc,if=none,id=disk0,format=host_device,cache=writeback,readonly=off
-drive if=ide, readonly=on,media=cdrom,id=ide-51840,file=/dev/xvdi,format=host_device
Also to double check, I am using this link and following the process without any variation: notes/InstallingAndroid.md at master · unman/notes · GitHub
This is the process everyone else is following correct? or am I using the incorrect guide?
Not sure how I could be messing this up at this point. Thanks for the help with any next steps I should try.
The problem is that you have not examined the scripts and
understood what they are doing.
The note refers to a directory - qemu_dmargs
The patch_init script looks for a file at /home/user/patch/init_patch
Do you see why this does not work for you?
Well before yesterday I didn’t know these files could be opened. Bare with me I was thrust into Qubes from Windows as a professional requirement. I never even used linux prior, except for some certain automated GUI tools required in my job. But very non-advanced, just login, use tool, export report. Send analysis via windows.
But now that you mentioned, opening the patch_init script in a text editor, I’m guessing this line:
sed -i "/IFS=\\$/ r /home/user/patch/init_patch" init
Means that it’s not working because I never copied init_patch file to /home/user/patch/init_patch
Now forgive me, is that supposed to be init_patch file in init_patch folder or is that init_patch in patch folder?
I guess since I don’t know I could save time and just copy init_patch in both directories and see what happens.
Also for enhancing your situational awareness with dealing with noobs such as myself coming from windows, I just assumed when running ‘sudo ./patch_init’ I saw a bunch of stuff flash across the screen I didn’t understand. I just assumed it was doing everything that needs to be done.
I’m no expert but I’m thinking it might also be possible to write this script to move init_patch to the correct location without needing me to copy paste this myself preventing me from making such a silly novice mistake.
Or maybe I could edit your workflow to simple say name android qube “react” not “reaction” and “make sure you place init_patch in /home/user/patch/init_patch”.
I’ll try to make an account with github and do that if you think that would be a value increase for you and everyone else that may come along and make such a mistake. Or maybe I’m just an idiot and the only one who would make such a mistake. I don’t know.
Rest assured I’ll continue my studies in linux, hopefully one day I won’t make such novice mistakes.
I appreciate your time for supporting something you created but have no obligation to troubleshoot. I know we all have our own lives, and other concerns which limits our time. So again I appreciate the time you’re giving me when I know you don’t have to. May all the gods or forces outside our perception and control, which ever you prefer, find you blessed with good tidings! Skol my friend.
If you’re new to linux, I can understand the trouble and see where you’re coming from.
So let’s back up a little.
First, let’s understand the issue. When Android-x86 tells you it could not detect a hard drive, it is because of the way Qubes presents the hard drive to the virtual machine. Android-x86 is not built to recognize that “way”. The patching procedure that’s being discussed changes the way the hard drive is presented to the virtual machine. It does this by presenting it as an IDE interface. Android-x86 has no issues if the drive is seen over the IDE bus, and installation will proceed.
So what are we actually patching? When a qube is run in HVM mode, Qubes has to fake some hardware devices within the virtual machine, as using HVM mode implies the OS inside the VM expects that it is running on bare metal. In order to do this, an HVM qube is actually two virtual machines. One is hidden from the UI and called the stub domain, or device-model (-dm).
When an HVM qube is started, this stub domain VM is booted first (qubename-dm). This then runs qemu, which is responsible for “making the real VM look like a computer”. It creates the device model: PCI bus, SCSI bus, hard drives, display controller, and the like. Once the real qube (qubename without -dm) is booted, it’ll see “hardware” though it is really being emulated by the qemu software in the stub domain.
The intention is to modify the device model creation within the stub domain so that the hard drive looks like a true IDE drive. Note: domain is another word for virtual machine, which is the base of what we know as a “qube” in Qubes OS. We modify the device model creation by changing how the qemu application is executed. The qemu application is executed within the “init” script of the stub domain virtual machine. In linux-speak, “init” is the first process that is executed by the kernel at boot.
In dom0, the init script is contained within something like a zip file, that holds all other files that will exist in the stub domain. This is the root fs. The stub domain’s rootfs zip file is very small because it only runs qemu and hangs around for any hardware translation-related events.
So when your HVM qube “react” boots, dom0 extracts the stubdomain zip file, starts react-dm, which boots its own linux kernel, then runs the “init” script. “init” script then starts qemu with the fake hardware profile set up, then “react” (android-x86) boots. Any hardware-ish things “react” tries to do, Xen lets qemu within the stub domain, react-dm, handle it.
Therefore, the goal is to extract the stub domain root fs zip file, patch the “init” script, zip it back up, so that the device model will appear differently the next time an HVM qube is booted (and starts with the name “react” - a decision by unman).
That is the what and the why we’re doing what we’re doing. For the “how”, unman has provided notes that has worked for them, but it does take some linux scripting knowledge to put it all together. Since we’re working in dom0 territory, it would be prudent to understand the context and what changes are being made. While unman is definitely a trusted member of the Qubes team, someone can just as easily provide a guide that patches the “init” script or even qemu itself to be malicious, to the effect that every HVM qube (sys-net anyone?) siphons off data for malicious purposes.
In addition to unman’s notes, this post by qubesnewbie showed an approach that is similar: Android runs fine in qubes, no mouse issue, But - #19 by qubesnewb. In that post they are forcing IDE if the qube name ends with -ide.
What I would recommend if following unman’s notes or other guides is to simply analyze the patch_init script and run the commands manually.
If you happen to ruin the stubdom-rootfs file to the point where you have no idea what’s in it anymore and did not create a backup, no need to do a complete reinstall! You can get it back by reinstalling the xen-hvm-stubdom-linux package:
sudo qubes-dom0-update --action=reinstall xen-hvm-stubdom-linux
At the time of this post, with package version xen-hvm-stubdom-linux-1.0.10-1.fc25.x86_64 which has not changed since October 2018, the default /usr/lib/xen/boot/stubdom-linux-rootfs has a sha256sum of:
57f37b3f41dfbe006ca463fd60d5ed186368723eec94bbcc3aa79bb5f8871a36
Thank you sincerely for this lesson. Previously I’ve viewed the introductions over at xen on their site, but it’s very surface level. Thank you for giving me a better understanding of the internal workings.
Unfortunately this time around I’m still recieving the same “hard drive not detected”.
I deleted the react qube, and did your reinstall of stubdom. Thanks for that! Way faster then reinstalling the whole OS each time lol.
This time copying init_patch to /home/user/patch/ then running through Unman’s process again. When it didn’t work I though that maybe init_patch here needs to be made executable? But making it so, it didn’t change anything.
Each time I ran through the process I reinstalled stubdom and deleted and remade the react qube to try and make sure I’m following the process exactly with the same conditions.
The only error I think I could be making is maybe /home/user/patch/init_patch is supposed to be an empty directory and I shouldn’t have moved the file there? But if it was a directory only then wouldn’t the syntax be init_patch/ and not just “init_patch”? I’m just guessing at this point.
Other than that are we sure I’m not downloading the wrong version of change disk or something? I downloaded the zip from here: GitHub - unman/change_disk
And then extracted to the folders as mentioned in the guide for copying easily to Dom0.
I also ran your suggested ‘busybox strings /proc/busybox pidof qemu/cmdline|grep -A1 ^-drive’ command and it still shows if=none on disk0 
The only thing I’m noticing now is in the change disk directory there is a “reset”. Should I have used that before retrying Unman’s process? If so is that just a simple chmod +x reset then sudo ./reset?
I went through both the init_patch and patch_init files and I couldn’t tell if there was anther missing piece. But maybe I’m just not experienced enough to see.
I feel pretty silly at this point. I can’t imagine what else it could be I’m doing wrong.
Maybe it’s the android.iso? Or maybe el Diablo messing with me?
Thanks again.
I said all of the above without getting to the bottom line - the bottom line is that you need to verify that the init script gets patched before even trying to boot android-x86.
If you look at the script, which is here: change_disk/patch_init at master · unman/change_disk · GitHub
Line 12 is the sed command that says:
init file, which is part of the extracted stubdom-rootfs “zip” fileinit file that contains IFS=\\$, append the contents of file /home/user/patch/init_patch after the IFS=\\$ line.And the contents of init_patch, which is here: change_disk/init_patch at master · unman/change_disk · GitHub
This adds code (into init) that says:
react, do the IDE hack (inserting if=IDE into the dm_args variable).As I recommended, run the commands within patch_init manually. After running the sed command from line 12, check if the init file was patched by looking for the presence of react. If this yields no match, then stop right there and forget about even booting the qube.
If that doesn’t work, perhaps you need to indicate what you are doing, command by command. Note that unman’s scripts are notes, not a complete guide, and assumes some scripting knowledge. For example, the location of patch_init can be anywhere as long as you know how to change the script, just like the name of the qube can be any pattern, as long as you know how to change the script. But I am sticking to what is written to keep it simple.
So let’s verify that the /init file is being patched.
Okay so I was making quite a big assumption that what Unman shared was a guide, but more an example or notes and requires actually having to go through everything myself.
I’m fairly confident I’ve figured out the exact problem and where I need help specifically. A noob issue by not understanding a command and how to move files correctly.
So I ran through the patch_init commands manually. It made a temp directory, and if I understand unzipped the contents of stubdom in the temp directory to make the IDE edit.
So I proceeded all the way to line 12, and tried that command. Then in the temp directory I used nano on the init file and searched for if=IDE change. This change it did not find.
By you asking me to walk through this step by step, I figured out the problem. I think.
Because I never opened these files, I assumed that by placing “init_patch” file in the vm qubes1’s /home/user/patch/ folder, that following Unmans process and using his script that dom 0 would some how find where I placed init_patch.
Am I correct this is my error? That instead I need to place init_patch in dom0’s /home/user/patch or change the directory in the script?
And this is where I ran into trouble. I tried my best to make this directory in dom0, I tried to move the file which all says directory not found or file permissions issues even when I run sudo. Then I tried to do
sed -i "/IFS=\\$/ r qemu_dmargs/init_patch" init
And it says directory not found. Or when I could get the command to fire, I’d check init again and no changes.
I’m really having trouble with cd #, versus ~, /, etc. I don’t really know what I’m doing here.
So if I’m correct about this mistake, could you please tell me how to move the file in the right place or what edits I should make in running the "sed -i “/IFS=\$/ r” command to make this init edit finish, I think that would resolve the issue.
Ultimately I am learning a lot so I think although frustrating at moments, it’s a been a worthwhile challenge to get this working.
Going back again, I tried this again and finally got the command to fire without giving me any errors. But after looking within init file, there are still no changes inside. Even ran the command as sudo. Still no change.
Looking inside init_patch, couldn’t I just some how add these edits manually? Unfortunately I’m not sure where these edits match up in init. But the init file is maybe less than 300 words. Pretty small.
At this point is it possible something is incorrectly formatted in init_patch. Why does it fire and make no changes? 
From your description, it doesn’t appear you have your file paths correct. So either you’ve placed the files in the wrong location and/or your current directory that you’ve cd'd into isn’t appropriate for the command utilizing relative paths.
After step 3 from InstallingAndroid.md,
Verify init_patch and patch_init from the Github are unmodified, and located in dom0, inside directory /home/user/qemu_dmargs/
ls -l /home/user/qemu_dmargs
Enter the /home/user/qemu_dmargs directory in dom0
cd /home/user/qemu_dmargs
Open the init_patch file using nano init_patch, and change line 12, with the sed command, to change only this part:
/home/user/qemu_dmargs/init_patch instead of /home/user/patch/init_patch
Continue with step 4, skip step 5
You might want to take a look at a linux command line tutorial to become more familiar.
Here’s one: The Linux command line for beginners | Ubuntu
Lessons 4 and 5 are relevant to this topic.
Hi @anon93834559
I admire your attitude - I wish it was shared by more contributors.
I’m sorry that my notes have caused you so much trouble - but you seem to
have learnt a fair deal, and are still learning.
You can adjust the script to the notes, by editing the file patch_init
and changing the sed line from:
sed -i "/IFS=/r /home/user/patch/init_patch" init to:
sed -i "/IFS=/r /home/user/qemu_dmargs/init_patch" init
sed is a stream editor -
the -i means edit the file in place
init is the name of the file to edit
/IFS=/ matches the *line* to edit r` reads in a file - in this case the patch in /home/user/qemu_dmargs/init_patch
If you make that change, you will find that the script works correctly.
sed is a great tool. because it is an editor you can manually make the
changes yourself in any text editor.
If you need more help PM me.
Well good news is I got it working. However the solution is slightly embarrassing. I too thought just editing patch_init line 12 to /home/user/qemu_dmargs/init_patch would be the fix.
However I wasn’t realizing that dom 0 /user/ is my system username and that’s the folder name I should be using. I just ignored this because I’ve been used to every appvm I make always has /user/ as the username in terminal and also the user folder is just user.
But just going through everything step by step. And following this guide helped. I went back to lesosn 3 to better understand relative and absolute paths. And also the shortcuts for root and home. I’d see these often but never knew what they were. But doing pwd helped me realize, oh crap /user/ is not the folder in dom0 but my username. So thanks Icequbes1 for sharing that guide. It helped.
So while slightly embarrassing this simple mistake I kept making. Yes I did learn a lot! Now I know more about the xen backend in terms of stubdom, so I’m happy about that.
But I’m more happy that Android now works 
Thank you @unman, @icequbes1 and everyone for your patience and teaching me more about qubes.
I think I’ll try to do a noob’s guide to getting androidx86 working in 4.0.4 with some screenshots and stuff and mention the noobie mistakes one might make.
Thanks again 
Nothing embarrassing about having a problem and seeing it through.