[qubes-users] cannot get locally built xen packages to install in dom0

[Jake]

hi list,

i made some modifications to the vmm-xen component of qubes and am 
having difficulty testing the built packages.


i have copied the packages to dom0, but attempts to dnf update with the 
newly built packages, e.g. xen-libs give the error


"problem: the operation would result in removing the following protected 
packages: qubes-core-dom0"


i would appreciate it if someone can tell me how to go about updating 
these packages so i can test them.


regards,

jake

--
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/d96ea9fe-f746-0594-39a2-1aec3de29427%40companyzero.com.

[qubes-users] laptop Intel HD Graphics heatsink fan: SOLVED

[Jake]

hello list,

i was trying to get qubes to work on a new laptop with an intel hd 
graphics gpu and observed the following behavior i had never encountered 
previously:


- install succeeded, but once i started running several appvms and 
restoring from a backup the heatsink fan was blowing a lot of hot air. 
neither dom0 nor the appvms were using any cpu (all at 0% or close), so 
i inferred that the heat was coming from the gpu.


after attempting several fixes, e.g. updating dom0 to use the 5.6 kernel 
and setting several kernel options, i did the following:


- in dom0 do 'journalctl | grep drm | less' and see a log '[drm] 
Reducing the compressed framebuffer size. This may lead to less power 
saving than a non-reduced size. Try to increase stolen memory size if 
available in BIOS.'


i rebooted the machine, went into the bios, and adjusted the memory for 
the integrated gpu upwards from its default setting. now the machine is 
working as expected - no unusual heatsink activity.


just in case adjusting the memory used by the gpu in the laptop bios 
doesn't work by itself (i haven't tested this), the following may be useful:


- in dom0 'sudo qubes-dom0-update kernel-latest' to install the latest 
stable 5.x kernel. you can also use --enablerepo=qubes-dom0-unstable


- [assumes uefi boot] in dom0 edit /boot/efi/EFI/qubes/xen.cfg kernel 
options to add i915.enable_fbc=0 and i915.enable_psr=0 to disable 
framebuffer compression and panel self refresh


i hope this can help someone else and save them some time that i lost.

regards

jake

--
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/27ab2788-cdf9-2a41-b2eb-e56d0f8e5562%40companyzero.com.

Re: [qubes-users] Re: Boot Failure: Dell Latitdue 5491

[Jake Knobloch]

I have tried the troubleshooting steps "Installation finished but

“Qubes”
boot option is missing and xen.cfg is empty" but I get the error when
trying to create efi boot entry "EFI variables are not support on this
system."  Seems it's safe to assume this is yet another unsupported
laptop.  I've yet to run Qubes on hardware that's less than 5 years old.


On Thursday, August 8, 2019 at 2:26:52 PM UTC-5,
jake-...@uptimecomputing.com wrote:

I have been trying to get Qubes installed again and have not been
successful.  First I tried on a Precision 5530 but nvidia can't be
disabled
and nothing seemed to be working right.  I purchased a Dell Latitude
5491
specifically for Qubes and seem to be having all the same problems.
I'm
able to enable legacy boot mode and run through the installer that
way, but
then I get a drive that has no bootable partition.  I'm not finding
anything in the documentation other than run the installer and go from
there.  Are there any special steps that need to be performed to get a
recent model laptop to boot Qubes after installing in legacy boot mode?


If you're doing a legacy boot, EFI is effectively turned off so you
won't see a xen.cfg etc. You might need to add the hard drive in your
BIOS settings boot order in legacy mode, even if it's already in there
in UEFI mode. Also, what happened when you first tried to install Qubes
in EFI (non-legacy) mode?

Thank you for the suggestions.  First, the installer would not finish
booting in EFI mode.  With EFI and secure boot turned on, I get the
message saying "Operating System Loader failed signature verification."
With mode EFI and secure boot off I see 4 lines of output, something
about xen, something about bootx64.cfg, then vmlinuz, and last line is
initrd.  After that the screen goes blank and ctrl-alt-del does not
work, box is locked up.  One press of the power button and it shuts
right off.

I have looked in the bios and I am not able to add the hard drive to
legacy boot mode.  The Dell Latitude 5491 bios has the message saying
"Legacy External Devices boot mode does not support OS boot on internal
storage[...]"



