[qubes-users] Re: Install Android-x86 on HVM

2018-03-05 Thread msgheap
On Tuesday, March 6, 2018 at 12:40:13 PM UTC+7, Tim W wrote:
> On Thursday, March 1, 2018 at 11:17:25 AM UTC-5, msg...@gmail.com wrote:
> > On Thursday, March 1, 2018 at 7:50:44 PM UTC+7, Yuraeitha wrote:
> > > On Thursday, March 1, 2018 at 11:11:44 AM UTC+1, msg...@gmail.com wrote:
> > > > Hello,
> > > > 
> > > > I want to install Android-x86 on Qubes OS 4.0rc4 StandaloneVM (HVM), 
> > > > but the Android installer can't recognize the VM drives.
> > > > I can run the Android Live from the iso and it works.
> > > > I've tried to install Android-x86 7.1-rc1/6.0-rc3/4.4-rc5 but they 
> > > > can't recognize the VM drives.
> > > > Based on some messages from mailing list/github issues, it was possible 
> > > > to install Android-x86 on HVM in Qubes OS 3.2 (or pre 4.0rc4?) but I 
> > > > can't do it in Qubes 4.0rc4.
> > > > Maybe someone have some clues on how to make the Android-x86 installer 
> > > > recognize VM drives?
> > > 
> > > Could it be because of the kernel is loaded in a similar way to how it 
> > > for example prevents Windows to install? I'd guess any standalone shares 
> > > this issue in Qubes 4 and not just Windows. Linux or not, if it tries to 
> > > use its own kernel rather than the one provided by dom0, then it would 
> > > probably not work. 
> > > 
> > > This should disable the VM's kernel, though I never used it my self, try 
> > > adjust if the citation marks are different.
> > > qvm-prefs android-vm-name kernel ''
> > > 
> > > I can confirm from personal experience that Android remix was possible to 
> > > be installed during Qubes 3.2., though I didn't try on Qubes 4 yet. 
> > > Generally it should work though, you probably just need to bypass some 
> > > issues, like the kernel issue above, and perhaps you need to adjust the 
> > > virt_mode too qvm-prefs android-vm-name virt_mode. Try change it to HVM 
> > > if it isn't already. I'm not sure if the GUI VM Settings has been fixed 
> > > for the Virt_mode, otherwise just use the dom0 terminal with above 
> > > command to change it.
> > 
> > I've already set the kernel to '', virt_mode to HVM, disabled memory 
> > balancing and set memory to 4GB, it didn't help.
> > I've installed Windows 7/10 without any problems on this same Qubes OS 
> > 4.0rc4 but I can't install Android-x86 with the same config.
> 
> I do not think the mouse  behavior issue has ever been able to be addressed.  
> It is mentioned in most of the android attempt threads.  There have been 
> numerous requests for actual android auppprt but without fully functional 
> mouse behavior it prevents proper use function.  As far as I know it has been 
> an issue in ever successful install of android on qubes but I could be wrong.

Yes, I know about this issue, but with the changed vm mouse config from  to type='mouse' I can more or less work in the 
Android even with the mouse acceleration problem.
The main reason why I wanted to install Android in Qubes is to use telegram 
with secret chat so I don't really need the mouse that much.
Right now I can't install Android-x86/CM-x86 because android installer can't 
detect the xen drive.
Also the network is not working in Android-x86 Live (tried Android-x86 7/6/4.4 
and CM-x86 14.1).

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f012d073-fab4-4ab5-b89f-340642fa8082%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Install Android-x86 on HVM

