First time user: initial issues and thoughts

[sm8ax1]

Hi,

I just installed Qubes yesterday and wanted to share my thoughts and
some issues I ran into.

Table of Contents
1. Use Case / Thanks
2. Minor issues with manual partitioning and assigning mountpoints
3. First-boot dialog
4. NetworkManager applet didn't start the first time
5. Modifying /etc files in template-inherited VMs persistently
6. Screensaver blacks screen but doesn't turn off the backlight
7. sys-firewall uses much more RAM than it should have to
8. Encrypted /boot partition support

First, I want to thank the developers. I've used Xen with QEMU and GTK+
on other Linuxes before, so I'm familiar with some of the concepts. I
was trying to accomplish basically what Qubes did, but it was a real
pain to manage, the actual security of the whole system was
questionable, and even simple tasks like pasting text or transferring
files were a pain. You guys did a great job with Qubes. It's the OS I've
been waiting for.

I learned about it a long time ago, probably around the time it first
came out, but I didn't think about trying it until it was featured on
the Tor blog and I learned about some new features. (For anyone who's
interested, I had a thoughtful, though theoretical, debate with another
reader about the some of the design choices around Qubes:
https://blog.torproject.org/blog/tor-heart-qubes-os#comment-229452)

The installation was pretty easy, but I ran into somewhat of an edge
case that held me up a little. I did my partitioning manually, and kept
the same GPT (and protective MBR) that was already installed.

BIOS Boot Partition (1007K) - out-of-alignment filesystemless partition
that allows GRUB to embed itself
EFI System Partition
/boot partition
encrypted main partition with LVM
root
swap

All good. Here's the issue. I thought I would "help" the installer by
creating a BTRFS LV for the root filesystem. It showed up in the
installer with a weird name like "btrfs.XXX" (where X is a digit that
changed on each reboot), and it didn't have the logical volume name in
the subtext like my swap LV did. I was typing "/" into the mountpoint
field, but instead of moving the partition up to the
to-be-assigned-a-mount-point group (above the list of available
partitions) when I clicked away like /boot and /boot/efi, the "/"
disappeared and the partition stayed put. I didn't think anything of
pre-formatting the LV with BTRFS because it was okay for all of the
other partitions.

I worked around it by removing the filesystem from the LV (zeroing it
out), and then the installer finally allowed me to have a new BTRFS
filesystem created on the LV and a mountpoint assigned. I think at some
point I read in the documentation that the root filesystem MUST be newly
created, but it would have saved me a lot of time if the installer had
just told me that. Overall I'd say it did alright for an LVM-on-LUKS
with BTRFS installation though.

The first-boot options dialog could have explained the options a little
better, or they should be explained in the documentation. For example,
the option to proxy all applications and upgrades through Tor, I
selected it because it sounded like what I wanted, but I didn't really
understand how it would affect the networking VM hierarchy or whether I
could still create unproxied VMs. I left the USB VM (sys-usb) option
unselected because I wasn't sure how reliable it would be, I don't have
an IOMMU anyway, and I don't connect a lot of random USB devices to my
computer, but I would like to try the feature in the future. All along I
was thinking "Can I change my mind later? Am I stuck with these
decisions for the rest of my life?"

Next, and this is the biggest one, the NetworkManager applet in sys-net
didn't start the first time, so I spent an a lot of extra time tinkering
with it and researching the problem until I found a bug report that
described the exact problem I was having. All I had to do was restart
sys-net, but it would have saved me a lot of time if it had started on
its own the first time.

I wanted to setup MAC address spoofing on my wireless interface too, so
I modified /etc/NetworkManager/NetworkManager.conf in sys-net, but when
I restarted it my changes were gone. I read that I have to make changes
in the TemplateVM itself (fedora-23) for them to be persistent, but the
problem is that I don't necessarily need all VMs to have this change.
I'm still not sure of the correct way to make changes to a single VM
that inherits from a TemplateVM.

Also, the screen saver doesn't turn off the display backlight like it
did on my old OS on this machine. Rather, the screen goes black but the
backlight is still on. I've seen other machines do the same thing, but I
know the hardware and drivers support turning off the backlight on this
machine if I can figure out how to configure it. I'm really hoping it
doesn't involve recompiling the kernel or anything like that.

When the Qubes VM Manager came up, my first thought (after noticing how
nice it looked) was "1400MB of RAM for a firewall? Really?" It's now at
723MB, but still, I have a feeling something like DSL or Alpine Linux
could do the same with less resource consumption (and better hardening,
as an added bonus).

Lastly, something I lost from my old setup was an encrypted /boot
partition[1]. It used GRUB_ENABLE_CRYPTODISK=y so that Grub itself could
unlock the /boot partition run the kernel and early userspace, which
could optionally do some authenticity checks (e.g. verify the bootloader
was not modified)[2], and then ask for the main partition password.
Although not perfect, this helps protects the kernel and early userspace
from tampering and mitigates certain other offline attacks. Are there
any plans to support something like this on Qubes OS in the future?

[1]
https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Encrypted_boot_partition_.28GRUB.29
[2]
https://wiki.archlinux.org/index.php/Dm-crypt/Specialties#mkinitcpio-chkcryptoboot

-------------------------------------------------

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2017-03-04 06:35, sm8ax1 wrote:
> Hi,
>
> I just installed Qubes yesterday and wanted to share my thoughts and
> some issues I ran into.
>
> Table of Contents
> 1. Use Case / Thanks
> 2. Minor issues with manual partitioning and assigning mountpoints
> 3. First-boot dialog
> 4. NetworkManager applet didn't start the first time
> 5. Modifying /etc files in template-inherited VMs persistently
> 6. Screensaver blacks screen but doesn't turn off the backlight
> 7. sys-firewall uses much more RAM than it should have to
> 8. Encrypted /boot partition support
>
> First, I want to thank the developers. I've used Xen with QEMU and GTK+
> on other Linuxes before, so I'm familiar with some of the concepts. I
> was trying to accomplish basically what Qubes did, but it was a real
> pain to manage, the actual security of the whole system was
> questionable, and even simple tasks like pasting text or transferring
> files were a pain. You guys did a great job with Qubes. It's the OS I've
> been waiting for.
>

Welcome, and thank you for the thoughtful and organized feedback!

Possibly related and/or helpful links:

https://www.qubes-os.org/doc/custom-install/
https://github.com/QubesOS/qubes-issues/issues/2340
(I've added a link to your post.)

> The first-boot options dialog could have explained the options a little
> better, or they should be explained in the documentation. For example,
> the option to proxy all applications and upgrades through Tor, I
> selected it because it sounded like what I wanted, but I didn't really
> understand how it would affect the networking VM hierarchy or whether I
> could still create unproxied VMs. I left the USB VM (sys-usb) option
> unselected because I wasn't sure how reliable it would be, I don't have
> an IOMMU anyway, and I don't connect a lot of random USB devices to my
> computer, but I would like to try the feature in the future. All along I
> was thinking "Can I change my mind later? Am I stuck with these
> decisions for the rest of my life?"
>

We plan to implement explanatory tooltips to help with this:

https://github.com/QubesOS/qubes-issues/issues/2211
(I've added your comments and a link to this post.)

> Next, and this is the biggest one, the NetworkManager applet in sys-net
> didn't start the first time, so I spent an a lot of extra time tinkering
> with it and researching the problem until I found a bug report that
> described the exact problem I was having. All I had to do was restart
> sys-net, but it would have saved me a lot of time if it had started on
> its own the first time.
>

Was it this one?

https://github.com/QubesOS/qubes-issues/issues/2293

> I wanted to setup MAC address spoofing on my wireless interface too, so
> I modified /etc/NetworkManager/NetworkManager.conf in sys-net, but when
> I restarted it my changes were gone. I read that I have to make changes
> in the TemplateVM itself (fedora-23) for them to be persistent, but the
> problem is that I don't necessarily need all VMs to have this change.
> I'm still not sure of the correct way to make changes to a single VM
> that inherits from a TemplateVM.
>

On MAC anonymization:

https://www.qubes-os.org/doc/anonymizing-your-mac-address/

On TemplateVM persistence:

https://www.qubes-os.org/doc/templates/#important-notes

On making directories persistent without making the changes in a TemplateVM:

https://www.qubes-os.org/doc/bind-dirs/

> Also, the screen saver doesn't turn off the display backlight like it
> did on my old OS on this machine. Rather, the screen goes black but the
> backlight is still on. I've seen other machines do the same thing, but I
> know the hardware and drivers support turning off the backlight on this
> machine if I can figure out how to configure it. I'm really hoping it
> doesn't involve recompiling the kernel or anything like that.
>

This sounds like a hardware-specific issue. It might be worth asking
about this in a separate thread (in which you give your hardware specs).
But first, if you haven't already done so, I recommend investigating it
as an upstream issue.

> When the Qubes VM Manager came up, my first thought (after noticing how
> nice it looked) was "1400MB of RAM for a firewall? Really?" It's now at
> 723MB, but still, I have a feeling something like DSL or Alpine Linux
> could do the same with less resource consumption (and better hardening,
> as an added bonus).
>

The Qubes memory manager (qmemman) daemon automatically and dynamically
reallocates available memory to all running VMs. If a small number of
VMs are running relative to your total system memory, it will appear
that they're using large amounts of memory. However, that memory will
simply be reallocated to new VMs when you start them. So, it's not that
sys-firewall *requires* that much memory. That's simply how much memory
qmemman has given it at the moment, since the memory is not needed
elsewhere.

More information about qmemman:

https://www.qubes-os.org/doc/qmemman/

> Lastly, something I lost from my old setup was an encrypted /boot
> partition[1]. It used GRUB_ENABLE_CRYPTODISK=y so that Grub itself could
> unlock the /boot partition run the kernel and early userspace, which
> could optionally do some authenticity checks (e.g. verify the bootloader
> was not modified)[2], and then ask for the main partition password.
> Although not perfect, this helps protects the kernel and early userspace
> from tampering and mitigates certain other offline attacks. Are there
> any plans to support something like this on Qubes OS in the future?
>

Yes:

https://github.com/QubesOS/qubes-issues/issues/2442

> [1]
> https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Encrypted_boot_partition_.28GRUB.29
> [2]
> https://wiki.archlinux.org/index.php/Dm-crypt/Specialties#mkinitcpio-chkcryptoboot
>

- --

Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYu+3wAAoJENtN07w5UDAweSIP/0gSLrQx1C+AIMuRSal+TVDi
WZTJA9/tmODetes4q6EDD2WqlnTIYB5J/aFYmt8oPvqZ3vR+a7MT5msX7X+QX1cF
0IkEPlT+pXu6tezRiUeJf6kRbvSP6uv1WA8aX8rmR0mQ5WhFQVASsCHeXol6vG5T
9C1892RycUkf5KykkBnS1kwiOofAvErQrYtweBitACuUfuDB5/nOsdYxipqGfKbt
xETjsvy404TtxwAzgXdmUvTutFynaJq87C4RtnsQgac6Atrz2256BfpFiVmVSaRU
6cgN9LLdiPNJoT/qo5nOGTMM+8fdECKq96s1hnqv5lcoJP4GsA24C4mrZWBjoJha
gOdn1xF303n3e0aLwsCoIX768n8BykP1huUJUtQgHzJ+3VvQMODA9lXweehOQ/Mg
S3VzCLjhmmd3mj7umQzkzMNzmOJCnhf4pNJlsbnFEHMuVPfgaKyI1E058s9VzWQm
hRuFy7OPx5GU7NpRDdzsA/yz/LAgcX/r2x/XLni1dSLIECYo+QMTXmQC16Y9RNMp
FY+EYmLeevXdZjwT09iosIfTXBWaxFzp+EO0o0FjduHh0OYl7PHXnCbFknLKYbuS
2BpRKQP8PfXw+mtViHMDH5jxLUF7f9Df6TZti/QovlKeslyRNoRmxDrxx8MtdO86
O5Z4/dXxTPHYQHlBQ8eK
=79m1
-----END PGP SIGNATURE-----

[sm8ax1]

Andrew David Wong:

Thanks, I read the custom install page prior to installing, but I was
unaware of #2340.

To be honest, when I decided I wanted BTRFS, I just sort of assumed that
guest disk images were logical volumes to begin with. The custom install
page mentioned LVM in every scenario, so I thought it was necessary for
that reason. And the Xen wiki repeatedly mentions that logical volumes
are faster than image files on any kind of filesystem. It was, however,
suspcious when the custom install page said "-l 100%FREE" for the root
LV. I guess that's what I get for assuming.

Are there any plans for hooking Qubes up to the LVM in this way? LVM
itself supports block-level rw CoW snapshots, and the Xen project
strongly recommends it over image files.

And as a final thought, it really wouldn't be that hard for Qubes to run
`chattr +C $file` when a new image file is created (though CoW is
reenabled if you take a snapshot, according to #2340). Note that if you
want to do this after the fact, you have to recreate the file (setting
+C on a non-empty-file is undefined).

mv file.img file.img.bak
touch file.img
chattr +C file.img
cp file.img.back file.img
rm file.img.bak

>
>> The first-boot options dialog could have explained the options a little
>> better, or they should be explained in the documentation. For example,
>> the option to proxy all applications and upgrades through Tor, I
>> selected it because it sounded like what I wanted, but I didn't really
>> understand how it would affect the networking VM hierarchy or whether I
>> could still create unproxied VMs. I left the USB VM (sys-usb) option
>> unselected because I wasn't sure how reliable it would be, I don't have
>> an IOMMU anyway, and I don't connect a lot of random USB devices to my
>> computer, but I would like to try the feature in the future. All along I
>> was thinking "Can I change my mind later? Am I stuck with these
>> decisions for the rest of my life?"
>
>
> We plan to implement explanatory tooltips to help with this:
>
> https://github.com/QubesOS/qubes-issues/issues/2211
> (I've added your comments and a link to this post.)
>
>> Next, and this is the biggest one, the NetworkManager applet in sys-net
>> didn't start the first time, so I spent an a lot of extra time tinkering
>> with it and researching the problem until I found a bug report that
>> described the exact problem I was having. All I had to do was restart
>> sys-net, but it would have saved me a lot of time if it had started on
>> its own the first time.
>
>
> Was it this one?
>
> https://github.com/QubesOS/qubes-issues/issues/2293

Yes, and #2537 referenced by #2293 in particular. I didn't have to mess
with service files or the Services tab at all fortunately, I just had to
restart sys-net.

>> I wanted to setup MAC address spoofing on my wireless interface too, so
>> I modified /etc/NetworkManager/NetworkManager.conf in sys-net, but when
>> I restarted it my changes were gone. I read that I have to make changes
>> in the TemplateVM itself (fedora-23) for them to be persistent, but the
>> problem is that I don't necessarily need all VMs to have this change.
>> I'm still not sure of the correct way to make changes to a single VM
>> that inherits from a TemplateVM.
>
>
> On MAC anonymization:
>
> https://www.qubes-os.org/doc/anonymizing-your-mac-address/

That's more or less what I read on other sites. I think we should
consider putting a Big Fat Warning on that page saying that your changes
will be lost on restart if the VM belongs to a template, or you could
easily leak your real MAC address by accident.

>
> On TemplateVM persistence:
>
> https://www.qubes-os.org/doc/templates/#important-notes
>
> On making directories persistent without making the changes in a TemplateVM:
>
> https://www.qubes-os.org/doc/bind-dirs/

Thanks. It sounds like bind-dirs.sh is just what I need!

>
>> Also, the screen saver doesn't turn off the display backlight like it
>> did on my old OS on this machine. Rather, the screen goes black but the
>> backlight is still on. I've seen other machines do the same thing, but I
>> know the hardware and drivers support turning off the backlight on this
>> machine if I can figure out how to configure it. I'm really hoping it
>> doesn't involve recompiling the kernel or anything like that.
>
>
> This sounds like a hardware-specific issue. It might be worth asking
> about this in a separate thread (in which you give your hardware specs).
> But first, if you haven't already done so, I recommend investigating it
> as an upstream issue.

I found a partial solution to this. Running "xset q" showed that DPMS
had various timeouts set, but was disabled. I opened the Xfce "Power
Manager", switched to the "Display" tab, and then toggled "Display Power
Management" off and on again. Then, "xset q" showed DPMS enabled. I
guess it just needed a poke, sort of like the NetworkManager/sys-net
issue. I'm still having trouble getting all of timeouts right, at the
moment it puts the screen into standby (backlight off) but at some point
it will come back on with just the blank screen. I'll look it up and
play around with it and see if I can figure out what's wrong. It is
probably an upstream issue but hopefully worth mentioning here.

https://wiki.archlinux.org/index.php/Display_Power_Management_Signaling
http://shallowsky.com/linux/x-screen-blanking.html

>
>> When the Qubes VM Manager came up, my first thought (after noticing how
>> nice it looked) was "1400MB of RAM for a firewall? Really?" It's now at
>> 723MB, but still, I have a feeling something like DSL or Alpine Linux
>> could do the same with less resource consumption (and better hardening,
>> as an added bonus).
>
>
> The Qubes memory manager (qmemman) daemon automatically and dynamically
> reallocates available memory to all running VMs. If a small number of
> VMs are running relative to your total system memory, it will appear
> that they're using large amounts of memory. However, that memory will
> simply be reallocated to new VMs when you start them. So, it's not that
> sys-firewall *requires* that much memory. That's simply how much memory
> qmemman has given it at the moment, since the memory is not needed
> elsewhere.
>
> More information about qmemman:
>
> https://www.qubes-os.org/doc/qmemman/

Thanks. I haven't read the whole article yet, but it makes makes a lot
more sense now.

>
>> Lastly, something I lost from my old setup was an encrypted /boot
>> partition[1]. It used GRUB_ENABLE_CRYPTODISK=y so that Grub itself could
>> unlock the /boot partition run the kernel and early userspace, which
>> could optionally do some authenticity checks (e.g. verify the bootloader
>> was not modified)[2], and then ask for the main partition password.
>> Although not perfect, this helps protects the kernel and early userspace
>> from tampering and mitigates certain other offline attacks. Are there
>> any plans to support something like this on Qubes OS in the future?
>
>
> Yes:
>
> https://github.com/QubesOS/qubes-issues/issues/2442

That sounds almost like a wontfix. "Imperfect therefore pointless" so to
speak. It is the usual reaction to encrypted /boot, in my experience. We
had to go through a fairly detailed list of scenarios that it would and
would not protect against before it even made it to the Arch Wiki.

It is true that real firmware-level protection like secure boot would be
superior in detecting bootloader tampering, and I strongly encourage the
developers to work towards enabling it for machines that support it, but
that's not possible for everyone, particularly those with a BIOS or
without the ability to enroll their own UEFI keys. Even that isn't
perfect if the installed OS has ever had access to the signing key,
meaning offline kernel/initramfs updates (from a bootable drive) would
be necessary.

The point is that it's far easier for someone to build a malicious and
stealthy payload into /boot/vmlinuz or /boot/initramfs.img compared to
the first track (first 440 bytes) of the hard disk, where Grub stage1 is
located, or the EFI Boot Partition (or post-MBR gap) where stage2
(core.img) is located. Apart from the payload size restrictions, you
have Real Mode and the lack of system calls, hardware drivers, and
dynamic linking (to an extent) to contend with.

Storing /boot on an external drive is already possible as with any OS.
The only work to be done there is a friendly GUI that helps the user do
it. And if you accidentally forget to insert the drive before booting,
or you get your BIOS boot order wrong, then you're booting from the hard
disk anyway, so that's not perfect either.

I guess we'll just have to wait and see if anything comes of it.

>
>> [1]
>> https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Encrypted_boot_partition_.28GRUB.29
>> [2]
>> https://wiki.archlinux.org/index.php/Dm-crypt/Specialties#mkinitcpio-chkcryptoboot
>
>
>

[Chris Laprise]

On 03/05/2017 08:11 AM, sm8ax1 wrote:
>
> Thanks, I read the custom install page prior to installing, but I was
> unaware of #2340.
>
> To be honest, when I decided I wanted BTRFS, I just sort of assumed that
> guest disk images were logical volumes to begin with. The custom install
> page mentioned LVM in every scenario, so I thought it was necessary for
> that reason. And the Xen wiki repeatedly mentions that logical volumes
> are faster than image files on any kind of filesystem. It was, however,
> suspcious when the custom install page said "-l 100%FREE" for the root
> LV. I guess that's what I get for assuming.
>
> Are there any plans for hooking Qubes up to the LVM in this way? LVM
> itself supports block-level rw CoW snapshots, and the Xen project
> strongly recommends it over image files.

Normally you shouldn't mix Btrfs with LVM, as the former is a kind of
volume manager in itself.

I have used Btrfs on Qubes for probably close to 2 years and it has been
very good in terms of stability and performance. However, anaconda
(fedora's installer) doesn't handle a mixture of partitioning and fs
options well, esp. if you select Btrfs. The only 'good' way I've found
is to select a Btrfs system install and let it re-partition the whole
disk; otherwise, it has a tendency to forget steps such as LUKS
encryption layer.

Note that thin-provisoned LVM (probably the type you're referring to)
incurs a speed penalty as well. Its really doing the same work as Btrfs,
but without some of the nice features.

> I wanted to setup MAC address spoofing on my wireless interface too, so
>>> I modified /etc/NetworkManager/NetworkManager.conf in sys-net, but when
>>> I restarted it my changes were gone. I read that I have to make changes
>>> in the TemplateVM itself (fedora-23) for them to be persistent, but the
>>> problem is that I don't necessarily need all VMs to have this change.
>>> I'm still not sure of the correct way to make changes to a single VM
>>> that inherits from a TemplateVM.
>>
>> On MAC anonymization:
>>
>> https://www.qubes-os.org/doc/anonymizing-your-mac-address/
> That's more or less what I read on other sites. I think we should
> consider putting a Big Fat Warning on that page saying that your changes
> will be lost on restart if the VM belongs to a template, or you could
> easily leak your real MAC address by accident.

This behavior is explained in Qubes introductory material...
template-based VMs forget anything that isn't in /rw (such as home/).
That's why its routine for Qubes docs to instruct adding settings to the
template. In this case, the doc also has the user restarting the netVM
before checking the MAC address.

Also, a given template does boot differently depending on the VM type
(netVM, proxyVM, appVM) that's using it. So Network Manager settings
don't really affect appVMs since they aren't intended to run NM.

>> On TemplateVM persistence:
>>
>> https://www.qubes-os.org/doc/templates/#important-notes
>>
>> On making directories persistent without making the changes in a TemplateVM:
>>
>> https://www.qubes-os.org/doc/bind-dirs/
> Thanks. It sounds like bind-dirs.sh is just what I need!

There are several alternatives for configuration. The VPN doc describes
using /rw/config (without bind-dirs) to configure and script things for
a specific VM. You could also create a standalone netVM so that config
changes become very straightforward. It depends on the specific case.

Chris

[sm8ax1]

Chris Laprise:

The installer worked the way I wanted it to after a few tries, as I
mentioned earlier. I just had to delete the filesystem from the LV
first. The custom install page even warns that it's likely to be
glitchy. I can't really complain.

I'm not sure what you mean by the installer forgetting the LUKS
encryption layer. That already existed on the disk before I used the
installer. I had to unlock it within the installer before I could setup
the root and swap LVs. If it were to overwrite the whole LUKS container
with a root filesystem then that's one hell of a bug.

About Btrfs...

You have a point that Btrfs can replace LVM for the most part and
thin-provisioned LVM's performance is probably comparable. However, I
was referring specifically to Xen Project's recommendation to use LVM
because the block device backend is faster than the filesystem backend
according to them. This is regardless of the performance difference
between btrfs and thin-provisioned LVM, presumably.

I mistakenly implied that snapshot capabilities even matter with things
as they are today. If Qubes can run on ext4, necessarily without any
CoW/snapshot infrastructure, then it seemingly could run on traditional
LVM just the same. The only difference is it would be running on a block
device rather than a filesystem. Snapshots and thin-provisioned LVM are
both beyond the scope of this comparison.

As a separate issue, CoW copies of blocks being created when a file is
randomly written to is just part of how Btrfs works and irrelevant to
snapshots (which AFAIK aren't used) in Qubes's case. It can cause bad
performance with random-write scenarios like virtual machine images.
Using an LV solves the problem, but so does `chattr +C`, so there's not
much of an argument here.

As an aside, sometimes the biggest advantage to using LVM is because
many early userspace implementations don't know how to unlock multiple
LUKS partitions (e.g. root (btrfs) and swap). Although you don't
technically need swap unlocked in early userspace, you do if you want to
resume from hibernation and/or only enter your password once. Btrfs
doesn't support swap files either.

Using Btrfs instead of LVM is completely valid in many cases. The
question is whether the performance advantage of traditional LVM would
justify supporting it in addition to image files.

>> I wanted to setup MAC address spoofing on my wireless interface too, so
>>>> I modified /etc/NetworkManager/NetworkManager.conf in sys-net, but when
>>>> I restarted it my changes were gone. I read that I have to make changes
>>>> in the TemplateVM itself (fedora-23) for them to be persistent, but the
>>>> problem is that I don't necessarily need all VMs to have this change.
>>>> I'm still not sure of the correct way to make changes to a single VM
>>>> that inherits from a TemplateVM.
>>>
>>> On MAC anonymization:
>>>
>>> https://www.qubes-os.org/doc/anonymizing-your-mac-address/
>> That's more or less what I read on other sites. I think we should
>> consider putting a Big Fat Warning on that page saying that your changes
>> will be lost on restart if the VM belongs to a template, or you could
>> easily leak your real MAC address by accident.
>
> This behavior is explained in Qubes introductory material...
> template-based VMs forget anything that isn't in /rw (such as home/).
> That's why its routine for Qubes docs to instruct adding settings to the
> template. In this case, the doc also has the user restarting the netVM
> before checking the MAC address.
>
> Also, a given template does boot differently depending on the VM type
> (netVM, proxyVM, appVM) that's using it. So Network Manager settings
> don't really affect appVMs since they aren't intended to run NM.

This is an interesting point I wasn't aware of. Are there more details
on the specific differences between types of VMs? I guess I could have
just made the changes to the fedora-23 TemplateVM then.

>>> On TemplateVM persistence:
>>>
>>> https://www.qubes-os.org/doc/templates/#important-notes
>>>
>>> On making directories persistent without making the changes in a
>>> TemplateVM:
>>>
>>> https://www.qubes-os.org/doc/bind-dirs/
>> Thanks. It sounds like bind-dirs.sh is just what I need!
>
> There are several alternatives for configuration. The VPN doc describes
> using /rw/config (without bind-dirs) to configure and script things for
> a specific VM. You could also create a standalone netVM so that config
> changes become very straightforward. It depends on the specific case.
>
> Chris
>

Thanks. I went with bind-dirs.sh so far, but I'll look into the
/rw/config method as well. I thought about creating a standalone VM at
first, but having to update it separately is a disadvantage there. Like
you said, it depends on the case.

[Chris Laprise]

On 03/06/2017 07:44 AM, sm8ax1 wrote:
>
> Using Btrfs instead of LVM is completely valid in many cases. The
> question is whether the performance advantage of traditional LVM would
> justify supporting it in addition to image files.

BTW, Qubes R4 will have a new storage architecture with plugin
capability, and IIRC it will default to using a Xen block driver +
thin-provisioned LVM plugin.

>
>>> I wanted to setup MAC address spoofing on my wireless interface too, so
>>>>> I modified /etc/NetworkManager/NetworkManager.conf in sys-net, but when
>>>>> I restarted it my changes were gone. I read that I have to make changes
>>>>> in the TemplateVM itself (fedora-23) for them to be persistent, but the
>>>>> problem is that I don't necessarily need all VMs to have this change.
>>>>> I'm still not sure of the correct way to make changes to a single VM
>>>>> that inherits from a TemplateVM.
>>>> On MAC anonymization:
>>>>
>>>> https://www.qubes-os.org/doc/anonymizing-your-mac-address/
>>> That's more or less what I read on other sites. I think we should
>>> consider putting a Big Fat Warning on that page saying that your changes
>>> will be lost on restart if the VM belongs to a template, or you could
>>> easily leak your real MAC address by accident.
>> This behavior is explained in Qubes introductory material...
>> template-based VMs forget anything that isn't in /rw (such as home/).
>> That's why its routine for Qubes docs to instruct adding settings to the
>> template. In this case, the doc also has the user restarting the netVM
>> before checking the MAC address.
>>
>> Also, a given template does boot differently depending on the VM type
>> (netVM, proxyVM, appVM) that's using it. So Network Manager settings
>> don't really affect appVMs since they aren't intended to run NM.
> This is an interesting point I wasn't aware of. Are there more details
> on the specific differences between types of VMs? I guess I could have
> just made the changes to the fedora-23 TemplateVM then.

IIRC it revolves around qvm-service. This doc has some details:

https://www.qubes-os.org/doc/dom0-tools/qvm-service/

>>>> On TemplateVM persistence:
>>>>
>>>> https://www.qubes-os.org/doc/templates/#important-notes
>>>>
>>>> On making directories persistent without making the changes in a
>>>> TemplateVM:
>>>>
>>>> https://www.qubes-os.org/doc/bind-dirs/
>>> Thanks. It sounds like bind-dirs.sh is just what I need!
>> There are several alternatives for configuration. The VPN doc describes
>> using /rw/config (without bind-dirs) to configure and script things for
>> a specific VM. You could also create a standalone netVM so that config
>> changes become very straightforward. It depends on the specific case.
>>
>> Chris
>>
> Thanks. I went with bind-dirs.sh so far, but I'll look into the
> /rw/config method as well. I thought about creating a standalone VM at
> first, but having to update it separately is a disadvantage there. Like
> you said, it depends on the case.

Here is a related example using rc.local. Instead of starting a process
directly, it adds a new systemd service and starts it...

https://github.com/tasket/Qubes-vpn-support