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!