2018-03-01 Thread msgheap
On Thursday, March 1, 2018 at 7:50:44 PM UTC+7, Yuraeitha wrote:
> On Thursday, March 1, 2018 at 11:11:44 AM UTC+1, msg...@gmail.com wrote:
> > Hello,
> > 
> > I want to install Android-x86 on Qubes OS 4.0rc4 StandaloneVM (HVM), but 
> > the Android installer can't recognize the VM drives.
> > I can run the Android Live from the iso and it works.
> > I've tried to install Android-x86 7.1-rc1/6.0-rc3/4.4-rc5 but they can't 
> > recognize the VM drives.
> > Based on some messages from mailing list/github issues, it was possible to 
> > install Android-x86 on HVM in Qubes OS 3.2 (or pre 4.0rc4?) but I can't do 
> > it in Qubes 4.0rc4.
> > Maybe someone have some clues on how to make the Android-x86 installer 
> > recognize VM drives?
> 
> Could it be because of the kernel is loaded in a similar way to how it for 
> example prevents Windows to install? I'd guess any standalone shares this 
> issue in Qubes 4 and not just Windows. Linux or not, if it tries to use its 
> own kernel rather than the one provided by dom0, then it would probably not 
> work. 
> 
> This should disable the VM's kernel, though I never used it my self, try 
> adjust if the citation marks are different.
> qvm-prefs android-vm-name kernel ''
> 
> I can confirm from personal experience that Android remix was possible to be 
> installed during Qubes 3.2., though I didn't try on Qubes 4 yet. Generally it 
> should work though, you probably just need to bypass some issues, like the 
> kernel issue above, and perhaps you need to adjust the virt_mode too 
> qvm-prefs android-vm-name virt_mode. Try change it to HVM if it isn't 
> already. I'm not sure if the GUI VM Settings has been fixed for the 
> Virt_mode, otherwise just use the dom0 terminal with above command to change 
> it.

I've already set the kernel to '', virt_mode to HVM, disabled memory balancing 
and set memory to 4GB, it didn't help.
I've installed Windows 7/10 without any problems on this same Qubes OS 4.0rc4 
but I can't install Android-x86 with the same config.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8c5d3463-ee5c-448d-b696-e841cf930589%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Install Android-x86 on HVM

2018-03-01 Thread msgheap
Hello,

I want to install Android-x86 on Qubes OS 4.0rc4 StandaloneVM (HVM), but the 
Android installer can't recognize the VM drives.
I can run the Android Live from the iso and it works.
I've tried to install Android-x86 7.1-rc1/6.0-rc3/4.4-rc5 but they can't 
recognize the VM drives.
Based on some messages from mailing list/github issues, it was possible to 
install Android-x86 on HVM in Qubes OS 3.2 (or pre 4.0rc4?) but I can't do it 
in Qubes 4.0rc4.
Maybe someone have some clues on how to make the Android-x86 installer 
recognize VM drives?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/84a4bcd5-833f-4dfa-8898-ac9e0d425a7c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Start VMs on boot before user login (Qubes OS 4.0rc4)

