[qubes-users] Re: dom0 update got stuck - now QOS daemon does not start
Le mercredi 5 juin 2019 10:00:36 UTC+2, qubes666 a écrit : > Hi, > need really help. Yesterday i started on my Thinkpad dom0 update through the > terminal command. During verification process the program got stuck. I > powered off. Now, the boot process seems to stop after the login. > > Qubes manager, other programs and all VM do no start. (sudo journalctl). > > qubes-prefs output state: error: failed to connect to qubesd service Errno2 > no such file or directory > > new sudo qubes-dom0-update state the same error message. > > Any help is appreciated. I had the same problem. I did a "sudo dnf reinstall qubes-core-dom0" -- 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/ff4bac1d-29d5-41d3-8d65-88c05ea5ab2a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] USB webcam forwarding
Le mercredi 31 octobre 2018 13:26:25 UTC+1, awokd a écrit : > Bertrand Lec wrote on 10/31/18 11:55 AM: > > Le mercredi 31 octobre 2018 12:35:27 UTC+1, awokd a écrit : > >> tfm853 via qubes-users wrote on 10/30/18 8:30 PM: > >>> I'm trying to use a C920 USB camera on a Thinkpad X1 Carbon 6gen, latest > >>> Qubes4. The VM is running debian-9, but i also tried fedora-26. I tried > >>> both connecting the camera directly to a USB port of the Thinkpad and via > >>> a powered USB hub. > >> > >>> > >>> Qubes shows the device as still being attached to the VM. I can detach > >>> and reattach without problems. > >>> > >>> Forwarding the Thinkpad's internal camera works fine. > >>> > >>> Are failures with particular USB devices to be expected? Does anyone know > >>> a good external webcam that works? > >>> > >> > >> Yes, some devices don't work well through redirect. If you have a spare > >> USB controller (not in use for your mouse & keyboard) you can assign it > >> directly to the VM and then connect the webcam, but you lose isolation > >> between that controller and the VM. > > > > Do you have an idea of _why_ some devices do not work well though redirect? > > I have the same problem with a network interface from a docking station. > > My guess is only some USB commands are making it through and devices > that use more obscure ones run into problems. I'm no developer, though. > Webcams in particular have been an issue for a while: > > https://github.com/QubesOS/qubes-issues/issues/2594 > https://github.com/QubesOS/qubes-issues/issues/4035 > > Didn't list them all. Does your docking station NIC show up as a USB > device? If not, it's a different issue. Yes, it's a USB device, managed by sys-net. Bertrand -- 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/9cdf933e-ae01-4508-b257-fb62339ab7ce%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] USB webcam forwarding
Le mercredi 31 octobre 2018 12:35:27 UTC+1, awokd a écrit : > tfm853 via qubes-users wrote on 10/30/18 8:30 PM: > > I'm trying to use a C920 USB camera on a Thinkpad X1 Carbon 6gen, latest > > Qubes4. The VM is running debian-9, but i also tried fedora-26. I tried > > both connecting the camera directly to a USB port of the Thinkpad and via a > > powered USB hub. > > > > > Qubes shows the device as still being attached to the VM. I can detach and > > reattach without problems. > > > > Forwarding the Thinkpad's internal camera works fine. > > > > Are failures with particular USB devices to be expected? Does anyone know a > > good external webcam that works? > > > > Yes, some devices don't work well through redirect. If you have a spare > USB controller (not in use for your mouse & keyboard) you can assign it > directly to the VM and then connect the webcam, but you lose isolation > between that controller and the VM. Do you have an idea of _why_ some devices do not work well though redirect? I have the same problem with a network interface from a docking station. Thanks, Bertrand -- 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/8dc65961-c34e-4dbf-b72a-affb3c7381c8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Losing graphical luks passphrase entry screen after kernel-latest installation
Le lundi 27 août 2018 00:26:43 UTC+2, awokd a écrit : > On Sun, August 26, 2018 7:53 pm, Bertrand Lec wrote: > > Hello, > > > > > > I wanted to install the latest available kernel to check if there is any > > improvement on the suspend/resume topic and the network through USB3 > > docking station (no improvement on both topics). It's a Lenovo T580. > > > > I did install them by issuing the commands from dom0: > > > > > > sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing > > kernel-latest > > > > and > > > > sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing > > kernel-latest-qubes-vm > > > > After the needed reboot, I don't have anymore the graphical screen to > > enter the LUKS passphrase. Instead, I have a textual prompt. I can > > successfully at this stage enter my passphrase (and the keymap is > > correct, i.e. not an English one). > > > > What can i do ? > > Is the only problem it's showing in text mode instead of graphical? If so, > just ignore it and hope the next update fixes it! Yes, as far as I know, it's the only problem. I agree that it is possible to continue using my Qubes system, but it is not intellectually satisfactory to not know why :) Thanks, Bertrand -- 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/fa581e40-8283-4d2b-8dac-a017531dfa97%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Losing graphical luks passphrase entry screen after kernel-latest installation
Hello, I wanted to install the latest available kernel to check if there is any improvement on the suspend/resume topic and the network through USB3 docking station (no improvement on both topics). It's a Lenovo T580. I did install them by issuing the commands from dom0: sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing kernel-latest and sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing kernel-latest-qubes-vm After the needed reboot, I don't have anymore the graphical screen to enter the LUKS passphrase. Instead, I have a textual prompt. I can successfully at this stage enter my passphrase (and the keymap is correct, i.e. not an English one). What can i do ? Thanks Bertrand -- 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/71ebc5e7-5558-45a8-b9e8-7ecf4dff97a4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Launching KDE applications in VM
Hello, I am using the artful template. I installed kubuntu-deskptop package to get all needed packages. This looks to work correctly. When I launch a KDE applications, it runs without displaying any icons. I have found that if I start the KDE application from a shell, then I can add the env variables "export KDE_SESSION_VERSION=5" and "export KDE_FULL_SESSION=true" and it works better. Do you know how I could set those env variable for every launched application from the XFCS dom0 start menu? Thanks, Bertrand -- 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/fd0ef8a4-f41a-4eeb-bcfc-bbf0ca78f588%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Ubuntu templates
Le jeudi 1 février 2018 00:56:29 UTC+1, Unman a écrit : > I'm just pushing up some PRs to remove zesty and institute build support > for artful (17.10). > If you cant wait there's a ready built 3.2 template you can try at: > http://qubes.3isec.org/Templates > > unman Thank you a lot for your work. Do you know which qvm-* tools to install? The ones in http://qubes.3isec.org/3.2/ are not for artful and the Release file is missing. Can I use the debian ones? Thanks a lot Bertrand -- 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/bb5f4d81-4519-4486-995b-1b37e49948b0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: No more boot after update
Le dimanche 14 janvier 2018 14:36:06 UTC+1, erikmunk...@gmail.com a écrit : > Den søndag den 14. januar 2018 kl. 12.55.00 UTC+1 skrev awokd: > > On Sun, January 14, 2018 11:19 am, erikmunk...@gmail.com wrote: > > > Den lørdag den 13. januar 2018 kl. 19.37.57 UTC+1 skrev Bertrand Lec: > > > > >> From my understanding, it says that Qubes is the first one to be booted > > >> but the currently booted is ubuntu (which is true :) ) > > >> > > >> Do you have any idea for me? > > > > > > > If this is indeed triggered by a too small EFI partition size, then we > > > need to make it bigger next time to avoid it happening again. Though, > > > this is not enough to recover now that it already happened. I'm still > > > pondering about a possible solution. > > > > Not sure if you two are having the same issue but I've run into what > > Erik's describing before. I luckily caught it before rebooting, but it may > > also work from rescue mode. I manually deleted older versions of initramfs > > etc. in /boot/efi/EFI/qubes to free up space leaving just the single most > > recent, and was able to rebuild the new Qubes EFI boot image with: > > /usr/bin/dracut -f > > /boot/efi/EFI/qubes/initramfs-4.4.31-11.pvops.qubes.x86_64.img > > 4.4.31-11.pvops.qubes.x86_64 > > Replace the file names with the correct versions for your updated kernel. > > Amazing, your approah worked smoothly! > Also I can confirm it works just fine in recovery mode too. > > Although I had to make some small minor modifications due to my slight > different situation, since seemingly I did not have the new > initramfs-4.14.13-1.pvops.qubes.x86_64 and only my old one > initramfs-4.9.56-21.pvops.qubes.x86_64 > I'm not too sure why it didn't work for the new kernel, whether or not it was > due to the missing initramfs or not, but either way, it was probably just > that, lack of diskspace on the partition. > > I did not just delete the old initramfs in the reocvery mode, since guessing > it might leave worse off not having a single one available. So to be sure not > to mess up, I could either make a copy elsewhere for backup before deleting > the last initramfs, or try restore my old kernel. > > So I resorted to trying re-establish my old kernel using your method, and it > worked. I'll explain what I did below in details in case others need it too. > I used your post as a guideline to make these modifcations. > > I booted my system normally using the old kernel after the above fix, and > proceeded to "sudo dnf remove kernel-4.14.13-1.pvops.qubes.x86_64" to get rid > of the new broken kernel. > > I then made a backup copy of my EFI folder to my home folder (In case I > needed it again), and then followed up to delete the old 21MB'ish or so in > size initramfs for my old and current running kernel system. > > I then proceeded with updating again, installing the new kernel. This time it > installed cleanly. I then checked the EFI folder if the new kernel and new > initramfs was there, and the xen.cfg file also correctly pointed to the > kernel and initramfs without the need for edits. > > Then rebooted, and now it works flawlessly with the new kernel update. > > Thanks a lot awokd! > > @Bertrand Lec, did you get yours working? So, a little summary: - I have plenty of room in my EFI partition. - I was not installing from testing, just from normal repository, so my kenerl was 4.9.56 - I tried the dracut command, without success However, I did a new fresh install of R3.2 but this time, to do the dom0 update, I chose to use testing repository (--enablerepo=qubes-dom0-current-testing), and it works now fine ! What worries me the most is that I don't understand what happened (and that I am afraid of doing a new update of dom0, as it is requesting it). Thank you all, Bertrand -- 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/65178161-f4c4-4dd6-a1fc-87238db32d00%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: No more boot after update
Le samedi 13 janvier 2018 20:10:39 UTC+1, Bertrand Lec a écrit : > Le samedi 13 janvier 2018 19:44:54 UTC+1, cooloutac a écrit : > > On Saturday, January 13, 2018 at 1:37:57 PM UTC-5, Bertrand Lec wrote: > > > Hello, > > > > > > I'm fresh installing Qubes R3.2 on my desktop PC, aside from Ubuntu. > > > The PC is configured with UEFI. > > > > > > The installation goes well. At that time, I can reboot directly to Qubes. > > > > > > However, after I update dom0, Qubes refuse to reboot. The boot is done to > > > Ubuntu. Even when I choose to boot Qubes in the BIOS, Ubuntu will boot. > > > > > > Result of efibootmgr command is: > > > BootCurrent: > > > Timeout: 1 seconds > > > BootOrder: 0002,,0005,0001,0007 > > > Boot* ubuntu > > > Boot0001* Hard Drive > > > Boot0002* Qubes > > > Boot0005* CD/DVD Drive > > > Boot0007* Removable Drive > > > > > > From my understanding, it says that Qubes is the first one to be booted > > > but the currently booted is ubuntu (which is true :) ) > > > > > > Do you have any idea for me? > > > > > > Thanks > > > Bertrand > > > > you have to add qubes to the ubuntu grub. > > With the way the BIOS is configured, it should only boot Qubes, and it's what > it did with several reboots done before the dom0 upgrade. > > By the way, I have just seen that there is no *cfg file in Qubes' /boot. Is > it normal...? > > However, if a modification of Ubuntu's grub could be the solution, I'll take > it, but I don't see what I could put there. > > Bertrand Some additional information: When the system boots, I can see those three lines at the top of the black screen: - Xen 4.6.6 (c/s ) EFI loader Using configuration file 'xen.cfg' vmlinuz-4.9.56-21.pvops.qubes.x86_64: 0x0-0x000... - The hexa numbers at the end of the last line were long and it was not really possible to read them. Just a few milisecond after this is displayed, either the system gets back to the BIOS or boots Ubuntu, depending on how I was booting. Hope this will give you some ideas... Bertrand -- 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/a63b0b17-fd2e-47b1-8cc5-9d6c55223246%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: No more boot after update
Le samedi 13 janvier 2018 20:10:39 UTC+1, Bertrand Lec a écrit : > Le samedi 13 janvier 2018 19:44:54 UTC+1, cooloutac a écrit : > > On Saturday, January 13, 2018 at 1:37:57 PM UTC-5, Bertrand Lec wrote: > > > Hello, > > > > > > I'm fresh installing Qubes R3.2 on my desktop PC, aside from Ubuntu. > > > The PC is configured with UEFI. > > > > > > The installation goes well. At that time, I can reboot directly to Qubes. > > > > > > However, after I update dom0, Qubes refuse to reboot. The boot is done to > > > Ubuntu. Even when I choose to boot Qubes in the BIOS, Ubuntu will boot. > > > > > > Result of efibootmgr command is: > > > BootCurrent: > > > Timeout: 1 seconds > > > BootOrder: 0002,,0005,0001,0007 > > > Boot* ubuntu > > > Boot0001* Hard Drive > > > Boot0002* Qubes > > > Boot0005* CD/DVD Drive > > > Boot0007* Removable Drive > > > > > > From my understanding, it says that Qubes is the first one to be booted > > > but the currently booted is ubuntu (which is true :) ) > > > > > > Do you have any idea for me? > > > > > > Thanks > > > Bertrand > > > > you have to add qubes to the ubuntu grub. > > With the way the BIOS is configured, it should only boot Qubes, and it's what > it did with several reboots done before the dom0 upgrade. > > By the way, I have just seen that there is no *cfg file in Qubes' /boot. Is > it normal...? > > However, if a modification of Ubuntu's grub could be the solution, I'll take > it, but I don't see what I could put there. > > Bertrand Some additional information: When the system tries to boot, I can see 3 lines written at the top of the black screen: -- 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/e77c11a8-a7bb-4bc4-a25b-cf81aa985c3f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: No more boot after update
Le samedi 13 janvier 2018 19:44:54 UTC+1, cooloutac a écrit : > On Saturday, January 13, 2018 at 1:37:57 PM UTC-5, Bertrand Lec wrote: > > Hello, > > > > I'm fresh installing Qubes R3.2 on my desktop PC, aside from Ubuntu. > > The PC is configured with UEFI. > > > > The installation goes well. At that time, I can reboot directly to Qubes. > > > > However, after I update dom0, Qubes refuse to reboot. The boot is done to > > Ubuntu. Even when I choose to boot Qubes in the BIOS, Ubuntu will boot. > > > > Result of efibootmgr command is: > > BootCurrent: > > Timeout: 1 seconds > > BootOrder: 0002,,0005,0001,0007 > > Boot* ubuntu > > Boot0001* Hard Drive > > Boot0002* Qubes > > Boot0005* CD/DVD Drive > > Boot0007* Removable Drive > > > > From my understanding, it says that Qubes is the first one to be booted but > > the currently booted is ubuntu (which is true :) ) > > > > Do you have any idea for me? > > > > Thanks > > Bertrand > > you have to add qubes to the ubuntu grub. With the way the BIOS is configured, it should only boot Qubes, and it's what it did with several reboots done before the dom0 upgrade. By the way, I have just seen that there is no *cfg file in Qubes' /boot. Is it normal...? However, if a modification of Ubuntu's grub could be the solution, I'll take it, but I don't see what I could put there. Bertrand -- 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/5f3d54f5-4c5f-4e4d-ace8-78da77445011%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] No more boot after update
Hello, I'm fresh installing Qubes R3.2 on my desktop PC, aside from Ubuntu. The PC is configured with UEFI. The installation goes well. At that time, I can reboot directly to Qubes. However, after I update dom0, Qubes refuse to reboot. The boot is done to Ubuntu. Even when I choose to boot Qubes in the BIOS, Ubuntu will boot. Result of efibootmgr command is: BootCurrent: Timeout: 1 seconds BootOrder: 0002,,0005,0001,0007 Boot* ubuntu Boot0001* Hard Drive Boot0002* Qubes Boot0005* CD/DVD Drive Boot0007* Removable Drive >From my understanding, it says that Qubes is the first one to be booted but >the currently booted is ubuntu (which is true :) ) Do you have any idea for me? Thanks Bertrand -- 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/db4ea5cb-6cba-4e5a-b285-62b7bdc5fb07%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