Try the steps in this section:
https://www.qubes-os.org/doc/uefi-troubleshooting/#installation-freezes-before-getting-to-anaconda-qubes-40,
then attempt a reinstall in UEFI mode. Adding that nouveau.modeset=0
line could also permit your install image to work on the 5530. If you
still have no joy getting it installed on the 5491, try the section
after about disabling runtime services. That's really a last resort
though, because it makes every Xen update a pain.

Success on the Latitude!  Thanks for the suggestion.  I was able to 
install and configure Qubes using the above troubleshooting.


I did try the nouveau setting on the Precision 5530 just now, along with 
the other 2 settings.  Same result, I see the 4 lines of output, plus 2 
more that look like memory addresses, then blank screen for about 10 
seconds, then it reboots.  I no longer need to run Qubes on the 
Precision, but am happy to try further testing if there are any suggestions.


--
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/15fae82b-1e29-dc40-c640-1273d72c3864%40uptimecomputing.com.

Re: [qubes-users] Re: Boot Failure: Dell Latitdue 5491

[Jake Knobloch]

jake-goo...@uptimecomputing.com:

I have tried the troubleshooting steps "Installation finished but “Qubes”
boot option is missing and xen.cfg is empty" but I get the error when
trying to create efi boot entry "EFI variables are not support on this
system."  Seems it's safe to assume this is yet another unsupported
laptop.  I've yet to run Qubes on hardware that's less than 5 years old.


On Thursday, August 8, 2019 at 2:26:52 PM UTC-5,
jake-...@uptimecomputing.com wrote:

I have been trying to get Qubes installed again and have not been
successful.  First I tried on a Precision 5530 but nvidia can't be disabled
and nothing seemed to be working right.  I purchased a Dell Latitude 5491
specifically for Qubes and seem to be having all the same problems.  I'm
able to enable legacy boot mode and run through the installer that way, but
then I get a drive that has no bootable partition.  I'm not finding
anything in the documentation other than run the installer and go from
there.  Are there any special steps that need to be performed to get a
recent model laptop to boot Qubes after installing in legacy boot mode?


If you're doing a legacy boot, EFI is effectively turned off so you
won't see a xen.cfg etc. You might need to add the hard drive in your
BIOS settings boot order in legacy mode, even if it's already in there
in UEFI mode. Also, what happened when you first tried to install Qubes
in EFI (non-legacy) mode?


Thank you for the suggestions.  First, the installer would not finish 
booting in EFI mode.  With EFI and secure boot turned on, I get the 
message saying "Operating System Loader failed signature verification."  
With mode EFI and secure boot off I see 4 lines of output, something 
about xen, something about bootx64.cfg, then vmlinuz, and last line is 
initrd.  After that the screen goes blank and ctrl-alt-del does not 
work, box is locked up.  One press of the power button and it shuts 
right off.


I have looked in the bios and I am not able to add the hard drive to 
legacy boot mode.  The Dell Latitude 5491 bios has the message saying 
"Legacy External Devices boot mode does not support OS boot on internal 
storage[...]"



--
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/44ae12d7-7ba2-33f5-6725-812c1e036a43%40uptimecomputing.com.

[qubes-users] Re: Boot Failure: Dell Latitdue 5491

[jake-google]

I have tried the troubleshooting steps "Installation finished but “Qubes” 
boot option is missing and xen.cfg is empty" but I get the error when 
trying to create efi boot entry "EFI variables are not support on this 
system."  Seems it's safe to assume this is yet another unsupported 
laptop.  I've yet to run Qubes on hardware that's less than 5 years old.


On Thursday, August 8, 2019 at 2:26:52 PM UTC-5, 
jake-...@uptimecomputing.com wrote:
>
> I have been trying to get Qubes installed again and have not been 
> successful.  First I tried on a Precision 5530 but nvidia can't be disabled 
> and nothing seemed to be working right.  I purchased a Dell Latitude 5491 
> specifically for Qubes and seem to be having all the same problems.  I'm 
> able to enable legacy boot mode and run through the installer that way, but 
> then I get a drive that has no bootable partition.  I'm not finding 
> anything in the documentation other than run the installer and go from 
> there.  Are there any special steps that need to be performed to get a 
> recent model laptop to boot Qubes after installing in legacy boot mode?
>