2018-02-20 Thread msgheap
On Tuesday, February 20, 2018 at 6:00:21 PM UTC+7, Yuraeitha wrote:
> On Tuesday, February 20, 2018 at 10:51:55 AM UTC+1, msg...@gmail.com wrote:
> > On Tuesday, February 20, 2018 at 2:49:30 PM UTC+7, Yuraeitha wrote:
> > > On Monday, February 19, 2018 at 3:37:39 PM UTC+1, msg...@gmail.com wrote:
> > > > On Monday, February 19, 2018 at 7:29:37 PM UTC+7, Yuraeitha wrote:
> > > > > On Monday, February 19, 2018 at 1:00:13 PM UTC+1, msg...@gmail.com 
> > > > > wrote:
> > > > > > On Sunday, February 18, 2018 at 4:10:56 PM UTC+7, msg...@gmail.com 
> > > > > > wrote:
> > > > > > > Hello,
> > > > > > > 
> > > > > > > Is it possible to start all VMs marked as "Start qube 
> > > > > > > automatically on boot" on Qubes OS boot and not on user login in 
> > > > > > > Qubes OS?
> > > > > > > Is it possible to do it without Qubes OS autologin?
> > > > > > > I want to have a working server application on VM on Qubes OS 
> > > > > > > boot without the need to login in Qubes OS.
> > > > > > 
> > > > > > I've enabled autologin and add "xscreensaver-command -lock" in the 
> > > > > > Startup Applications as temporary solution, but it's not perfect 
> > > > > > because the system is unlocked briefly before xscreensaver will be 
> > > > > > locked and it may be exploited.
> > > > > 
> > > > > I'm no expert, but in order to bypass a Qubes login, isn't this just 
> > > > > about changing the PID levels? If this is possible to do without 
> > > > > major change in the code, of course. The various processes are 
> > > > > ordered in levels, init the root of all levels being 1, and the 
> > > > > lowest possible firmware at init 0. While root as an account is 
> > > > > disabled by default in Qubes, there should be something akin to root, 
> > > > > in a way of "system" processes. So the system processes starts up 
> > > > > during boot, which includes all autostart VM's. Which you can see in 
> > > > > "sudo journalctl --boot" and adjust it to around the time you booted 
> > > > > it up, or a much simpler appoach which is to press the F1 key after 
> > > > > LUKS password, which will show you what happens during boot, up until 
> > > > > the Qubes login for user sessions. 
> > > > > 
> > > > > I believe the AppVM's must be partly starting up in the background, 
> > > > > but all the user aspects from the user account, did not. For example 
> > > > > XFCE4, widgets, notifications, etc. are not bound by system 
> > > > > processes, but are bount by the user account processes. 
> > > > > 
> > > > > If you can change all the processes related to a Qube AppVM, and all 
> > > > > the required processes, i.e. by changing them from user processes 
> > > > > type, to a system process type, then it may very well fully boot 
> > > > > before you type in your password.
> > > > > 
> > > > > However, you will have no LUKS password, since this cannot be 
> > > > > automated even if you use other systems. Essentially, your plan seems 
> > > > > like it will fall apart, no matter what you do with current 
> > > > > technology, no matter which Linux or system you pick, they are all 
> > > > > vulnurable to this issue. Or so it seems, after all, I'm no expert. 
> > > > > 
> > > > > Essentially, you can probably work around the last Qubes login, but 
> > > > > not the first disk encryption login. And even then, putting some of 
> > > > > Qubes processes from user to system, may be risky too.
> > > > > 
> > > > > I'm sorry, but if you look at it from an abstract point of view, no 
> > > > > matter how you flip this, it just seems outright impossible if 
> > > > > preserving security is your goal. Or did I miss something crucial?
> > > > 
> > > > Thank you for the suggestion to check the boot process log, the AppVMs 
> > > > really are starting up before user login. It seems that when I've 
> > > > tested this, the testing AppVM failed to load and I couldn't connect to 
> > > > it. I've tried to connect to the ssh service in AppVM, but failed to 
> > > > connect and when I've logged in the Qubes OS I've seen the VMs just 
> > > > starting to boot from the look of it.
> > > > The problem is solved.
> > > > 
> > > > Regarding the encryption, I'm thinking of using hardware-based full 
> > > > disk encryption with the feature to remote unlocking the drive to keep 
> > > > the encryption keys away from the Qubes OS hardware. This will avoid 
> > > > the threats like meltdown/spectre/IntelME/AMD PSP stealing the 
> > > > encryption keys.
> > > 
> > > @msg...@gmail.com
> > > oh interesting, I did not know it was possible to do remote hardware 
> > > decryption, I made the mistake expecting it had to be physically at the 
> > > server. This is one powerful ability that indeed changes everything. 
> > > Looks like it might work after all then, I'm glad its starting to work 
> > > out for you.
> > > 
> > > Apologize for the large post below, but I'd argue I have a solution for 
> > > you regarding the RAM issue, but it's a different way of thinking, that's 
> > 

[qubes-users] Re: Start VMs on boot before user login (Qubes OS 4.0rc4)

