Something that I sometimes find helpful when making risky changes is to open a disposable VM and try the changes there so that if anything goes wrong my template is still safe. This doesn’t work well for every change, especially if I need to test that the change actually propagates to AppVMs based on the template (I’ve made the mistake of using /usr/local in a template before 
), but it can save a lot of headaches when appropriate.
1 Like
Right now I am for example putting off the LUKS full disk encryption password reset because even the vendor of the laptop warns if I mess up I will have to reinstall QubesOS
eeek
But I will be doing that soon … today or tomorrow. In fact I am making other edits first, in sheer procrastination since I am scared ha … today or tomorrow yup have to eventually before putting it online
But then I saw on the GUI Desktop bar in “systems settings” drop down menu
“Change Disk Password”
Is this the same thing???
If I can do it this way in the GUI it doesn’t seem as scary compared to the 8 key slot direction stuff I was sent in email
I have not used it, but it looks like it just changes the disk password. I definitely wouldn’t depend on it to disable some kind of reset method implemented by the producer of the laptop…
1 Like
Good point
I guess I have to do the scary stuff after all, of the 8 slot LUKS thing
There is no need for anything to be scary.
There are (as you know) 8 slots.
You are using 1 .
add a new password to another slot, test that this
works, and then delete the old slot.
This is fully documented in many places online.
You can also consult man cryptsetup - man is your friend.
1 Like
Well it is intimidating for someone brand new to Qubes who is more of a GUI person than a CLI person, but yes I will do this
Thanks for proving additional documentation btw
Many problems that people have in Qubes are actually not Qubes specific.
This is one of those.
The only Qubes specific part here is that you have to do this in dom0.
I dont underestimate how intimidating it can be for someone coming fresh
to Linux and Qubes. That is why I tend to emphasise the importance of
not going to far from the Qubes defaults for most new users.
1 Like
My Threat Model right now requires me to go beyond the defaults
No offense but I wouldn’t even be using Qubes if I wasn’t placed in a situation forcing me to …
… and my mom isn’t too thrilled either but at least I can try to do the difficult stuff where all she has to do is learn how to use the GUI to prompt USB and network auth and keep her qubes activities segregated along with the external hard drive that will save/store data backups
Don’t get me wrong I am thankful this option to use QubesOS exists, but it isn’t how I prefer to live unless forced to do so and now I am forced. I spent a whole decade being spoiled on MacOS, I am already crying inside that my new laptop doesn’t turn on when I lift the lid lol oh well new way of life I guess
By the way, i think uman gave some good tips on changing disk passwords on this thread for changing disk passwords:
1 Like
Also FYI
Source: [from a chat platform that cannot be linked to sorry just screenshots there is no public links for that chat app platform]
/usr/local is similar to your home directory in that each VM gets their own copy of it. So if you add a file like /usr/local/bin/really-cool-script to a template VM, none of the AppVMs based on in will get it. On the other hand, adding /usr/local/bin/really-cool-script within an AppVM will keep that script there even after a reboot.
2 Likes
If you want stuff in your template to show up in /usr/local/bin then put it in /usr/local.orig/bin on the template.
The difficulty is that /usr/local.orig/bin on the template gets copied once to /usr/local/bin on the AppVM when the AppVM is created, so you can’t just alter the template and expect the AppVM to have it the next time you run it. (And this applies to AppVMs that are Disposable templates, too.) That’s fairly easy to fix, though; go into /usr/local/bin on your AppVM and copy the new/changed file(s) out of /usr/local.orig/bin. (That directory always matches what’s currently on the template, as of the time the AppVM started up.)
I deal with this a LOT because I’ve written a LOT of scripts and a few executables, and I don’t want to put them in /usr/bin where they get lost amongst the thousands of “real” system scripts and executables. In my case I can usually just regenerate the AppVM (most of mine are disposable templates, so I don’t lose data), but there are a few “real” AppVMs with data on them so I have to do that copy. (In fact, I think I might just work on a way to automate that.)
2 Likes
I will try to remember this, thank you for the tip!
So this syntax literally has a dot in it’s path directory? Just trying to make sure I get this correct if I try it
Thanks btw (and a script would be really cool)
btw I never did find any conclusive answers on the web for LUKS2 risk of wiping everything out or not, my best guess is it will (based on the very vaguely worded warning on Red Hat)
Do yall know?
yes, it has a dot in the path!
The script I was thinking of was one that would be run on the AppVM once the template is created, to simply copy everything in local.orig to local. I’d only run it on “regular” AppVMs, not Dvm templates (which I will simply regenerate anyway, and that causes the copy to happen). This would end up happening in salt (in fact, there’s a salt state to do exactly this sort of thing, no need to write a script).
But it’s a pretty simple script. Really, all you need to do is open a terminal on the AppVM and issue sudo mkdir -p /usr/local/bin (the directory might not exist yet) and then sudo cp /usr/local.orig/bin/* /usr/local/bin
1 Like
Thanks for the information!
Thank you so much! 