Re: [qubes-users] First time user: initial issues and thoughts
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. 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.
Re: [qubes-users] First time user: initial issues and thoughts
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 -- 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/9ae78236-6c62-9627-0c5e-a68064426a10%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] First time user: initial issues and thoughts
Andrew David Wong: > 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! > >> 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. > > > 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.) 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
Re: [qubes-users] First time user: initial issues and thoughts
-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! > 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. > 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