2018-02-20 Thread msgheap
On Tuesday, February 20, 2018 at 2:49:30 PM UTC+7, Yuraeitha wrote:
> On Monday, February 19, 2018 at 3:37:39 PM UTC+1, msg...@gmail.com wrote:
> > On Monday, February 19, 2018 at 7:29:37 PM UTC+7, Yuraeitha wrote:
> > > On Monday, February 19, 2018 at 1:00:13 PM UTC+1, msg...@gmail.com wrote:
> > > > On Sunday, February 18, 2018 at 4:10:56 PM UTC+7, msg...@gmail.com 
> > > > wrote:
> > > > > Hello,
> > > > > 
> > > > > Is it possible to start all VMs marked as "Start qube automatically 
> > > > > on boot" on Qubes OS boot and not on user login in Qubes OS?
> > > > > Is it possible to do it without Qubes OS autologin?
> > > > > I want to have a working server application on VM on Qubes OS boot 
> > > > > without the need to login in Qubes OS.
> > > > 
> > > > I've enabled autologin and add "xscreensaver-command -lock" in the 
> > > > Startup Applications as temporary solution, but it's not perfect 
> > > > because the system is unlocked briefly before xscreensaver will be 
> > > > locked and it may be exploited.
> > > 
> > > I'm no expert, but in order to bypass a Qubes login, isn't this just 
> > > about changing the PID levels? If this is possible to do without major 
> > > change in the code, of course. The various processes are ordered in 
> > > levels, init the root of all levels being 1, and the lowest possible 
> > > firmware at init 0. While root as an account is disabled by default in 
> > > Qubes, there should be something akin to root, in a way of "system" 
> > > processes. So the system processes starts up during boot, which includes 
> > > all autostart VM's. Which you can see in "sudo journalctl --boot" and 
> > > adjust it to around the time you booted it up, or a much simpler appoach 
> > > which is to press the F1 key after LUKS password, which will show you 
> > > what happens during boot, up until the Qubes login for user sessions. 
> > > 
> > > I believe the AppVM's must be partly starting up in the background, but 
> > > all the user aspects from the user account, did not. For example XFCE4, 
> > > widgets, notifications, etc. are not bound by system processes, but are 
> > > bount by the user account processes. 
> > > 
> > > If you can change all the processes related to a Qube AppVM, and all the 
> > > required processes, i.e. by changing them from user processes type, to a 
> > > system process type, then it may very well fully boot before you type in 
> > > your password.
> > > 
> > > However, you will have no LUKS password, since this cannot be automated 
> > > even if you use other systems. Essentially, your plan seems like it will 
> > > fall apart, no matter what you do with current technology, no matter 
> > > which Linux or system you pick, they are all vulnurable to this issue. Or 
> > > so it seems, after all, I'm no expert. 
> > > 
> > > Essentially, you can probably work around the last Qubes login, but not 
> > > the first disk encryption login. And even then, putting some of Qubes 
> > > processes from user to system, may be risky too.
> > > 
> > > I'm sorry, but if you look at it from an abstract point of view, no 
> > > matter how you flip this, it just seems outright impossible if preserving 
> > > security is your goal. Or did I miss something crucial?
> > 
> > Thank you for the suggestion to check the boot process log, the AppVMs 
> > really are starting up before user login. It seems that when I've tested 
> > this, the testing AppVM failed to load and I couldn't connect to it. I've 
> > tried to connect to the ssh service in AppVM, but failed to connect and 
> > when I've logged in the Qubes OS I've seen the VMs just starting to boot 
> > from the look of it.
> > The problem is solved.
> > 
> > Regarding the encryption, I'm thinking of using hardware-based full disk 
> > encryption with the feature to remote unlocking the drive to keep the 
> > encryption keys away from the Qubes OS hardware. This will avoid the 
> > threats like meltdown/spectre/IntelME/AMD PSP stealing the encryption keys.
> 
> @msg...@gmail.com
> oh interesting, I did not know it was possible to do remote hardware 
> decryption, I made the mistake expecting it had to be physically at the 
> server. This is one powerful ability that indeed changes everything. Looks 
> like it might work after all then, I'm glad its starting to work out for you.
> 
> Apologize for the large post below, but I'd argue I have a solution for you 
> regarding the RAM issue, but it's a different way of thinking, that's why it 
> needs to be compiling different pieces of logics together. There are ways you 
> can raise un-tapped potential for security here if you look for measures 
> outside the computer itself.
> 
> 
> 
> 
> First an established logic analogy that embodies everything below:
> The whole logic below can be summarized as an analogy of the difference 
> between ps/2 and USB. First establishing a logic here through an analogy 
> between USB/ps/2. USB is universal, advanced, and powerful, it can do a lot 

[qubes-users] Re: Start VMs on boot before user login (Qubes OS 4.0rc4)

2018-02-19 Thread msgheap
On Tuesday, February 20, 2018 at 7:04:00 AM UTC+7, Tim W wrote:
> Make sure there is no way to softboot\power cycle the box as with sed opal2 
> hw encrypt drives they will stay unlocked until either manual locked or power 
> loss state i.e. true power cycle.   I run  Samsu. 850pro  But still run luks 
> as a precaution to some tricks to softboot a locked powered on system.

