Re: [qubes-users] Dracut and a detached LUKS header
On Tuesday, August 21, 2018 at 12:31:26 PM UTC+1, Unman wrote: > On Tue, Aug 21, 2018 at 02:23:56AM -0700, tierl...@gmail.com wrote: > > Is this possible? Can dracut be configured to decrypt a LUKS volume with a > > detached header? > > > > I think that dracut generally wants to have a UUID, and with a detached > header you won't have one. You could use the serial number. > You'll also need to add a udev attribute for crypto_LUKS, I think. > I recall reading someone who did have dracut working in this setup, but > it needed some changes to the crypt module. > You could always specify the header file and key file in the kernel > command line using cryptdevice and cryptkey options. --> "You could always specify the header file and key file in the kernel command line using cryptdevice and cryptkey options." Interesting, what would that look like? Something like this? (lifted from Gentoo forums): root=/dev/ram0 real_root=/dev/mapper/vg-root cryptdevice=/dev/sda4:crypt But doesn't that just specify the LUKS volume? How can explicitly specify the location of the header file? Is it possible to build a custom initramfs with mkinitcpio (or another) without having to recompile the kernel? I'm assuming yes. -- 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/16899c5a-0dd9-4a59-a651-d646ca398cb2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Dracut and a detached LUKS header
Is this possible? Can dracut be configured to decrypt a LUKS volume with a detached header? -- 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/07646dfa-30bd-426d-87c7-6adaa212962a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Shredding VM images
What's the most convenient way to wipe these images? (I'm just talking about
individual VM images)
I'm on Qubes 4.0, and I understand it's not that simple on SSDs, but whats the
situation?
I see that /dev/mapper has a number of links to ../dm devices, these are
encrypted, right? Where is the key stored? How is that stored on disk, and is
it likely to leave fragments all over the drive?
Can a `shred -vzn 7` be done on these devices? Does it effectively erase the
data?
I see that within /dev/mapper there's foo--private, foo--private--{0-9}+--back,
and foo--private--snap. What's the difference between these? How are they
created and used?
Am I right in thinking that only the private images hold VM specific states?
What about foo--volatile?
--
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/7a6ab861-a76d-4791-b8ff-c7851ce55b66%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: qvm-run, hangs and stacktrace.
On Tuesday, August 14, 2018 at 4:36:29 PM UTC+1, Pablo Di Noto wrote: > Kudos to the `qvm-volume revert` feature! > > I just did > ``` > qvm-volume info debian-9-root > qvm-volume revert debian-9-root XX-back > ``` > and went back to the pre-update template and the issue disappeared. > > Later today will try to see what happened by updating a clone of the template > (as I should have done in the first place) Not an option for me. I shall file a bug report. -- 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/f79af9e9-457b-4693-8f11-cc3309136449%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: New CPU Bug Found
On Tuesday, August 14, 2018 at 12:44:18 AM UTC+1, jonbrown...@gmail.com wrote: > New CPU backdoor has been found with code available here: > https://github.com/xoreaxeaxeax/rosenbridge > > Anyone mind checking if Thinkpad 230 is affected? It is thought that only VIA C3 CPUs are affected by this issue. The C-series processors are marketed towards industrial automation, point-of-sale, ATM, and healthcare hardware, as well as a variety of consumer desktop and laptop computers. Thinkpads are Intel. But don't think for a second a 0-day for Intel/AMD doesn't exist, and isn't actively being exploited. Security is broken. -- 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/1509d366-69ec-4c62-8798-8a330c7c1e06%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] qvm-run, hangs and stacktrace.
Has anyone else experienced this? The application is launched, but it doesn't return correctly. I have to ctrl+c to improperly exit qvm-run, and it prints a stack trace: Traceback (most recent call last): File "/usr/bin/qvm-run", line 5, in sys.exit(main()) File "/usr/lib/python3.5/site-packages/qubesadmin/tools/qvm_run.py", line 235, in main retcode = max(retcode, proc.wait()) File "/usr/lib64/python3.5/subprocess.py", line 1399, in wait (pid, sts) = self._try_wait(0) File "/usr/lib64/python3.5/subprocess.py", line 1349, in _try_wait (pid, sts) = os.waitpid(self.pid, wait_flags) The same happens with --noguid or --no-guid -- 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/c253c432-c9e2-402b-ad3f-0024ab661c1c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] No sound after template upgrade to Fedora 27/28
On Monday, August 6, 2018 at 1:38:43 PM UTC+1, Unman wrote: > On Sun, Aug 05, 2018 at 09:58:55PM -0700, tierl...@gmail.com wrote: > > I'm new to Fedora, forgive my stupidity but I upgraded from 26 -> 27 -> 28, > > instead of 26 -> 28. Anyway, After upgrading from 26 -> 27 sound stopped > > working, and is still not working on 28. > > > > In Dom0 pavucontrol:playback shows only one VM (sound works) - which is > > still running 26. So it's not necessarily a dom0 thing, and appears to > > relate to the upgrade. Pulse audio is also definitely installed in the > > templates, although pactl and paplay have their "connection refused" - > > which is about the limit of my knowledge with pulseaudio - and I cannot > > diagnose the issue any further. > > > > I have no special sound configuration, and very little custom > > configurations in /etc (almost none), so it's a pretty vanilla install - > > except a few packages. The install is actually only a few days old. > > > > I'm not really sure what the Qubes sound architecture looks like, or how to > > fix my issue. Pulseaudio is also my (idiomatic) Achilles heel - so I'm here > > asking for some guidance. > > > > Thanks! > > > > It's a known problem and there's an open issue for it. > The problem is that fedora have been updating the pulseaudio stable > version, and the Qubes updates to match are working their way in to > Qubes stable. > You may be able to resolve by using packages from the Qubes testing > repository. I don't use Fedora so cant vouch for this. > Have a look at > www.qubes-os.org/doc/software-update-vm/#testing-repositories > > unman Thanks. Can you share the ticket please? -- 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/4cfc0a95-5c47-4f66-84f0-05af91dbe1dd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] No sound after template upgrade to Fedora 27/28
I'm new to Fedora, forgive my stupidity but I upgraded from 26 -> 27 -> 28, instead of 26 -> 28. Anyway, After upgrading from 26 -> 27 sound stopped working, and is still not working on 28. In Dom0 pavucontrol:playback shows only one VM (sound works) - which is still running 26. So it's not necessarily a dom0 thing, and appears to relate to the upgrade. Pulse audio is also definitely installed in the templates, although pactl and paplay have their "connection refused" - which is about the limit of my knowledge with pulseaudio - and I cannot diagnose the issue any further. I have no special sound configuration, and very little custom configurations in /etc (almost none), so it's a pretty vanilla install - except a few packages. The install is actually only a few days old. I'm not really sure what the Qubes sound architecture looks like, or how to fix my issue. Pulseaudio is also my (idiomatic) Achilles heel - so I'm here asking for some guidance. Thanks! -- 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/1377293a-b591-409c-8139-c8ca0f107c7d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