-- 
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/1ff8b938-49cf-481b-a881-e4a73e49affd%40googlegroups.com.

[qubes-users] Boot Failure: Dell Latitdue 5491

[jake-google]

I have been trying to get Qubes installed again and have not been 
successful.  First I tried on a Precision 5530 but nvidia can't be disabled 
and nothing seemed to be working right.  I purchased a Dell Latitude 5491 
specifically for Qubes and seem to be having all the same problems.  I'm 
able to enable legacy boot mode and run through the installer that way, but 
then I get a drive that has no bootable partition.  I'm not finding 
anything in the documentation other than run the installer and go from 
there.  Are there any special steps that need to be performed to get a 
recent model laptop to boot Qubes after installing in legacy boot mode?

-- 
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/4b5f98bb-24a6-4962-b5ed-90df65538d48%40googlegroups.com.

Re: [qubes-users] Adding a repo: works in appvm/dispvm, not in template

[Jake]

On 12/16/18 9:05 AM, unman wrote:


On Sun, Dec 16, 2018 at 01:57:57AM -0600, Jake wrote:

I need to add an additional yum/dnf repo to install some software, but I
seem to only be able to do it on an appvm/dispvm, not on a template.

When adding the repo to the template, I cannot install packages after adding
it, and get the following message when attempting to install using dnf:

"Failed to synchronize cache for repo "

Can someone give me a clue about why this works for appvms and not a
template?

Regards,

Jake

appVMs are networked and templates use a proxy which they access by
qubes-rpc.(seewww.qubes-os.org/doc/software-update-vm#updates-proxy)

What's the repo you want to use, and what is the proxy you are
using? (Check in QubesGlobalSettings and 
/etc/qubes-rpc/policy/qubes.UpdatesProxy in dom0)



Apologies for the delayed response. The repo is a 3rd party repo for an 
external USB device, and giving my sys-usb vm network access to install 
these packages each time I need to use it strikes me as poor opsec.


What I have attempted to do is clone my fedora template, add the new 
repo to that template, and then install the relevant packages. The goal 
with this config is to avoid having to re-trust the remote repo and its 
packages each time I set this up.


I gave the docs you linked to and the config files a close look and 
don't immediately see how to debug this problem and get updates via this 
additional repo working via the proxy system.  My read is that the 
following is occurring when attempting to update/install packages in a 
templateVM:


attempt to install pkg in templateVM --> traffic flows to/from 
127.0.0.1:8082 in templateVM --> either sys-net or sys-whonix over 
qubes-rpc --> ?


I don't see any obvious logs that give useful info and it's not clear to 
me how to track the update process over the qubes-rpc link.  The best 
debug info I have on-hand is that "dnf install  -v" gives the 
error "Cannot download 'https://remoterepo.com/rpm': Cannot download 
repomd.xml: Cannot download repodata/repomd.xml: All mirror were 
tried".  I have verified that 
https://remoterepo.com/rpm/repodata/repomd.xml exists and packages 
install fine using a dispVM.  Are the repo IPs or domains being filtered 
via the update proxy?


Any advice on how to get this additional repo working via the update 
proxy mechanism would be welcome.


--
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/90c47ac6-8aab-4f23-3040-b86beb1a68b8%40companyzero.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Adding a repo: works in appvm/dispvm, not in template

[Jake]

I need to add an additional yum/dnf repo to install some software, but I 
seem to only be able to do it on an appvm/dispvm, not on a template.


When adding the repo to the template, I cannot install packages after 
adding it, and get the following message when attempting to install 
using dnf:


"Failed to synchronize cache for repo "

Can someone give me a clue about why this works for appvms and not a 
template?


Regards,

Jake

--
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/b9e2158a-708c-1fa0-4fac-afc6832a4310%40companyzero.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] migrating R3.1 appvm to R4.0 manually

[Jake]

Hello list,

i need to migrate a R3.1 appvm to R4.0 manually.  due to this appvm 
having overfilled the hard drive of a R3.1 installation, i had to 
migrate the contents of /var/lib/qubes/appvm/ to another 
drive.  i have verified {private,volatile}.img were copied without 
error, but i cannot get the appvm to show up under a new R4.0 
installation with these files manually copied to 
/var/lib/qubes/appvm/, in dom0.