I know about this problem, I want to use hardware-based encryption against 
unprepared/unskilled attackers, but if someone really want to get the keys, 
there'll allways be a way to do this when you have physical access to the 
hardware. For example, even if you use LUKS in addition to hardware encryption, 
the LUKS keys will be in the RAM and attacker can read them directly from RAM:
https://en.wikipedia.org/wiki/Cold_boot_attack

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/d8f87378-2530-4cd1-93ed-db735ad9dd00%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Start VMs on boot before user login (Qubes OS 4.0rc4)

2018-02-19 Thread msgheap
On Monday, February 19, 2018 at 7:29:37 PM UTC+7, Yuraeitha wrote:
> On Monday, February 19, 2018 at 1:00:13 PM UTC+1, msg...@gmail.com wrote:
> > On Sunday, February 18, 2018 at 4:10:56 PM UTC+7, msg...@gmail.com wrote:
> > > Hello,
> > > 
> > > Is it possible to start all VMs marked as "Start qube automatically on 
> > > boot" on Qubes OS boot and not on user login in Qubes OS?
> > > Is it possible to do it without Qubes OS autologin?
> > > I want to have a working server application on VM on Qubes OS boot 
> > > without the need to login in Qubes OS.
> > 
> > I've enabled autologin and add "xscreensaver-command -lock" in the Startup 
> > Applications as temporary solution, but it's not perfect because the system 
> > is unlocked briefly before xscreensaver will be locked and it may be 
> > exploited.
> 
> I'm no expert, but in order to bypass a Qubes login, isn't this just about 
> changing the PID levels? If this is possible to do without major change in 
> the code, of course. The various processes are ordered in levels, init the 
> root of all levels being 1, and the lowest possible firmware at init 0. While 
> root as an account is disabled by default in Qubes, there should be something 
> akin to root, in a way of "system" processes. So the system processes starts 
> up during boot, which includes all autostart VM's. Which you can see in "sudo 
> journalctl --boot" and adjust it to around the time you booted it up, or a 
> much simpler appoach which is to press the F1 key after LUKS password, which 
> will show you what happens during boot, up until the Qubes login for user 
> sessions. 
> 
> I believe the AppVM's must be partly starting up in the background, but all 
> the user aspects from the user account, did not. For example XFCE4, widgets, 
> notifications, etc. are not bound by system processes, but are bount by the 
> user account processes. 
> 
> If you can change all the processes related to a Qube AppVM, and all the 
> required processes, i.e. by changing them from user processes type, to a 
> system process type, then it may very well fully boot before you type in your 
> password.
> 
> However, you will have no LUKS password, since this cannot be automated even 
> if you use other systems. Essentially, your plan seems like it will fall 
> apart, no matter what you do with current technology, no matter which Linux 
> or system you pick, they are all vulnurable to this issue. Or so it seems, 
> after all, I'm no expert. 
> 
> Essentially, you can probably work around the last Qubes login, but not the 
> first disk encryption login. And even then, putting some of Qubes processes 
> from user to system, may be risky too.
> 
> I'm sorry, but if you look at it from an abstract point of view, no matter 
> how you flip this, it just seems outright impossible if preserving security 
> is your goal. Or did I miss something crucial?

Thank you for the suggestion to check the boot process log, the AppVMs really 
are starting up before user login. It seems that when I've tested this, the 
testing AppVM failed to load and I couldn't connect to it. I've tried to 
connect to the ssh service in AppVM, but failed to connect and when I've logged 
in the Qubes OS I've seen the VMs just starting to boot from the look of it.
The problem is solved.

Regarding the encryption, I'm thinking of using hardware-based full disk 
encryption with the feature to remote unlocking the drive to keep the 
encryption keys away from the Qubes OS hardware. This will avoid the threats 
like meltdown/spectre/IntelME/AMD PSP stealing the encryption keys.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/abaf104e-914a-4a7f-8d9a-a9284d2492c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Start VMs on boot before user login (Qubes OS 4.0rc4)

