Re: [qubes-users] Why is dom0 so long behind in versions?
On Tue, Jan 18, 2022 at 5:49 PM Floyd wrote: > On 1/18/22 7:09 AM, 'Rune Philosof' via qubes-users wrote: > > On Tue, Jan 18, 2022 at 1:24 PM 'awokd' via qubes-users < > qubes-users@googlegroups.com> wrote: > >> 'Rune Philosof' via qubes-users: >> > Why not use fedora 35 for dom0? >> > Wouldn't it make it easier to maintain, while also getting better >> hardware >> > support? >> > >> https://www.qubes-os.org/faq/#why-is-dom0-so-old >> > > Security is the core of Qubes, not convenience or bells and whistles. > There are, generally speaking, fewer surprises with mature versions. > > There was a saying in IT of which I often reminded my employees and > colleagues - I don't mind being on the bleeding edge, as long as it's not > the client's blood. Update that to today's reality - I don't mind being on > the bleeding edge, as long as it's not my blood. > Those are good arguments. However, I am testing out 4.1 and looking a bit into the cause of the bugs I see (loading the coredumps in gdb). I find my motivation for using time on getting to the bottom of the errors dropping because there is a chance that the errors are already fixed in newer versions. How hard it would be for me to test it out on newer versions, I wonder. It would be nice if Qubes was something you could add to an existing installation. -- 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/CAL8J5gaxndr1MqGNBmNKaSUjeJYmVxKi6k_zekka65geEaKbbg%40mail.gmail.com.
Re: [qubes-users] Help using qubes as testing VMs
"Eric W. Biederman" writes: >> https://www.qubes-os.org/doc/firewall has information about enabling >> networking between qubes. > > I am going to spin up a second firewall vm and poke some more, and > see if I can get somewhere. I figured it out. Apparently both iptables rules and nftable rules are both being configured to prevent qubes from talking to each other. The redundancy was a real surprise, as that is just unnecessary overhead. Using nftables must be a recent addition and the firewall Documentation has not caught up. Eric -- 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/871r1379vp.fsf%40email.froward.int.ebiederm.org.
Re: [qubes-users] Help using qubes as testing VMs
unman writes: > On Tue, Jan 18, 2022 at 12:49:34PM -0600, Eric W. Biederman wrote: >> >> Can someone tell me if I am missing something? >> >> I do a lot of testing of linux kernels. A bunch of that I have >> historically done in qemu with kvm support. Unfortunately nested >> hardware virtualization does not work. Which means for testing >> for race conditions and the like I need to run the kernels in >> their own HVM. >> >> I use an HVM so I can update the kernel in /boot and reboot the qube and >> be running the kernel I am testing. It would be nice if I could use a >> throw-away qube that just boots with a kernel of my choosing but using >> an stand-alone qube is fine. >> >> Where I run into practical problems is when I want to place specific >> files into my testing qube. I have not figured out how to ssh into >> the qube from another qube, nor have I figured out how to use qvm-copy. >> The best I have right now is to have an external machine that I copy >> things to and then copy them back, which seems like a real hack. >> >> I also have not figured out how to get a serial console from such a qube >> only a graphical one which makes it more difficult than I would like >> to capture errors. >> >> I looked at installing the qubes-core-agent package in my testing HVM >> but it has too many dependencies and installing it makes it impossible >> to test what I would like to test. That is assuming someone has even >> packaged it for the distro I need to test on. >> >> Am I missing something? Is there an easier more straight forward way to >> setup a testing qube? Is it possible to setup a virtual serial console >> to a qube? Is it possible to ssh to a qube from another qube? >> >> Eric > > Hi Eric > > You should probably check out the fine documentation: > https://www.qubes-os.org/doc/managing-vm-kernels/ has information about > using different kernels, including kernels provided by the qube. I don't seem to be missing anything there. I could theoretically use a standalone PV style cube instead of a standalone HVM. But going that route I might not be able to see the output of a boot failure, and the grub timeout is made so small (when installing qubes-core-agent) I do not have enough time to mess with grub in case I install a broken kernel. > https://www.qubes-os.org/doc/firewall has information about enabling > networking between qubes. Unfortunately the formula given there to allow networking between hosts does not work for me and I am not certain why. I am using Qubes 4.0 and that is supposed to work. When I follow the instructions ping works fine but tcp connections make it to the firewall vm and I get a "no route to host" icmp reply. I am not certain what is the problem. I have been able to completely disable the qubes firewall and still the ssh packets are returned with a "no route to host" and icmp packets still make the round trip. It looks like there is some clever networking configuration that I have not figured out yet, which is causing the problem. I am going to spin up a second firewall vm and poke some more, and see if I can get somewhere. > If you are using HVMs you can, in some cases, install qubes packages, > and then use tools like qvm-copy. I say, in some cases, because this > wont work with some targets, like Ubuntu standalones. Yes. I have explored using qubes packages. My initial kernel test configuration is using debian11. Unfortunately the qubes packages make the HVM unusable for my testing. Pulling in a bunch of stuff I don't want and taking over configuration I need to control for my tests. Eric -- 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/87mtjr7fda.fsf%40email.froward.int.ebiederm.org.
Re: [qubes-users] Nitropad X230 with Qubes 4.1
On Wed, 19 Jan 2022 at 12:51, 'taran1s' via qubes-users < qubes-users@googlegroups.com> wrote: > Hello everyone, I am using the Nitropad X230 with the latest 4.0 Qubes > installed. > > In the conversation with Thierry Laurion here > https://groups.google.com/g/qubes-users/c/KsY46D55UQM/m/F3cQ-89KBQAJ it > seemed that at that time the Nitropad X230 was not ready to transit to > Qubes 4.1. > > This part of the conversation actually: Heads will need to be reflashed > with a ROM supporting cryptsetup2 to reinstall. Heada will also need to > be based on coreboot 4.13+ as per pending Heads pull request 1015. > > Consider this as a beta testing ROM. > > Is the situation different now with rc4, or is it advisable to wait till > the transition will be ready? > > Thank you! > > -- > 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/01457a0b-9ac2-c4f4-7678-56e25de0374b%40mailbox.org > . > Nitropad will need to provide you an upgrade path that supports Cryptsetup2 in order to move to QubesOs 4.1 Alternatively, you could flash a current version of the X230 heads firmware (which uses 4.13 and cryptsetup2) by building this yourself from source, or grabbing a prebuilt bin from the Heads CircleCI https://app.circleci.com/pipelines/github/osresearch/heads - the hardware is still an X230. However you need to consider if Nitropad would support your product were you to do this. -- Kind Regards, Simon Newton E: simon.new...@gmail.com -- 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/CADLktjANHT7xUMP2xbUqd7cQf3hCVJUb0FGMdAPZT6SDkns5Bw%40mail.gmail.com.
[qubes-users] Nitropad X230 with Qubes 4.1
Hello everyone, I am using the Nitropad X230 with the latest 4.0 Qubes installed. In the conversation with Thierry Laurion here https://groups.google.com/g/qubes-users/c/KsY46D55UQM/m/F3cQ-89KBQAJ it seemed that at that time the Nitropad X230 was not ready to transit to Qubes 4.1. This part of the conversation actually: Heads will need to be reflashed with a ROM supporting cryptsetup2 to reinstall. Heada will also need to be based on coreboot 4.13+ as per pending Heads pull request 1015. Consider this as a beta testing ROM. Is the situation different now with rc4, or is it advisable to wait till the transition will be ready? Thank you! -- 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/01457a0b-9ac2-c4f4-7678-56e25de0374b%40mailbox.org.
