I’ve searched for issues using queries like “where to view disks” and “how to display drives”, unfortunately it’s difficult to know what exactly to say to find the relevant discussion, I assume this has been explained elsewhere.
Clicking the drive icon on the tray doesn’t really show what I’m looking for. It lists volumes (linux-kernel, varlibqubes, vm-pool). This is not useful info to me. My preferred way to view disks is using gnome-disks-utility. But since qubes are compartmentalized, any qube I open this app in will only show block devices, never the whole disk (I’m looking for a 2TB disk, connected via m.2 slot, what shows up here isn’t any more than a few GB). I don’t have a dedicated USB qube, and I’m not about to install gnome disks in dom0. So where do I find my disks?
The internal SSD is my Fedora host drive. I don’t want to use it as secondary storage. I just want to see how I can actually access the drive and display it in gnome disks.
gnome-disks is not installed in dom0, so you cannot. You could install
gnome-disks using sudo qubes-dom0-update gnome-disks - it’s a small
install with few dependencies.
I think the major question is why? What is it that you want to do that
you need this utility?
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
One thing I don’t recommend using is the disk monitor on KDE. Probably due to how many volumes there is on Qubes, the disk monitor starts consuming a lot of resources and might freeze your system. This was on R4.2, didn’t test since and I don’t recommend fiddling with such thing on dom0.
It causes dom0 to parse VM volumes* for partition tables. VM volume content is fully controlled by the VM and potentially malicious.
* All running VMs’ volumes on Btrfs/XFS; not sure about LVM
This seems like a general caveat for such tools in dom0: You don’t want to use a tool that automatically scans each and every “disk” (including virtual ones representing VM volumes). Besides the security risk, it could also cause data corruption if a VM volume “disk” that is already mounted in the VM is automatically (or after one click in the wrong place) mounted in dom0 too.
Unfortunately not, and there are probably lots of ways to (more or less) accidentally make dom0 handle VM storage data. E.g. it’s common to see people fscking or mounting VM volumes in dom0 for recovery, because it’s not intuitive that this alone is already very dangerous.
Ideally, all of dom0 - except for the Xen backend providing storage to the VM, and the Qubes OS subsystem managing it - should somehow (SELinux? Some other LSM?) be prevented from casually reading VM volume data even as root, unless the user acknowledges a specific warning.
Your point is a good one, but OP was not, I think, interested in VM
storage, but in storage disks attached to the system. I’m not clear that
gnome-disks actually does parse the partition table until
the block device is selected, although fdisk does, I think, do so. It
isnt worth the risk.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
I’m using LVM/ext4 and don’t recall fdisk -l returning any info on the VMs but it’s been a while and now I don’t want to use the command
I recall needing to recover data inside a VM on a failed Qubes install. Had a lot of trouble getting info on the VMs, thin pools etc
I assume that your warning also applies to using cli like vgscan, lvscan etc ? Or only after running vgchange -ay ?
Is there a qubes documentation link for this warming or is it undocumented? Or a GitHub issue ? I’m surprised it let’s me do this… I thought dom0 restricted harmful behavior
On reflection, I think the warning might be redundant. fdisk -l
returns data from /proc/partitions which suggests that this data is already in dom0. If there’s danger here then it’s already happened.
To access a Qubes disk and get data from individual qubes is documented here -
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
No, fdisk -l also scans the content of block devices that are not configured to have the kernel scan them for partitions: Try setting up a loop device (without --partscan) for a partitioned image file. /sys/block/loopN/partscan will be set to 0, there will be no partitions listed for loopN in /proc/partitions, and no /dev/loopNpM devices will exist. But fdisk -l [/dev/loopN] will show the partitions.
I’m not an LVM user, but AFAIK those tools should be okay. They don’t care about the content inside of the LVM volumes. And dom0 also configures LVM not to scan most devices, so that among other things it doesn’t target loop devices which could be file(-reflink) volumes.
Oh no, there are infinite ways shoot yourself in the foot in dom0 - manually. It’s a environment full of sharp edged general purpose Linux tools! dom0 does try not to do it automatically though, e.g. by disabling Fedora’s os-prober.
It’s true the manpage is not too explicit about this, but it’s only claiming that fdisk -l gets the devices to be scanned for partitions from /proc/partitions - not that it gets the partitions from there as well…
I recently had to figure out how to view my various HDs and have one mount to my ‘vault’ qube for data storage and management.
To find the harddrive i used lsblk in dom0. This gave me a list of loop devices, harddrives with the typical sda, sdb, naming convention, then a big list of qube partitions branching from the main HD.
It’s important to note that if the HD or other block device you want to mount is currently mounted to dom0 the next command wont work, unmount it so it is available for the appVM qubes
In dom0, run qvm-block list
This will spit out all block devices available for mounting. my hard drives are all labeled something like “dom0:sda”
or “dom0:sdb1” and usb devices are “sys-usb:sdx”. You’ll also get some info on each device, such as the volume label, and if it is currently attached to a qube.
Find the device you need and then run qvm-block attach <qube name> <device label> where the device label is the " dom0:sdx" you got from qvm-block list
This will last until dom0 is rebooted. To make things persistent use `qvm-block assign
Now open the terminal in your target qube and use lsblk
You should have a new drive labeled “xvd!” Where the ! is a letter, typically ‘d’ or ‘i’. You can now mount this device with typical linux commands.
I’m still super new to qubes, hope this helps. My understanding is only dom0 gets to see everything, any qube will only get the small virtual storage drive it’s assigned when created. With a device attached using the method I described, that qube will have full access to the device, but other qubes will not.
on my system tray.