2018-02-19 Thread msgheap
On Sunday, February 18, 2018 at 4:10:56 PM UTC+7, msg...@gmail.com wrote:
> Hello,
> 
> Is it possible to start all VMs marked as "Start qube automatically on boot" 
> on Qubes OS boot and not on user login in Qubes OS?
> Is it possible to do it without Qubes OS autologin?
> I want to have a working server application on VM on Qubes OS boot without 
> the need to login in Qubes OS.

I've enabled autologin and add "xscreensaver-command -lock" in the Startup 
Applications as temporary solution, but it's not perfect because the system is 
unlocked briefly before xscreensaver will be locked and it may be exploited.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/429151ce-5167-47cd-8474-c4ea94dffa5c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Start VMs on boot before user login (Qubes OS 4.0rc4)

2018-02-18 Thread msgheap
Hello,

Is it possible to start all VMs marked as "Start qube automatically on boot" on 
Qubes OS boot and not on user login in Qubes OS?
Is it possible to do it without Qubes OS autologin?
I want to have a working server application on VM on Qubes OS boot without the 
need to login in Qubes OS.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/aac46c65-faa0-474e-9c8f-91dbfed35749%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Running Windows from Qubes VM ?

2018-01-13 Thread msgheap
On Saturday, January 13, 2018 at 2:49:45 PM UTC+7, ThierryIT wrote:
> Hi,
> Seems to work better even if I am still not able to boot my windows.
> With "fdisk" I can see that my bootable HDD is "sdc1".
> From Dom0, when doing a : qvm-start vm-test --hddisk /dev/sdc1, I do have a 
> popup from my Windows drive.
> 
> Booting from CDROM  error code failaure 2
> Booting from Hard drive, failed no bootable disk 
> 
> No bootable device ...
> 
> Ideas ?
> 
> 
> 
> Le vendredi 12 janvier 2018 17:43:56 UTC+2, awokd a écrit :
> > On Fri, January 12, 2018 2:53 pm, ThierryIT wrote:
> > > Hello,
> > >
> > >
> > > I am not able to use "qvm-start" because the HVM I have created is
> > > "Empty".
> > > Dom0 is able to see my Windows 7 hard drive:
> > > /dev/sdc2 /run/media/user/32E...CCB type fuseblk
> > >
> > >
> > > From Dom0 I am able to have access to all my Window 7 files.
> > >
> > >
> > > Any ideas ?
> > >
> > >
> > > Thx
> > >
> > >
> > > Le vendredi 12 janvier 2018 13:59:56 UTC+2, awokd a écrit :
> > >
> > >> On Fri, January 12, 2018 6:48 am, ThierryIT wrote:
> > >>
> > >>> Hello,
> > >>>
> > >>>
> > >>>
> > >>> I have a laptop with two internal Hard Drives.
> > >>> One HD with Windows 7 the second Hard Drive with Qubes on it.
> > >>> Is it possible to run Windows 7 from a VM's Qubes instead of building
> > >>> a Win dows's VM ?
> > >>>
> > >>
> > >> You might be able to create a Win 7 HVM inside Qubes, then use
> > >> qvm-start win7 --drive /dev/sdb5 (or wherever your Win7 bootable
> > >> partition is located) to start it. Never tried it though.
> > 
> > Can you provide the exact error message? Not sure why qvm-start would care
> > it's empty, it will still boot from a CDROM then too...

Maybe there is no bootloader on /dev/sdc1? Try to boot from livecd and fix 
bootloader.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2448c4dc-cc1a-4476-a952-d4fbab759e9e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Windows 10 guest support (in Qubes 4.x)?

