[qubes-users] Re: Major Problem: Boot Loop after Upgrading dom0
On Monday, May 28, 2018 at 6:00:05 PM UTC+2, [ 799 ] wrote: > Hello, > > > After Upgrading my AppVMs to Fedora 28 yesterday I tried to upgrade dom0. > During the update I ran into problems with the kernel upgrade. > As the process seem to be stuck I interrupted with STRG + C. > > > Upon next reboot I run into a bootloop after passing Grub menu. > > > Any idea how to proceed? > > > [799] You should choose in grub menu an older kernel and do the grub2-mkconfig command as suggested. -- 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/54305e7a-732a-47ef-90b3-cdb887efecb1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Dolphin or Nautilus in a standard Qubes AppVM Template
On Sunday, May 27, 2018 at 10:16:17 PM UTC+2, [ 799 ] wrote: > Hello, > > I am currently migrating from fedora-26 to fedora-28 which includes replacing > my templates buy rebuilding from scratch. > > I decided to replace my "fat AppVM templates" which have been based on > fedora-26 before with AppVMs based on the > fedora-28-minimal template. > > The question is now, if I should install Dolphin or Nautilus as the default > File Manager and which qubes-specific question I should install. > What do you suggest under Qubes Dolphin or Nautilus? > > > [799] For fedora use nautilus. Better Qubes integration. In debian use dolphin, because in the past there already were some Qt packages installed. And respectively use Qt Applications in debian and gtk stuff in fedora. That is my advice. -- 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/b6c15394-4932-4992-a1d1-fc92bb8c26e2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] fedora-27-minimal: networking support?
> I want networking, but NOT use the https://www > .qubes-os.org/doc/templates/fedora-minimal/late as sys-net/-firewall > > Thank you! > > Joh Why not? Isn't it a prefered way to have an All-I-Need-Is-In-For-Networking-VM? Maybe additional packages someone would never use in an AppVm is an argument or to get only the basic support to lower any risk. -- 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/d236a808-e835-42ea-85b8-c076e235461b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] How to use sudo/nm-applet in qubes 4.0 in fedora-2X-minimal
I installed qubes-template-fedora-26-minimal, upgraded it to release version 28 (paid attention to the python2-xcffib bug) and cloned it to make a network-"for-all-things-networking"-VM-only template. So far, as written in qubes documentation->fedora-minimal, I installed the networking related packages to let the template act as a minimal-networking-stuff-template. But nm-applet is not authorized to control. And here we stops, because it seems that qubes-core-agent-passwordless-root and/or polkit is always necessary. (?) But because of a choice of design in Qubes 4.0, it is not installed as default. Whereas qubes-core-agent-systemd and qubes-core-agent-qrexec are installed by default as written in the documentation. What is the mind behind this choice? Just asking out of sheer curiosity. The package polkit depends on spidermonkey javascript stuff (mozjs52 package). 6.5MB of not relevant stuff for just an networking VM. Because it works except the nm-applet authorization thingy. "nmcli general permissions" gave me a timeout as fedora-minimal AppVM user. Can I get around this by adding the user to a specific group to get the rights to use nm-applet as an user? A search gave me answers to a nm-applet bug in 2015: https://mail.gnome.org/archives/networkmanager-list/2015-January/msg00033.html There is a hint that NM uses polkit and/or systemd. But only polkit is not installed (I guess). An advice someone wrote in the link: "Alternatively, if you don't care about user permissions and want to allow any user to control networking you can build NM with --with-session-tracking=none and --with-polkit=no to disable this functionality." I guess, this would be a workaround to get the minimal networking VM to fully work, am I correct? This should be the same behavior as qubes' passwordless-root just for NM and with less packages - or is this way intending that anyone (even nobody-user, if existing) could handle NM but do not get any other root files like write to /rw/ in the NetVM and is therefor less "secure" than user-polkit-passwordless-root installation and interaction!? -- 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/8db3b6c8-ebd2-497e-ac57-26f3459c2078%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: How to attach CDROM /dev/sr0 to appvm?
On Sunday, May 27, 2018 at 10:14:14 PM UTC+2, Inqubator wrote:
> On Sunday, May 27, 2018 at 3:41:41 PM UTC+2, awokd wrote:
> > On Sat, May 26, 2018 9:24 pm, Inqubator wrote:
> > > On Saturday, January 30, 2016 at 11:25:47 AM UTC+1, Dimitri wrote:
> > >> I'd like to listen to music but I didn't yet succeed with reading a
> > >> CDROM in a appvm. Qubes manager offers the option to attach dom:/dev/sr0
> > >> but the device won't show up in the appvm. (qvm-block tells me that
> > >> /dev/sr0 is attached as xvdi but there's no xvdi in the vm) Any ideas?
> > >> Thanks
> > >
> > > Same here: I attach my cdrom (sr0) to the domain "personal" but it doesn't
> > > show up there. qvm-block, run in dom0, shows it as used by "personal" (as
> > > "xvdi").
> > >
> > > Dmesg does not show anything but throws an error, both in dom0 and
> > > personal: "dmesg: read kernel buffer failed: Operation not permitted".
> > >
> > > Ideas?
> > >
> > > (BTW: I am using Qubes 4)
> >
> > I think that is a Xen limitation. It should work as you describe with data
> > CDs, but for music you might have to take one of these
> > https://www.qubes-os.org/doc/recording-optical-discs/ approaches.
>
> Thanks for the suggestion.
>
> I had tried with a music CD actually. But when I inserted a data CD, nothing
> changed. It just doesn't show up in the VM, despite the fact that Qubes shows
> it as attached. Very frustrating.
>
> Other ideas?
In dom0 (just a file you can delete afterwards) console as user:
truncate -s 500MB /var/tmp/testfile.img
testthis=$(sudo losetup -f --show /var/tmp/testfile.img)
sudo mkfs.ext2 ${testthis##*/}
qvm-block a VMname dom0:${testthis##*/}
In VMname AppVM as user with sudo or root:
sudo mount /dev/xvdi /mnt/removable
sudo ls -la /mnt/removable
Read/write ability available?
If true, is it possible that the domU kernel cannot read your type of music cd?
Maybe a drm codec/copyprotection?
But you said you tried this with data cd's too.
If not readable, something is wrong with qvm-block with cdroms and/or you have
chosen the wrong AppVM by name? ;-)
--
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/46bf274b-c066-414e-ae99-e5ce85bd29af%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Q4rc4 :: Fedora AppVM Screenshot-Tool only generates black window
On Thursday, February 15, 2018 at 11:15:51 PM UTC+1, [799] wrote: > Hello, > > I am migrating most of my work tasks to Qubes but found out, that I can't use > the screenshot tool in the Fedora based AppVM. > > When I launch the screenshot tool, I can launch a screenshot, which covers > another window are part of the screen with a window from the same AppVM, but > the screenshot only result in a black copy, the content is not shown. > > I am using a Fedora 26 AppVM based on the default Fedora template which > comes with Qubes 4rc4. > I have updated the template to the latest version. > > Can someone verify if this is a really a bug or what I need to do to get > screenshots working. > Most of my work involved creating screenshots for troubleshooting and > documentation. > > Regards > > [799] > > -- > Qubes 4rc4 > Lenovo X230 + Lenovo W540 So you want my brain involved to troubleshoot your screenshot problem to get your brain back to work creating screenshots for troubleshooting? Because you are the first one since release of qubes 4.0 rc4 (first handy information), you should provide some more information than telling us the standard template everyone else using qubes 4.0 rc4 also have. In example what video device does lspci list? What processor are you using? Any modifications in grub config files? Ask yourself some questions what may be of interest. Have you started your template one more time to (maybe) finish some system tasks? Have you tried turning it off and on again? -- 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/9f17a079-a928-4b7c-870f-f89aa254e71d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: QUBES 4 r4 - dom0 UTC time is incorrect - manual change each reboot.
On Sunday, February 18, 2018 at 5:52:34 PM UTC+1, QUBE-A-LICIOUS wrote: > On Thursday, February 15, 2018 at 5:42:44 PM UTC-5, schnuren...@gmail.com > wrote: > > On Tuesday, February 13, 2018 at 10:51:12 PM UTC+1, QUBE-A-LICIOUS wrote: > > > Hi there, > > > > > > I have a fresh install of Qubes 4r4. However, when I reboot and or login > > > I have to manually change dom0 time to UTC. > > > > > > Impact: Whonix/Tor does not work because of the incorrect time. > > > > > > Manual workaround: > > > 1. Get the correct UTC from a browser. > > > 2. Open Dom0 Terminal and update to UTC such as the following: > > > > > > sudo date --set "2018-02-13 21:30" > > > > > > 3. Shutdown Service:sys-whonix > > > 4. Restart a whonix domain such as Domain:anon-whonix(this restarts the > > > sys-whonix service that was just shutdown. > > > 5. Then run WhonixCheck to make sure it works. It usually does and > > > Whonix/Tor is functional. > > > > > > = > > > Qubes cannot be this bad, really. > > > > > > How can I have this Date and time correctly updated on boot up? Like it > > > should. > > > > > > Thanks for all your help. > > > NSJ > > > > Most times it is easy to point on another guilty one instead looking what > > may happen with the own stuff. So far you are the only one with this > > misbehavior. > > Qubes works as expected - at least in this point. > > But most user already experienced this behavior; qubes-os or any other > > distribution. > > The keyword is hwclock. You always update the software-based time, but if > > you restart, all temporary data is gone. (should) > > So your OS fetches at boot the time from the bios. > > If you update your time within the qubes-os, you should update your > > hardware clock (hc) as well: sudo hwclock --systohc > > If your time resets when you unplug your device from power supply, your > > device's battery is flat. > > -- > I did some analysis this morning. So at the same point in time the following > settings on my Qubes laptop showed the following values. (Bottom line is > that whonix/tor does not work) > > 1. The hardware BIOS clock is: 1030 (BIOS battery good, removed laptop > battery for few hours and date/time stayed same) > > 2. Dom0 time is: 0530 ( via date command) > > 3. service:sys-whonix is: 1030 (via date command) > > 4. Clock on upper right of screen is: 0430 > > Tor Boostrap info is: > > Whonixcheck gave up waiting > clock skew -21635 in directory from DIRSERV > > sudo date --set “2018 -02-18 17:30:00” > > - > I think that on a normal bootup the clocks should be in sync and Whonix/Tor > should work. bios time differs a lot from dom0 and dom0 time seems in the UTC (timezone), while the clock on your desktop should be therefore in the -1 hour timezone. There is already something wrong, isn't it? Could you please set the correct time in dom0 and do a 'sudo hwclock --systohw' to get dom0's sys date and bios time in sync. And reboot pls. After reboot check the time in bios, dom0 and your clockVM (probably sys-net) before connecting to any network. In System Tools -> Qubes Global Settings in dom0 you can check the name of the clock VM. The time of your whonix should, as far as I know, differs in timezone as qubes built-in rule randomly each bootup of the VM. (Do not know for sure) I either do not know whether sys-whonix only changes the timezone and if it is an attack surface if someone from the outside could simulate/fake specific minutes and seconds your network-time-daemon adapt and your whonix could be associated to your isp. Even there seems to be some misconfiguration I never got, the behavior remembers me to an empty hardware battery. -- 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/1f50c1eb-5097-4605-8cb5-b6525d3bd2e3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: QUBES 4 r4 - dom0 UTC time is incorrect - manual change each reboot.
On Tuesday, February 13, 2018 at 10:51:12 PM UTC+1, QUBE-A-LICIOUS wrote: > Hi there, > > I have a fresh install of Qubes 4r4. However, when I reboot and or login I > have to manually change dom0 time to UTC. > > Impact: Whonix/Tor does not work because of the incorrect time. > > Manual workaround: > 1. Get the correct UTC from a browser. > 2. Open Dom0 Terminal and update to UTC such as the following: > > sudo date --set "2018-02-13 21:30" > > 3. Shutdown Service:sys-whonix > 4. Restart a whonix domain such as Domain:anon-whonix(this restarts the > sys-whonix service that was just shutdown. > 5. Then run WhonixCheck to make sure it works. It usually does and > Whonix/Tor is functional. > > = > Qubes cannot be this bad, really. > > How can I have this Date and time correctly updated on boot up? Like it > should. > > Thanks for all your help. > NSJ Most times it is easy to point on another guilty one instead looking what may happen with the own stuff. So far you are the only one with this misbehavior. Qubes works as expected - at least in this point. But most user already experienced this behavior; qubes-os or any other distribution. The keyword is hwclock. You always update the software-based time, but if you restart, all temporary data is gone. (should) So your OS fetches at boot the time from the bios. If you update your time within the qubes-os, you should update your hardware clock (hc) as well: sudo hwclock --systohc If your time resets when you unplug your device from power supply, your device's battery is flat. -- 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/1565cfbf-9a13-4807-a794-ec48f59ed7b2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