can someone give me input on what i need to do to get this appvm to 
register/start on R4.0? i am confident there is a way to do this, but i 
do not know what is required.


regards,

jake

--
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/44736673-9b48-15a0-492b-b8f9abb07579%40companyzero.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: traveling - best practice

[Jake]

On 02/10/2017 05:02 AM, john.david.r.smith wrote:


On 10/02/17 11:53, '0xDEADBEEF00' via qubes-users wrote:

Interesting topic...

I would like to here more about how people handle this.

On my side, I'would never work on sensitive information in such a 
situation.
To make just some surfing in public place, my laptop is installed 
with a standard w10 that I use only to check a generic mailbox with 
on sensitive information, do some nonsensitive work and surf. By the 
way, the boot sequence of my laptop is set to boot this partition by 
default with no menu or prompt of any kind. If I want to boot into 
qubes, I have to do it manually by interupting the boot sequence.
This also serves as a decoy, if I'm forced to boot my laptop when 
passing borders or so.


Best,

0xdeadbeef


dual booting opens a whole new attack surface.
is there a way to deal with this?
the other os may not be able to read/modify qubes due to encryption, 
but it can write something malicious on the disk (e.g. some loader 
running before qubes)




while i can't deny the utility of a decoy, dual booting does indeed open 
a new attack surface, e.g. win10 gremlin rewrites the bootloader on your 
non-win10 partitions in a way that caches your disk passphrase somewhere 
win10 can access it next time it boots.


the best policy with windows is to never use it under any circumstances, 
provided you can manage it.


--
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/621ac601-b135-33f2-8e18-c455b9723e5f%40companyzero.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] traveling - best practice

[Jake]

  
  
On 02/07/2017 08:43 AM, Franz wrote:


  

  On Tue, Feb 7, 2017 at 10:09 AM,
haaber 
wrote:
Hello, 
  I wonder how you behave when traveling, for example in
  places
  with cameras all around. I feel uncomfortable to enter my
  passwords in
  such situations. Of course I can simply not turn my
  computer on.  But
  sometimes you have several hours in an airport ..  I
  thought about 3
  options.
  
  0) Change all (disk / user) pwd before & after
  traveling (how do I
  change the disk pwd?).
  
  1) Pull out my tails usbkey and surf with that?
  
  2) maybe it woud be nice to have an additional  "single
  cube"
  usr/password : when using this user name, one would get a
  single
  disposable untrusted VM,  no dom0 acces, no USB, and so
  forth. Is that
  feasable / reasonable?
  
  how do you cope with that? Thank you, Bernhard
  



But is the resolution of these cameras high and fast
  enough to be able to read the movements of my 10 fingers
  all working together and covering the whole keyboard?
  

I installed a high definition security ethernet camera
  in my home, but resolution and speed are not that
  spectacular.
  

There are mini-cameras that can be hidden, but
  resolution is worse.



So cameras can be easily identified and  I suppose it
  is enough to avoid sitting down  having a camera just over
  your shoulders.

  

  


i am a strong proponent of entirely removing both microphones and
cameras in all computing devices. even with a hardware switch, you
can't know it's actually disabled, whereas when you remove the mics
and cameras, you can be confident they are disabled.

this can be done to pretty much any laptop, but it may void your
warranty, so if you care about that kind of stuff, keep that in
mind. it typically takes 1-2 hours to disassemble and reassemble a
laptop when doing this.


  

  
Best

Fran


  --
  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+unsubscribe@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/8966eb59-45e3-e8d5-9ece-cae31d719f90%40web.de.
  For more options, visit https://groups.google.com/d/optout.

  
  

  
  -- 
  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/CAPzH-qAizi%2B%2BkUxeCpwiZvT%3DgvEFVPHaDhqDQGWb1AqC2FGjBQ%40mail.gmail.com.
  For more options, visit https://groups.google.com/d/optout.

  




-- 
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/2b4d8801-05d7-5c08-11e7-be6a896f507f%40companyzero.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Gaming on Qubes OS?

[Jake]

in a way, we're all gambling with operating systems :)

big money, no serious xen exploits!