2017-10-25 Thread msgheap
On Thursday, October 26, 2017 at 1:13:17 AM UTC+7, Ted Brenner wrote:
> On Wed, Oct 25, 2017 at 2:01 AM, '[799]' via qubes-users 
>  wrote:
> Hello Tine,
> 
> >> I would like to know if there are any plans for
> >> better Windows (10) support in the
> >> upcoming 4.X version? 
> 
> I have the same question regarding the future strategy for windows support:
> 
> - will we see Windows 10 support in Qubes 3.2?
> (Not relevant as Qubes 3.2 will become EOL)
> 
> - what about windows 7 and 10 support in Qubes 4.0?
> 
> With "supported" I mean that we'll have Qubes Tools available and maybe the 
> option to use seamless mode.
> 
> In the past I read about Windows Support for windows 8.1 which I think is not 
> relevant as most people run either Windows 7 or 10.
> Looking at my customers I have not a single customer who is running windows 
> 8.x (for a good reason).
> 
> To Qubes Dev's
> 
> I really think the Qubes Dev-Team should be honest and transparent about 
> Qubes Windows Support - maybe answering the question if they are working on 
> this at all, or if Windows on Qubes is more like another project which is out 
> of scope of the Qubes Dev Team as they are mainly focussing on the Qubes 
> (Core) OS themselves (which I would totally understand).
> 
> >> I really appreciate your work, but currently
> >> this is preventing me to use Qubes as the
> >> daily driver
> 
> As you said I need to run windows for my daily workflow and would really like 
> to do so in Qubes.
> I guess there are more users who work in Enterprise environments (as 
> non-developers) where windows is basically the default OS where lots of 
> applications are running.
> One example is that lots of my work is done on Outlook (Exchange 2016) and I 
> have not been able to get this done with Linux.
> 
> I think it would be good to know how many users are asking for windows on 
> Qubes and maybe raise some funding so that a capable developer can work on 
> this topic.
> 
> [799]
> 
> 
> 
> 
> 
> -- 
> 
> You received this message because you are subscribed to the Google Groups 
> "qubes-users" group.
> 
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to qubes-users...@googlegroups.com.
> 
> To post to this group, send email to qubes...@googlegroups.com.
> 
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/qubes-users/akE3h9OJmfmidm58UyS7FxK0sCUVtgRK__X6rHkfGjTeIQhvEp-ac2FROHm42zpJw5VLDDEeAj6PiXJP4-IBerWOnS46Pmzv_FbRadShsg0%3D%40protonmail.com.
> 
> For more options, visit https://groups.google.com/d/optout.
> 
> 
> I strongly suspect there isn't any work going on as I never see replies from 
> qubes dev on Windows questions, and there are a lot of them. Or at least it 
> is tabled for now till 4.0 is done. Perhaps it would be nice to open support 
> of the code to the community rather than having the Qubes team working on it 
> exclusively?
> 
> 
> -- 
> 
> Sent from my Desktop

https://github.com/QubesOS/qubes-issues/issues/1861#issuecomment-284584315

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/3ee683a8-4ddb-4d91-8f89-96434cafc83b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Connect to the AppVM with VNC using Xen capabilities

2017-10-17 Thread msgheap
On Monday, October 16, 2017 at 8:52:14 AM UTC-4, msg...@gmail.com wrote:
> воскресенье, 15 октября 2017 г., 1:46:40 UTC-4 пользователь msg...@gmail.com 
> написал:
> > Hello.
> > 
> > I want to connect to one of my AppVMs with VNC from remote host using Xen 
> > capabilities.
> > I wanted to do it with the custom Xen config, but I can't figure out how to 
> > change the default Xen config or use custom Xen config to start my AppVM. I 
> > think it was possible in Qubes OS 3.2 with "qvm-start 
> > –custom-config=CUSTOM_CONFIG", but I've installed Qubes OS 4.0 
> > (current-testing) and there is no such option now.
> > I've found the location of the Xen configs used for VMs in 
> > /etc/libvirt/libxl/vmname.xml and tried to change the graphics type 
> > parameter from 'qubes' to 'vnc' in my AppVM config with virsh and then 
> > start the AppVM, but the Xen config keep reverting back to its original 
> > state after I start AppVM. Is it hardcoded for Qubes OS to overwrite this 
> > file every time when I start VM?
> > How can I enable vnc in Xen config for Qubes OS VM?
> > Rdp/x11vnc and other services that can be installed in the quest OS are not 
> > an options, because I need to access the VM even if the network is broken 
> > in the VM.
> 
> I've found the way to do it in this document:
> https://github.com/QubesOS/qubes-core-admin/blob/master/doc/libvirt.rst
> It works fine.
> 
> Also, there was an error in this libvirt.rst document, it states that it 
> looks for the files:`/etc/qubes/templates/libvirt/by-name/.xml` but it 
> actually looks for 
> files:`/etc/qubes/templates/libvirt/xen/by-name/.xml` in the source 
> code:
> https://github.com/QubesOS/qubes-core-admin/blob/master/qubes/vm/__init__.py

