Re: [qubes-users] What happened to "paranoid mode"?
On Tue, Feb 25, 2020 at 12:42:42AM +0530, Anil wrote:
> At that time I didn't notice, but what in the world is TOFU? I even
> looked it up on Google, in Urban Dictionary, but still couldn't decide
> in which sense it was being used and for what.
In top-posting style, the original message is included verbatim, with the reply
above it. It is sometimes referred to by the acronym TOFU ("text over,
fullquote under"). It has also been colloquially referred to as Jeopardy! reply
style: as in the game show's signature clue/response format, the answers
precede the question.
https://en.wikipedia.org/wiki/Posting_style
/Sven
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/20200225011749.GA1116%40app-email-private.
signature.asc
Description: PGP signature
[qubes-users] Re: feature request
Could you please show screenshots to see how it looks like? On Thursday, February 20, 2020 at 2:36:52 PM UTC+3, Eva Star wrote: > > I don't know why nobody mentioned, but there is quick and easy working > solution for XFCE qubes called devilspie2. Possible to easy install at dom0 > and manage windows per 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/17860cec-6849-4d12-a02c-fbb6f2c7bb64%40googlegroups.com.
[qubes-users] AMD processors and Cubes 4.03
Hi, I installed Cubes 4.03 and everything worked fine except I get the "does not support the virtualization" error message. So I check my cpu, which is an AMD RX 427 and it lists AMD-V under virtualization, and the flags include npt, which means the RVI should work. So why won't my processor work with Cubes 4.0.3? Thank You, Joe Milosch -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200224145403.322832c3%40z15.zentara.net.
Re: [qubes-users] No boot after dom0 kernel update
I want to make clear that in each case, the new kernel has worked fine once I persuaded my BIOS to boot it. The problem is always that, after each kernel upgrade, the BIOS no longer recognizes any bootable partition, not even listing the drive among its boot options. Unmounting before fsck is the standard process, but I wonder why and how the dom0 kernel upgrade script leaves the boot partition in a state that the BIOS will not boot. I am far from certain that the fsck.vfat was what restored bootability, but something did. dom0 kernel upgrade should not leave the boot partition in such undesired state, unless there is some hard to reproduce bug. Otherwise it will get fixed really soon. I do not have whole lot of details about your configuration.. but if you really believe this issue is caused by the dom0 kernel upgrade script, then try to reproduce it in a minimal amount of steps, e.g.: 1. install qubes os of version X.Y.Z with the /boot on FAT FS (+ any other custom settings you have, including if you have a dual boot); 2. run qubes-dom0-update kernel-x.y.z; Otherwise it's hard to help. You can also inspect the install scripts by yourself: $ rpm -q --scripts kernel $ less /bin/kernel-install Kind regards, Andrey Arapov -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/6a462707231ce372a7168232fec690a7%40nixaid.com.
Re: [qubes-users] No boot after dom0 kernel update
Thank you for your kind attention. I want to make clear that in each case, the new kernel has worked fine once I persuaded my BIOS to boot it. The problem is always that, after each kernel upgrade, the BIOS no longer recognizes any bootable partition, not even listing the drive among its boot options. Unmounting before fsck is the standard process, but I wonder why and how the dom0 kernel upgrade script leaves the boot partition in a state that the BIOS will not boot. I am far from certain that the fsck.vfat was what restored bootability, but something did. On Monday, February 24, 2020 at 1:58:48 PM UTC-5, Andrey Arapov wrote: > Is there a way to get reliable booting after a dom0 kernel > update? > > > I am afraid that there is no such way as the new Linux kernel adds new > features, changes the current ones, which are unlikely were thoroughly > tested (or if tested at all) for the whole range of HW out there or their > combinations. > > Whenever you are upgrading the SW, be it a Linux kernel or any other > software, you should always expect things can go wrong. > The good news is that you can always rollback and contribute to the FOSS > by reporting the issue. > > Do I need to unmount my /boot partition and fsck.vfat it > before rebooting? > > > You should always unmount the mount point before fsck'ing any filesystem. > > Kind regards, > Andrey Arapov > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1724d125-278c-42de-9316-13c480cdd0bb%40googlegroups.com.
Re: [qubes-users] VMs to boot to new kernel
I find that dom0's /var/lib/qubes/vm-kernels/ does not list a 5.4 kernel, despite that dom0 uname reports running it. After I run # qubes-dom0-update kernel-latest-qubes-vm a 5.4 kernel is now listed, and is now selectable using Qube Settings/Advanced. Thank you. On Monday, February 24, 2020 at 1:44:02 PM UTC-5, Andrey Arapov wrote: > > Question: How to get VMs to boot to a newly installed kernel? > > > To change the default kernel for VM's: > > [arno@dom0 ~]$ uname -r > 4.19.100-1.pvops.qubes.x86_64 > [arno@dom0 ~]$ qubes-prefs -s default_kernel 4.19.100-1 > > the value should correspond to what you find in > /var/lib/qubes/vm-kernels/, e.g. > /var/lib/qubes/vm-kernels/4.19.100-1/vmlinuz > > And restart the VM's. > > To change the kernel for a specific VM only: > qvm-prefs -s kernel 4.19.100-1 > > > Kind regards, > Andrey Arapov > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e8a85186-e625-495d-9ee5-90408f95c4fa%40googlegroups.com.
Re: [qubes-users] Re: qvm-create-windows-qube 2.0
man. 24. feb. 2020 kl. 14.12 skrev A E : > ons. 19. feb. 2020 kl. 15.51 skrev A E : > >> tor. 13. feb. 2020 kl. 00.24 skrev M E : >> >>> søn. 26. jan. 2020 kl. 23.12 skrev 'Elliot Killick' via qubes-users < >>> qubes-users@googlegroups.com>: >>> On 2020-01-26 12:37, Claudio Chinicz wrote: > ׁHi Elliot, > > I've downloaded again and succeeded creating the HVM. > > I had a Windows 10 HVM I built manually just booting from the ISO and where > I did not succeed installing the QWT (boot after the QWT install would > freeze). > > Would you recommend building a Template from this HVM? > > The big advantage I saw in this implementation was that I can confortably > run my applications with 2GB (minimum) vs 6GB in my previous HVM. Another > advantage of the QWT is that I can send files from Windows to any other > PV/HPV VM using qrexec. > > What's intriguing me is that copy/paste between VMs is not working. When I > ctl+shift+C on my Windows VM I see the popup saying I can ctl+shift+V on > another VM but when I do so nothing is pasted. Any ideas? > > Thank you very much for this scripts/Windows VM builder. > > Regards By freeze do you mean it stops on the part where QWT tries to create the private disk? This is documented in the QWT Known Issues section of the README. Just exit that window with the error message and the installation will proceed as normal. Besides that for Windows 10/Windows Server 2019, you should not have to interact with any window or part of the installation. Sometimes, QWT may also just crash upon boot causing Windows to crash. This doesn't happen often, however, it is also documented in the README. This is more likely to happen if you installed Windows manually as you said because unstable QWT features like Qubes Memory Manager (qmemman) are enabled by default which we disable in the qvm-create-windows-qube.sh script (Thanks to @brendanhoar for that one). Due to that bug in making the private disk required, it's not possible to create templates for Windows 10/Windows Server 2019 anyway. Otherwise, I would recommend for must users to build a template with the software they want pre-installed and make AppVMs from that. Regarding copy/paste not working, it appears to work fine for others so I would just suggest you restart the Windows qube or possibly make a new one. If it's copying the data out correctly then there should be a notification saying "Copied X bytes to the clipboard". You're welcome, Claudio! Regards, Elliot -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2de7254e-c22c-3275-cdfd-30cdacd86a67%40zohomail.eu . >>> >>> >>> >>> I want to install Windows 10 from a DVD in a new HVM and have begun >>> following this guide: https://www.qubes-os.org/doc/windows-vm/ >>> >>> It says: >>> >>> “Create a new Qube: >>> Name: Win10, Color: red >>> Standalone Qube not based on a template >>> Networking: sys-firewall (default) >>> Launch settings after creation: check >>> Click “OK”.” >>> >>> As I’m going to install Win 10 from a DVD, shall I then just follow the >>> guide and choose “Launch settings after creation” or shall I choose >>> “Install from device” ? >>> >> >> >> I have made a Windows domain and downloaded and installed Windows 7 and >> Qubes Windows Tools by executing this script in dom0 according to this >> guide (link: https://github.com/elliotkillick/qvm-create-windows-qube ): >> >> chmod +x install.sh && ./install.sh >> >> And now I would like to know how to get further. >> >> I have made a thread here about making a Win10 HVM, so you are welcome to >> answer there instead (I have just made this post in attempt to get a >> quicker response): >> >> https://groups.google.com/forum/m/#!topic/qubes-users/78DgmWxZf80 >> >> How to use the script of the download-windows.sh file ? > > When I execute the script in the terminal, the different windows versions > are listed. But when I copy the label of one of them and paste it on the > line below it and press enter, the terminal says that it doesn’t recognize > the command. > More precisely worded: How to use the download-windows.sh file to download Win10 Pro 64 bit ? -- 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 view this discussion on the web visit
Re: [qubes-users] What happened to "paranoid mode"?
At that time I didn't notice, but what in the world is TOFU? I even looked it up on Google, in Urban Dictionary, but still couldn't decide in which sense it was being used and for what. I have been exploring the backup options suggested by you and others. Once reason 'those people' (I will still call them common people, although they will actually be power users at least, if they have come to this point in using OSs) may think twice about something like borg, is that, in Qubes, they will be wary of installing (or putting) something in dom0: something that can be executed. Perhaps that is being overcautious, but borg, for example, requires installation of several other dependencies. There aren't just two kinds of people: Developers/power-users and those who don't know how to delete a file without using a mouse. Unless I am extremely wrong, most Linux users will fall in somewhere between these two extremes and may of them won't even be power users. Linux is actually being used now and you can manage to do quite a lot with the GUI, so becoming more and more like Windows in that sense. I am sure you, of all people, know that, but my long term peeve (expressed before on this forum) has been that this large section of people in the middle is largely ignored. Even the documentation, as I pointed out earlier, is either too technical or too noob-friedly, although I understand that there aren't enough people to do documentation and this is open source and free software. They - we - have to go to something like reddit for finding clues. That aside, if one does decide to install bog, it seems to be a pretty good option. On Sat, 4 Jan 2020 at 18:50, wrote: > > On Sat, Jan 04, 2020 at 05:05:01PM +0530, Anil Eklavya wrote: > > (please dont TOFU) > > > I wasn’t aware of these options. Thanks for pointing out. I will > > certainly try them out. > > this is all "some assembly required" stuff, but i will try to describe > a working borg setup with some variations and try to explain some of > the thinking behind it. > > there are some example scripts here: > https://github.com/xaki23/rzqubes/tree/master/borg > > most of these are not commented, userfriendly or have proper > separation of "code" and "config", but otoh we are talking > about something you set up just once for each system. > > the complex parts there are bsnap.sh (which is the hourly > cronjob that does the actual borg-snapping) and bsync.sh > (which is optionally called at the end of bsnap and does > the syncing of backup to external target(s), if desired). > the *wraps are just thin wrappers as crude ways to use > remote-capable tooling (here: borg and rsync) over qubes-rpc. > > bsnap.sh has a bit of config at the beginning (lines 3-5), > storing a password like that is certainly not ideal, but otoh > doesnt matter (to me) since the script is inside dom0 which > already has access to all my data and if it is compromised > its pretty much gameover anyways. > > lines 7-13 are leftover from qubes3 days (or for people using > qubes pools of type "file" with q4). > > lines 15+16 are a sample of how to use the remote-wrapped variant. > basicly that means your dom0 still does all the reading, chunking, > encryption, but the actual storage backend process is running > on a remote host (or in a qubes appvm). this can be very useful > if you are backing up a stationary desktop to a bulk storage > host on the same lan. > > lines 20-30 are three "backup groups". private volumes at rest, > unsynchronized private volumes of running vms, and dom0 as "files". > the FLP/FLS parts (lines 20+24) select which VMs are backed up > in that way, you can play around with the ls+grep on the commandline > until it matches whatever you want to back up. the examples there > are of the "everything, except what the grep throws away". > > lines 21+25+29 delete old backup snapshots that are outside the > specified keep-range. 30/30/30/30 is _a_ _lot_ ... > > lines 34-43 are the call to sync out the backup to external > storage, with crude locking. the locking (even when less crude) > is mainly a policy question. if you dont use locking for the sync, > and your sync takes longer than your backup frequency, you might > end up with the sync always just doing half a sync, never completing. > that can be very bad. > otoh, if you do locking, and the (locked) sync stalls out and you > dont have stale-lock detection or a timed hard limit, that stalled > sync job will block all newer sync attempts forever. > thats also very bad. > > the called-under-lock bsync.sh tries to level the field (lines 4-8) > by killing/removing anything that might be leftover from older > syncs, creates a lvm snapshot of the local lvm backup volume, > attaches it to a sync-vm and runs a target-specific script inside > that vm. > this is just as setup-specific as it is modular. > doesnt matter to the backup at all whether the sync is done > over webdav, nfs, cifs or rsync-over-ssh. > > the modularity isnt limited to
Re: [qubes-users] No boot after dom0 kernel update
Is there a way to get reliable booting after a dom0 kernel update? I am afraid that there is no such way as the new Linux kernel adds new features, changes the current ones, which are unlikely were thoroughly tested (or if tested at all) for the whole range of HW out there or their combinations. Whenever you are upgrading the SW, be it a Linux kernel or any other software, you should always expect things can go wrong. The good news is that you can always rollback and contribute to the FOSS by reporting the issue. Do I need to unmount my /boot partition and fsck.vfat it before rebooting? You should always unmount the mount point before fsck'ing any filesystem. Kind regards, Andrey Arapov -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/30b614a3ba4e02e7007eb07f4e612737%40nixaid.com.
Re: [qubes-users] VMs to boot to new kernel
Question: How to get VMs to boot to a newly installed kernel? To change the default kernel for VM's: [arno@dom0 ~]$ uname -r 4.19.100-1.pvops.qubes.x86_64 [arno@dom0 ~]$ qubes-prefs -s default_kernel 4.19.100-1 the value should correspond to what you find in /var/lib/qubes/vm-kernels/, e.g. /var/lib/qubes/vm-kernels/4.19.100-1/vmlinuz And restart the VM's. To change the kernel for a specific VM only: qvm-prefs -s kernel 4.19.100-1 Kind regards, Andrey Arapov -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f09260920d3ca7d6d38e46b30ab4a25e%40nixaid.com.
[qubes-users] No boot after dom0 kernel update
I find that, when I update dom0 with a new kernel, too often my machine won't boot anymore, after the update. Then I need to tinker with the boot partition. It seems as if, this last time, what worked was to run fsck.vfat on the partition. I am (I hope understandably) reluctant to mess about with this bit of infrastructure without strong need. The machine is an ASUS K501UW, UEFI boot only, that needs "nouveau.modeset=0" to avoid frequent kernel oopses, so installing was a chore. Is there a way to get reliable booting after a dom0 kernel update? Do I need to unmount my /boot partition and fsck.vfat it before rebooting? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/6dd1008e-b433-4718-bf6b-3c30e0b3c650%40googlegroups.com.
[qubes-users] VMs to boot to new kernel
I recently succeeded in getting my dom0 upgraded to a 5.4 kernel. (I can't recall how, because it would not boot for some days afterward. More about that in another post.) Now uname in dom0 reports the shiny new 5. 4 kernel. I also got 5.4 kernels installed in some VM templates. However, when I start such a template or a VM referring to one, they still boot into the older, 4.19 kernel. Question: How to get VMs to boot to a newly installed kernel? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/9ca2cbd8-bddc-43de-a467-d08032f5a5f7%40googlegroups.com.
Re: [qubes-users] Running sshd on an AppVM
On 2/24/20, tetrahedra via qubes-users wrote: > On Mon, Feb 17, 2020 at 10:03:26AM +0100, dhorf-hfref.4a288...@hashmail.org > wrote: >>On Mon, Feb 17, 2020 at 08:59:18AM +, tetrahedra via qubes-users >> wrote: >>> like only debian's `apt-search` will search the binary names, fedora's >>> `dnf search` appears not to. Fyi - The dnf command does search for binaries, but you need to use the full path, or a wildcard path, for it to work correctly. e.g. $ sudo dnf search '*/sshd' will return the package that will install the 'sshd' binary. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAJ5FDngkPA9OhioZ3v3ncaS%3Dxbkc%2BRRqOZRiVWzD5FCjhVKsRg%40mail.gmail.com.
Re: [qubes-users] Running sshd on an AppVM
On Mon, Feb 17, 2020 at 09:28:37AM +0100, dhorf-hfref.4a288...@hashmail.org wrote: How do I set up an SSH server on my AppVM? i deviate from the regular "how to do portforwards with qubes" for this and have a qubes-rpc service that basicly just does "exec sudo sshd -i" in the target vms, then do a socat/systemdsocket bounce to the rpc service straight from sys-net. that way the "messing with firewalls" is limited to exactly one INPUT rule in sys-net, plus one qubes-rpc policy, and there are no perma-running services in the target vm at all! Very nice! -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200224150148.GB1499%40danwin1210.me.
Re: [qubes-users] Running sshd on an AppVM
On Mon, Feb 17, 2020 at 10:03:26AM +0100, dhorf-hfref.4a288...@hashmail.org wrote: On Mon, Feb 17, 2020 at 08:59:18AM +, tetrahedra via qubes-users wrote: like only debian's `apt-search` will search the binary names, fedora's `dnf search` appears not to. dnf whatprovides sshd Did not know about that! -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200224145953.GA1499%40danwin1210.me.
Re: [qubes-users] Re: qvm-create-windows-qube 2.0
ons. 19. feb. 2020 kl. 15.51 skrev A E : > tor. 13. feb. 2020 kl. 00.24 skrev M E : > >> søn. 26. jan. 2020 kl. 23.12 skrev 'Elliot Killick' via qubes-users < >> qubes-users@googlegroups.com>: >> >>> >>> On 2020-01-26 12:37, Claudio Chinicz wrote: >>> > ׁHi Elliot, >>> > >>> > I've downloaded again and succeeded creating the HVM. >>> > >>> > I had a Windows 10 HVM I built manually just booting from the ISO and >>> where >>> > I did not succeed installing the QWT (boot after the QWT install would >>> > freeze). >>> > >>> > Would you recommend building a Template from this HVM? >>> > >>> > The big advantage I saw in this implementation was that I can >>> confortably >>> > run my applications with 2GB (minimum) vs 6GB in my previous HVM. >>> Another >>> > advantage of the QWT is that I can send files from Windows to any >>> other >>> > PV/HPV VM using qrexec. >>> > >>> > What's intriguing me is that copy/paste between VMs is not working. >>> When I >>> > ctl+shift+C on my Windows VM I see the popup saying I can ctl+shift+V >>> on >>> > another VM but when I do so nothing is pasted. Any ideas? >>> > >>> > Thank you very much for this scripts/Windows VM builder. >>> > >>> > Regards >>> >>> By freeze do you mean it stops on the part where QWT tries to create the >>> private disk? This is documented in the QWT Known Issues section of the >>> README. Just exit that window with the error message and the >>> installation will proceed as normal. Besides that for Windows 10/Windows >>> Server 2019, you should not have to interact with any window or part of >>> the installation. Sometimes, QWT may also just crash upon boot causing >>> Windows to crash. This doesn't happen often, however, it is also >>> documented in the README. This is more likely to happen if you installed >>> Windows manually as you said because unstable QWT features like Qubes >>> Memory Manager (qmemman) are enabled by default which we disable in the >>> qvm-create-windows-qube.sh script (Thanks to @brendanhoar for that one). >>> >>> Due to that bug in making the private disk required, it's not possible >>> to create templates for Windows 10/Windows Server 2019 anyway. >>> Otherwise, I would recommend for must users to build a template with the >>> software they want pre-installed and make AppVMs from that. >>> >>> Regarding copy/paste not working, it appears to work fine for others so >>> I would just suggest you restart the Windows qube or possibly make a new >>> one. If it's copying the data out correctly then there should be a >>> notification saying "Copied X bytes to the clipboard". >>> >>> You're welcome, Claudio! >>> >>> >>> Regards, >>> >>> Elliot >>> >>> >>> >>> -- >>> 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 view this discussion on the web visit >>> https://groups.google.com/d/msgid/qubes-users/2de7254e-c22c-3275-cdfd-30cdacd86a67%40zohomail.eu >>> . >> >> >> >> I want to install Windows 10 from a DVD in a new HVM and have begun >> following this guide: https://www.qubes-os.org/doc/windows-vm/ >> >> It says: >> >> “Create a new Qube: >> Name: Win10, Color: red >> Standalone Qube not based on a template >> Networking: sys-firewall (default) >> Launch settings after creation: check >> Click “OK”.” >> >> As I’m going to install Win 10 from a DVD, shall I then just follow the >> guide and choose “Launch settings after creation” or shall I choose >> “Install from device” ? >> > > > I have made a Windows domain and downloaded and installed Windows 7 and > Qubes Windows Tools by executing this script in dom0 according to this > guide (link: https://github.com/elliotkillick/qvm-create-windows-qube ): > > chmod +x install.sh && ./install.sh > > And now I would like to know how to get further. > > I have made a thread here about making a Win10 HVM, so you are welcome to > answer there instead (I have just made this post in attempt to get a > quicker response): > > https://groups.google.com/forum/m/#!topic/qubes-users/78DgmWxZf80 > > How to use the script of the download-windows.sh file ? When I execute the script in the terminal, the different windows versions are listed. But when I copy the label of one of them and paste it on the line below it and press enter, the terminal says that it doesn’t recognize the command. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CABRRaUE4oGz-Z%2BSqcmaG%2BHC_aDWy7o6mux7PLqy-JSStMmS24A%40mail.gmail.com.
[qubes-users] Re: HCL - ASUS KGPE-D16
What hard drive do you use? I do not recommend this motherboard to anyone, Slow as hell, memory works bad (i use 64gb ram crucial 16x4, works only two modules) Coreboot support is over. No UEFI. And you need ASUS PIKE 2008 ( or any other controller) and one 6100 cpu for stock bios upgrade. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/b0002f14-f2d6-4267-b569-acd3719f7484%40googlegroups.com.
[qubes-users] Re: HCL - ASUS KGPE-D16
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 For the benefit of other users who may wish to use this board here is a few notes from my experience of getting Qubes R4.0 running: Mobo: Asus KGPE-D16 CPU: AMD Opteron Processor 6282 SE Memory: 4x MT36KSF2G72PZ-1G6E1FE GPU: NVIDIA GeForce GT 710 Coreboot 4.11 (GRUB2) As stated by other users, the onboard GPU is problematic with this motherboard and coreboot. I struggled to get the Qubes installer to accept the GT710 as the primary display. Thankfully the onboard GPU can be disabled either by disabling it when building coreboot or by physically setting a jumper on the motherboard (to which I chose the latter for easier debugging). This however presents us with attempting to boot the installer headless-ly. I achieved this by having the installer on one USB stick and another with a grub.cfg on it which I could change on another machine when required. The grub.cfg inside coreboot’s ROM would chainload to this. It should be noted that although this processor has IOMMU, and it was enabled in coreboot. Qubes installer warned that it was not present. This was overcome by appending ‘iommu=force’ to Xen’s command line. With all this setup I was able to power the machine on, and my screen would turn on when Linux initialised via the second GPU (with the jumper set, to Linux this appeared to be the only GPU). The installer ran without issue. Once installed, I removed the drive to inspect the generated grub.cfg file, and used the same method of chainloading config files to boot the system. Once I was satisfied with how the system was booting I embedded this into the ROM to remove the use of the USB stick. Creating symlinks to Xen, Linux and initrd helps in case of version updates, just remember to update them with any updates. Without OpenBMC the fans run at full speed. sensors-detect with its default queries load a kernel module that incorrectly reports fan speed and cannot control them. However one of its questions does allow you to load a module that can control the fans (I’m not sure which one, I just ran ‘yes | sensors-detect’ to probe everything). With this done pwmconfig was able to quieten down the fans and saves having to buy the module. Not KGPE-D16 specific however video performance was lacking with this card. However ‘sudo qubes-dom0-update kernel-latest’ helped this (a lot!, browser smooth scroll is smooth and YouTube plays decently). Further notes: SeaBIOS may have been easier than GRUB however I utilise GRUB’s signatures checks. There is no audio ports on the rear panel and no headers (I think?). The manual recommends installing a sound card however audio through HDMI via the GPU works. If your screen speakers are crap like mine you can get HDMI audio video splitters. The performance of this system is really great and much surpasses my former Qubes system (i7 X230). TPM modules are available which I'll invest in at some point. The performance looks to get better as NUMA awareness [1] is on the horizon (albeit with a ‘Far in the future’ milestone) Heads [2] looks really hopeful and I’ll probably replace my current coreboot setup with it when I get a TPM. As Linux is the first thing that loads, I’m hopeful we can forget about all this VGA disabling annoyingness. [1] https://github.com/QubesOS/qubes-issues/issues/5628 [2] https://github.com/osresearch/heads Thomas -BEGIN PGP SIGNATURE- iQJJBAEBCgAzFiEEWJ5tBOsioBjk2XnjPJv1q0TTly4FAl5TiigVHHRob21hc2M1 OTlAZ21haWwuY29tAAoJEDyb9atE05cuqecP/3lKwIplr3rDVBEnmfUMaih39Boe XGq+/SXBmCZINFIdNwGHM1MV2AWNXcASbm1HZTPbraHnt7oOmbT6PmlwEuUqbgJS s7x0E4cdLL1HPlSW0h4u3wwlapC3N0FmP5O32t7PbIJHMZJ95Mm6xdTYIYSQqRfA N6S3rL1RkxMyBdJkUgIcg0nhFiZJtENoskxWJ29gRYUYgnG9GKGRAySKVgde+ZpD bL/ycivwbWV18f22UYCet61WKKa99xp6DwPiWGQM116GR8Xdac/HSbZgeLm6jq9d 3h/0ZA910aZQdzKUr5tnsoLISjvHPNKZ+0LIilQI39uch20f9nQcIKULkRJSvfco DrCVsa47wR7FIJwrG/SswzO0bff8Or11g+anvui9CsFHzo/EsFir11mwb13ZODYp CtYIg2/SiJsXcXTRs+gAMMYaQQRVem4EPFF4OKb0gMIDYgRa/ViRHtaxT7/IWpQA d+iJHCv6zVySQNuDU513JZUplIxAbA19RyarBKTaOWGopkxS0KJ+45Lcfw9FH038 VfKYoa/rTnZn0/oJRh8kq937CgfwkgHQxgHXGKFG5mM13cpXhSuiTI+KCs/rWLbN bYfkSQSachILBKEMEHytWP1aDuAsikWCuOAnqEEinxvqQaCFp3CAgfwMTD4U9HBQ LCIMjf/3jvyL9w3T =W/SZ -END PGP SIGNATURE- -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/36b59873-e526-4c29-a1e4-6f8d1b46d39a%40googlegroups.com.