On 01/05/2017 04:44 PM, stevenwinderl...@gmail.com wrote:

Is it actually possible to game on Linux like on Windows 7 and up or is there 
any special requirement neccessary for this?

And would passing through a GPU via devices tab in VM settings actually be 
enough?



--
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/51d50879-a03c-52fa-c3e5-34439e867fcf%40companyzero.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] botched 3.1 -> 3.2 upgrade: reset dom0 password

[Jake]

On 01/02/2017 08:51 PM, Unman wrote:


On Thu, Dec 29, 2016 at 02:52:12PM -0600, Jake wrote:

hello list,

i have taken a R3.1 system installed from the ISO and attempted to upgrade
it to R3.2 by following the instructions from the docs (
https://www.qubes-os.org/doc/upgrade-to-r3.2/ ), but i have encountered an
unusually irritating problem in the process: after getting to step 7 of the
dom0 upgrade, the machine was rebooted and i cannot log into dom0 using the
password that worked fine with R3.1. i am 100% certain that this is not a
PEBCAK error and that my previously working password for dom0 is no longer
working.

that said, this is typically an easy enough problem to fix on most *nix
systems: drop to single user mode during boot and reset the password for
root or whatever user. i have searched the qubes-users archives, found no
advice on how to do this and had no luck trying this myself. i have used the
install ISO to boot into "rescue mode", manually mounted the LUKS volume and
attempted to reset the password to no avail. it would appear that the passwd
installed in dom0 does not support the -R option, nor does passwd work
properly inside a chroot, e.g. mount / filesystem on /mnt, run 'chroot /mnt'
and run 'chroot '.

if there is a trick to interrupting the qubes boot process to drop into
single user mode, i would greatly appreciate someone sharing that
information. it seems the issue is that this must occur between unlocking
the LUKS volume and arriving at the password prompt for dom0.

regards,

jake


Hi Jake

Sorry to hear of your problem. I havent encountered this in a number of
upgrades.


unman,

thanks for the feedback on the upgrade process. i'll try to repro the 
issue on identical hardware.


the extra steps to make passwd work are appreciated, i'll give them a 
try if i can reproduce this failure.


regards,
jake


If you want to use a chroot, then you need to do something like this:
Mount the decrypted disk to /mnt
$ sudo mount ‐‐bind /dev /mnt/dev
$ sudo mount ‐‐bind /proc /mnt/proc
$ sudo mount ‐‐bind /sys /mnt/sys
Then chroot, and the passwd command should work within the chroot.

(If you've already tried this, apologies - it isnt clear from your
post.)

unman




--
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/d54b8fb2-7885-1326-3114-c22a2a70cf3d%40companyzero.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] botched 3.1 -> 3.2 upgrade: reset dom0 password

[Jake]

hello list,

i have taken a R3.1 system installed from the ISO and attempted to 
upgrade it to R3.2 by following the instructions from the docs ( 
https://www.qubes-os.org/doc/upgrade-to-r3.2/ ), but i have encountered 
an unusually irritating problem in the process: after getting to step 7 
of the dom0 upgrade, the machine was rebooted and i cannot log into dom0 
using the password that worked fine with R3.1. i am 100% certain that 
this is not a PEBCAK error and that my previously working password for 
dom0 is no longer working.


that said, this is typically an easy enough problem to fix on most *nix 
systems: drop to single user mode during boot and reset the password for 
root or whatever user. i have searched the qubes-users archives, found 
no advice on how to do this and had no luck trying this myself. i have 
used the install ISO to boot into "rescue mode", manually mounted the 
LUKS volume and attempted to reset the password to no avail. it would 
appear that the passwd installed in dom0 does not support the -R option, 
nor does passwd work properly inside a chroot, e.g. mount / filesystem 
on /mnt, run 'chroot /mnt' and run 'chroot '.


if there is a trick to interrupting the qubes boot process to drop into 
single user mode, i would greatly appreciate someone sharing that 
information. it seems the issue is that this must occur between 
unlocking the LUKS volume and arriving at the password prompt for dom0.


regards,

jake

--
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/b589499b-4df9-adbe-4da4-caa7cca5eb08%40companyzero.com.
For more options, visit https://groups.google.com/d/optout.