NVM I found my error…
and the dispvm loaded and xterm came up…
So when I type what you said… “Then in dispvm you can edit grub config in mounted image:”
nano /mnt/grub/menu.lst
I get…a blank nano file
file does not exist
This is PAINFULLLL…
Anyway,
following the link you sent…
next step…
[user@dom0]$ qvm-block attach disp7142 dom0:$dev
Then I do
[user@dispXXXX]$ mount /dev/xvdiX /mnt/
AND GET
mount: /mnt: must be superuser to use mount...
OK
[user@dispXXXX]$ sudo mount /dev/xvdiX /mnt/
I get
mount: /mnt: special device /dev/xvdiX does not exist...
SO where the hell did it go???
/dev/xvdiX is an example disk name and partition number X (1, 2, 3, whatever).
Find out the name of your connected root image volume and it’s partitions with these commands in dispvm:
sudo fdisk -l
sudo blkid
Most probably you need to use /dev/xvdi1 device name instead of /dev/xvdiX.
@disp6252,
cool as long as it’s still there and “dom0” didn’t deleted or destroy it as I do not see it anymore listed along with all my other (HVM’s, Templates, domains) . So where it went to IDK., maybe stuck somewhere.
I was speaking to one of my Android buddies and is is going to try this Android 15 iso in “virtual-box” and see what happens. you know that hole " blinking" underscore/ blinking cursor. He doesn’t run Qubes OS but does a ton of VM’s in virtual-box.
Anyway thank you very much for the lesson and look very forward to understanding and using my “Qube” to the fullest.
I will tomorrow as “princess #3” is on a blazing terror right now and the Queen said it’s my turn to tame that fire…
What was I thinking, yep 3 of them…
I will let you know, thanks
@disp6252 ok here we go…
First input:
@dom0 Desktop]$ sudo fdisk -l
I get everything AND it see’s my Android HVM but only thing I am getting is… DIsk /dev/mapper/qubes_dom0-vm
Second input:
@dom0 Desktop]$ sudo blkid
only thing I am getting is… /dev/sda1: UUID
and then back to /dev/mapper/qubes_dom0-vm and seeing everything even my Android HVM. But I don not see anything in reference too
/dev/xvdiX OR /dev/xvdi1
Also Android HVM is missing from my drop down where I can choice domains,templates or other HVMS.
Those 2 terminal cmds list a ton of stuff
So what now???
@disp6252
So I am rerunning this and here is where I am running in to a problem from following the link you sent…
3: Attach the device to your newly created disp VM
[user@dom0]$ qvm-block attach NEWLY_CREATED_DISPVM dom0:$dev
``` what terminal?? as my dispVM has launched now and dom0 terminal does not have a cursor anymore
So I launch another dom0 terminal and type this as I have now a dispVM launched...
qvm-block attach disp933 dom0: $dev
I get error
qvm-block: error: backend vm 'dom0' doesn't expose device ' '
So wtf!!!You need to run these commands in dispvm to which you’ve connected your Android root storage to find its device name in dispvm.
It seems you’ve run this command:
[user@dom0]$ qvm-run -v --dispvm=YOUR_DVM_TEMPLATE --service qubes.StartApp+xterm
Instead of this command:
[user@dom0]$ qvm-run -v --dispvm=YOUR_DVM_TEMPLATE --service qubes.StartApp+xterm &
Note the & at the end of a command that makes the command run in the background so it won’t block the terminal.
You need to run this command in new terminal to initialize $dev variable there:
[user@dom0]$ dev=$(basename $(readlink /dev/YOUR_LVM_VG/YOUR_LVM_IMAGE))
@disp6252
in the first terminal of dom0 i run these cmd’s
First input:
@dom0 Desktop] $ dev=$ (basename $(readlink /dev/qubes_dom0/vm-Android15-root))
Second input:
@dom0 Desktop] $ qubesdb-write /qubes-block-devices/$dev/desc Android15
Third input:
@dom0 Desktop] $ qvm-run -v --dispvm=fedora-37-dmv --services qubes.StartApp+xterm &
dom0 kicks back
@dom0 Desktop] $ Running ‘qubes.StartApp+xterm’ on $dispvm:fedora-37-dvm
I then have no more blinking cursor BUT dispvm6230 has started and I now have xterm up and waiting for input…
Now you are saying open another terminal in dom0 and retype this cmd…
[quote=“disp6252, post:19, topic:19357”]
[user@dom0]$ dev=$(basename $(readlink /dev/YOUR_LVM_VG/YOUR_LVM_IMAGE))
which is to me this…
@dom0 Desktop] $ dev=$ (basename $(readlink /dev/qubes_dom0/vm-Android15-root))
Why???
I have already enter that in first dom0 terminal
When following these direction on the link you sent puts me at (# 3)
Attachthe device to your newly created disp VM
It’s just a message from background process stdout printed in terminal. You can press Enter and you’ll see that terminal is not blocked by the process.
Because the variables that you defined in one terminal won’t be passed to other terminals.
Doesn’t
[user@dom0 ~]$ qvm-prefs -s your-vm kernelopts “nomodeset xforcevesa”
work?
@disp6252, I must be missing something here as in the second dom0 terminal I.
Input:
And nothing happens but dom0 returns waiting for next input…
Thank you for your time but I will just keep making the kernel edit I have to do as I am getting nowhere here and wasting time, but again thank you
You need to set this dev variable in new terminal if you want to run this command in new terminal next that will use this variable:
3: Attach the device to your newly created disp VM
From the GUI, or from the command line:
[user@dom0]$ qvm-block attach NEWLY_CREATED_DISPVM dom0:$dev
There is no meaning in just setting variable and do nothing with it next.
OK
@tempmail welll I tried it and it does not work…
If I remember right you can edit the kernel in termux, I know you can set ifconfig parameters.
Sorry to hear. I’m not good with android. I know I tried to edit props as root on the phone itself (with termux and many other tools) trying to set some usb parameter, but didn’t succeed and am genuinely interested in this.
I tried this Android in VB and had the same problem i was seeing in my Qube. I then did a “Bare mental” install and setups on my bench;while it launched fine with no issues the runtime environment would hang/lock up. Also network connection would just disappear for no known reason. I actually did 2 “bare metal” installs and it would just hang up. So I deleted from my qube and will just stick with my “ROOTED” tablets, which work flawlessly.
For what it’s worth to anyone.
I finally got this to work on “Bare Mental” install. After reading through many post and forums there are some “very” specific things you have to do when building the USB installer (with Rufus/etcher) as well as to the either SSD or NVME you plan to install too in your Bare metal machine. Also you still have to do the “nomodeset xforcevesa” BUT the option to edit the kernel only comes up once * it is a different screen and you have to hit (f10) to apply that edit and not hit enter adn let the installer run it’s course (this removes that "blinking cursor/underscore thing). You must keep this USB install attached while after the first reboot. Also you have to “reboot” a second time your bare metal install by forcing it down then you can remove your USB installer after it gets to the installation of the gpx drivers and you only see this happening by hitting “enter” and the screen will flash as the code rolls out.
After many attempts in trying to at lest get it to work on a virtual machine I couldn’t.
I went as far as opening up the iso and reviewing as much of the code as I could too see “wtf” i could edit/modify.
A few of the boys/girls were kind enough to email me back and explain things.
1.) Android is very picky on what hardware it will work on from a desktop/laptop computer environment being that desktop/laptop hardware architect is very different from tablet/phone. Many people are not forth coming on what hardware they have it working on or be very open end on explaining.
2.) “They” Android devs/comm really are gearing towards Bare Metal setups. While yes IT can work to some degree in a virtual environment it is not their aim and Android at best will be missing many features building into their codes as well as “do you really trust” that OS you are running your Android VM on??
That being said, yes my bare metal install/setup now is working and running great. I was just luck to have a old desktop sitting on my bench.
Will it work on my “qube” very doubtful as the setup and install requires
GPT, EFI access to the gpx & NIC card/driver(s).
Sorry to necro this but I’ve been away.
I dont think you are right about GPT and EFI - you can have a standard
Android install using stock grub menu in the qube. I do this on a Debian
minimal install to test different Android versions.
The only issue (but it is a major one) with Bliss is the failure of NIC
drivers - this is a relatively recent change . Otherwise everything
works as expected.
Thanks unman for the heads up!