Add support for mounting exFAT partitions by default

[bnvk]

Currently, Qubes by default does not mount exFAT formatted external drives / partitions. I believe this should be supported by default so as to be more usable for people not good at using a CLI

[marmarek]

Mounting where? In a VM to which you attach some external block device
(for example using Qubes Manager)? I believe Qubes VM is the same here
as any other Fedora/Debian/whatever system - when you install
appropriate package (fuse-exfat?) it will just work.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[bnvk]

@marmarek yes, the use case where you attach an external device like USB key. However, this particular case of installing the appropriate package is quite challenging as neither yum install fuse-exfat nor yum install exfat-fuse work as the package is not listed. I've been reading forum threads trying to find the best way to do this for the last 20 mins and still no luck. Additionally, the rpm every thread points to at rpm fusion seems to download it over standard HTTP.

This is precisely the sort of UX that I think is a common real world case (a person inserts an exFAT formatted usbkey) that should just work® easily with Qubes!

[marmarek]

Ah, indeed there is no exfat support in plain Fedora. We provide
rpmfusion repositories definitions (disable by default), so if anyone
want to use it, it's only matter of enable:

sudo yum-config-manager --enable rpmfusion-free rpmfusion-free-updates

Then you can simply install the package using yum. We don't want to
enable those repositories by default (or install packages from there),
because it should be user choice about trust and/or licensing (for
example patent restrictions).

Debian apparently provide those packages in the main repository, so there is
no need to add/enable additional ones. apt-get install ... just works
in that case.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[bnvk]

@marmarek thanks for responding. I tried enabling the command you suggested in dom0 and my Fedora TemplateVM, the later looked like it actually performed an action.

After trying to install the fuse-exfat or exfat-fuse packages with yum install, as well the others outlined in this post they all keep saying "No package exfat-fuse found"

I also tried creating a debian-8 AppVM, but for some reason no apps will start from this VM- they just die after launching from the KDE menu.

I hear what you're saying about "because it should be user choice about trust and/or licensing (for example patent restrictions)" and I know this is the sort of thing that many in the infosec / FOSS community are really hardline about. Yet this is precisely one of the major pain points in FOSS and one whereby all but the most skilled and persistent users suffer and often give up or retreat to Mac or Windows. I mean, here I am (2 hours later) being a persistent power user trying to contribute to FOSS, as well as needing the security Qubes provides for my personal / work demands, and I am still unable to figure out out to install these packages and get data off a thumbdrive... Just something to consider when setting defaults and considering usability!

[adrelanos]

On the usability side, I agree with @bnvk here. This whole chain of discussion "I want to copy to USB." -> "You need rpmfusion but beware of trust/legal/patent issues?" -> "What?; How do I do this?" -> etc... itself is much too much for any user. The whole discussion needs to be avoided. More like "I want to copy to USB." -> "Copy to USB then." ;)

Debian apparently provide those packages in the main repository, so there is no need to add/enable additional ones. apt-get install ... just works in that case.

For this reason, and for others, such as...