I can change the Xen config, but I can't figure out how to make VNC work 
properly.
With the default HVM, the Qubes OS will configure Xen to use device model stub 
domain for the devices (), including the 
. So the VNC server will be started for the stub domain.
When I try to connect to the VNC server from dom0 I can see this message:
"Guest has not initialized the display (yet)"
https://i.stack.imgur.com/D5HsM.png
VNC client connects to the vmname-dm VM.
When I searched for this problem, I've found this config, suggesting that VNC 
should work with stub domain emulator (but it's not certain):
https://www.mail-archive.com/libvirt-users@redhat.com/msg00118.html
There is also example Xen config for stub domain with VNC that seems to work:
https://wiki.xenproject.org/wiki/StubDom
But there are two separate configs: for HVM and HVM-dm, but in my case there is 
singe libvirt config and I don't know how to use these example configs for my 
case.
Can someone suggest how to fix this issue? Is it just wrong libvirt config or 
does Qubes OS somehow interfere with video/graphics/something else that is 
breaking VNC.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ae49dab1-dcf0-46dc-a190-a7b1a3b59654%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Connect to the AppVM with VNC using Xen capabilities

2017-10-16 Thread msgheap
воскресенье, 15 октября 2017 г., 1:46:40 UTC-4 пользователь msg...@gmail.com 
написал:
> Hello.
> 
> I want to connect to one of my AppVMs with VNC from remote host using Xen 
> capabilities.
> I wanted to do it with the custom Xen config, but I can't figure out how to 
> change the default Xen config or use custom Xen config to start my AppVM. I 
> think it was possible in Qubes OS 3.2 with "qvm-start 
> –custom-config=CUSTOM_CONFIG", but I've installed Qubes OS 4.0 
> (current-testing) and there is no such option now.
> I've found the location of the Xen configs used for VMs in 
> /etc/libvirt/libxl/vmname.xml and tried to change the graphics type parameter 
> from 'qubes' to 'vnc' in my AppVM config with virsh and then start the AppVM, 
> but the Xen config keep reverting back to its original state after I start 
> AppVM. Is it hardcoded for Qubes OS to overwrite this file every time when I 
> start VM?
> How can I enable vnc in Xen config for Qubes OS VM?
> Rdp/x11vnc and other services that can be installed in the quest OS are not 
> an options, because I need to access the VM even if the network is broken in 
> the VM.

I've found the way to do it in this document:
https://github.com/QubesOS/qubes-core-admin/blob/master/doc/libvirt.rst
It works fine.

Also, there was an error in this libvirt.rst document, it states that it looks 
for the files:`/etc/qubes/templates/libvirt/by-name/.xml` but it actually 
looks for files:`/etc/qubes/templates/libvirt/xen/by-name/.xml` in the 
source code:
https://github.com/QubesOS/qubes-core-admin/blob/master/qubes/vm/__init__.py

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6025a370-8fb7-44f5-91ec-dee3ad1f1cdd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Connect to the AppVM with VNC using Xen capabilities

2017-10-14 Thread msgheap
Hello.

I want to connect to one of my AppVMs with VNC from remote host using Xen 
capabilities.
I wanted to do it with the custom Xen config, but I can't figure out how to 
change the default Xen config or use custom Xen config to start my AppVM. I 
think it was possible in Qubes OS 3.2 with "qvm-start 
–custom-config=CUSTOM_CONFIG", but I've installed Qubes OS 4.0 
(current-testing) and there is no such option now.
I've found the location of the Xen configs used for VMs in 
/etc/libvirt/libxl/vmname.xml and tried to change the graphics type parameter 
from 'qubes' to 'vnc' in my AppVM config with virsh and then start the AppVM, 
but the Xen config keep reverting back to its original state after I start 
AppVM. Is it hardcoded for Qubes OS to overwrite this file every time when I 
start VM?
How can I enable vnc in Xen config for Qubes OS VM?
Rdp/x11vnc and other services that can be installed in the quest OS are not an 
options, because I need to access the VM even if the network is broken in the 
VM.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/97fb90a5-e16a-4998-9b32-0ab29ead74bc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.