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! -- 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/646d702f-0553-b11c-e895-7421acb541dd%40vfemail.net. For more options, visit https://groups.google.com/d/optout.