• How cumbersome it is to debug scriplets on Fedora.
• How cumbersome it is to extract rpm's to get a full view on everything (any scriptlet etc.)
• Another reason, both gui upgraders are broken, Fedora (Graphical update of Fedora 21 template reports no updates available #982) and Debian (T373).
• Fedora .desktop files parsing broken?
• There is no upgrade-grub wrapper in Fedora. (One has to use a cumbersome full command grub2-mkconfig -o /boot/grub2/grub.cfg that I always need to look up.)
• From a perspective of both, a developer and a user, currently Qubes is difficult. One has to know both distributions, Fedora and Debian. I need to know a bit of Fedora to sort out driver issues in dom0 as well as knowledge of Debian to use Debian and Whonix.

Let's consider to throw out Fedora out of Qubes entirely, from dom0, everywhere? (1) (2) Of course, there could be compelling reasons to use Fedora for dom0 for whatever Xen related reason that I am ignorant of.

Please feel free to cut off this "what's the best distribution to fork" discussion. I am happy to move it elsewhere.

(1) (Perhaps have the community take over a template as community supported.)
(2) (I was still preparing this argument. This is a very summarized form of my argument. Felt, now it's the time to jump in.)

[marmarek]

On Tue, Jul 07, 2015 at 11:01:38PM -0700, Patrick Schleizer wrote:

Let's consider to throw out Fedora out of Qubes entirely, from dom0, everywhere? (1) (2) Of course, there could be compelling reasons to use Fedora for dom0 for whatever Xen related reason that I am ignorant of.

Generally, in long term, it is a good idea. But for now changing
distribution in dom0 is too much work. This will be much easier when we
introduce GUI VM, which we have on our roadmap for the next year.

But for now we need to handle Qubes with Fedora in dom0. Note that this
ticket is only about VM distribution, which can be rather easily changed
right now. Actually we have Debian templates available :)

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[bnvk]

@marmarek I think this is a pretty important feature, sad to see the issue closed with wontfix so, couple questions:

1. Can this be achieved if the right packages are installed in the Debian template and a user makes their usbdata VM based on that template instead of Fedora? Or is there some lower level Xen / dom0 issue?
2. If the answer is no, maybe re-open this and assign it to a "Migrate dom0 to Debian" milestone? We could use this to keep track of other relevant issues as well...

[marmarek]

First of all, this all looks to be totally independent of dom0 distribution, only VM is involved.

As explained before, we don't want to enable RpmFusion by default (and install packages from there), so for Fedora it would need user action (one yum install command mentioned before) to having it supported. Maybe having it properly documented would be enough? That would be the easiest (for us) option.
But for Debian, having it installed by default shouldn't be a big problem - just checked:

Need to get 69.9 kB of archives.
After this operation, 330 kB of additional disk space will be used.

I think we can afford this space in default template. The remaining part would be actually using Debian template. User is free to create Debian-based VM (or switch existing) pretty easy, so it can be just documentation thing. The other option would be to having Debian template being the default one. In that case, I think it rather deserve an option in firstboot/pre-configuration.

[adrelanos]

Marek Marczykowski-Górecki:

Maybe having it properly documented would be enough?

Should be documented.

But for Debian, having it installed by default shouldn't be a big problem - just checked:

https://github.com/marmarek/qubes-builder-debian/pull/25

The other option would be to having Debian template being the default one.

I like that idea for other reasons anyhow.

In that case, I think it rather deserve an option in firstboot/pre-configuration.

Not sure. Buried under advanced options perhaps. It's a pretty difficult question for someone using some *nix for the first time.

How could that be worded? @bnvk

[bnvk]

@marmarek thanks for re-opening and looking into this. I understand the reasoning about RpmFusion issue. I'm working on adding to the Docs about this. However,

I can't seem remember how and where to enable RPM Fusion. In our current docs, the only thing seems to be https://www.qubes-os.org/doc/software-update-vm/#tocAnchor-1-1-9 which is lacking & unhelpful. I think I remember running a command from CLI within that Template. Any help?

Offering Debian sounds like a good option for users. Simply adding the lib and a page to the Docs will be good enough for now :)

[adrelanos]

Enabling rpmfusion in dom0 seems super difficult. Even if it was documented. See this thread:

https://groups.google.com/forum/#!msg/qubes-users/zHdY6Oe58t0/qSFkLZdpng4J

I am not sure anymore I got it to work back then.

Perhaps instead of enabling rpmfusion in dom0 or Fedora, documentation should recommend to use a Debian based VM for this task?

[marmarek]

Why would you want to enable it in dom0?! You should not mount external devices in dom0, instead use some VM for that. Debian-based one in this case is a good choice.

[Gw443]

I agree. Coming from windows and without much unix knowledge that's a barrier. I am still struggling for it.

[Gw443]

--enable is not recognized, so I tried --enablerepo, then, the command is:
sudo yum-config-manager --enablerepo rpmfusion-free rpmfusion-free-updates

then:
sudo yum install fuse-exfat
Error: Unable to find a match

[marcb]

In sys-usb I enabled network access via sys-firewall to allow the following:

after sudo yum-config-manager --enablerepo rpmfusion-free rpmfusion-free-updates I had to manually enable them in /etc/yum.repos.d. change enabled=0 to enabled=1 for first entries in rpmfusion-free.repo and rpmfusion-free-updates.repo.

I then executed sudo yum install fuse-exfat exfar-utils. Check and if satisfied accept the GPG key.

Then I removed network access to sys-usb.

[connorbode]

I'm convinced this issue should be closed.. it was a very simple install for me:

On dom0, follow the Qubes instructions to attach drive to your qube

In your qube:

sudo yum-config-manager --enablerepo rpmfusion-free rpmfusion-free-updates
sudo dnf install fuse-exfat
# if you want this to be available after rebooting the AppVM,
# the commands above must be run in your TemplateVM
cd ~
mkdir mnt
sudo mount.exfat-fuse /dev/xvdi1 mnt

Now your drive is available in the mnt directory.

Use lsblk -f to find the appropriate drive. It should show the name of your drive, and also verify that it is using an exfat filesystem.

[philipthatcher]

This appears to have moved on since originally posted. The correct commands are below. ('yum-config-manager' did nothing in my Qubes OS R4.0).

In your qube:

sudo dnf config-manager --set-enabled rpmfusion-free rpmfusion-nonfree
sudo dnf install fuse-exfat
# if you want this to be available after rebooting the AppVM,
# the commands above must be run in your TemplateVM
cd ~
mkdir mnt
sudo mount.exfat-fuse /dev/xvdi1 mnt

Now your drive is available in the mnt directory.

Use lsblk -f to find the appropriate drive. It should show the name of your drive, and also verify that it is using an exfat filesystem.

[andrewdavidwong]

It appears this issue has already been resolved, so I'll close it. If anyone believes the issue is not yet resolved, or if anyone is still affected by this issue, please leave a comment, and we'll be happy to reopen this. Thank you.