Hacking Dom0 Root Pool Params

I want to redirect dom0 root pool to an external HD.

I’m trying to find where the pool param is defined.

Drilling down in the file system I see:
/dev/qubes_dom0
There’s a symlink called “root”. That links to …/dm-4.
There’s a bunch of symlinks for the appVms that link to …/dm-###

Okay, so can I assume that the files for appVms and dom0 are found on …/dm directory?

And if I symlinked the entire …/dm directory to the external HD drive, dom0 would now be piping all hd writes/reads to the external HD?

(I’m trying to access .dm. I can’t seem to get to it using a explorer with root privileges? Is there something I’m missing?)

it the linux hidden folder (every file and folder with . (dot) before the name is hidden)

Ya, I have “show hidden” enabled. I see the other hidden folders… I see plenty of redirects to .dm-### in the /dev & the /mapper directory. I just can’t seem to find the parent of .dm

I’m guessing the key to get a mirrored os on the usb HD drive is binding the .dm parent directory to the usb HD?

Maybe another approach… Wouldn’t it be possible to copy/move the dom0 root pool LV to your external HD (offline, via a LiveUSB). Double check the UUID’s and adjust /etc/fstab and /etc/crypttab if necessary.
Then re-install grub

just thinking out loud here, no experience.
(if you do choose this approach, would you mind keeping notes and sharing them as I want to do something similar and I have no idea how (and low priority atm)).

What I would like to do when I have the time, is make some kind or raid for my SSD’s, but instead of having a ‘hot’ raid with lots of read/write operations that wear both SSD’s down at the same rate… I want a ‘cold’ raid where one SSD wears down normally and the other get’s used once every month or so.

  • with ‘hot’ raid I mean a normal raid1 setup
  • with ‘cold’ raid I mean duplicate the dom0 pool on other PV2, make dual-boot, create snapshot only run dom0 on PV1 storing changes in snapshot. Once a month copy snapshot to PV2, merge snapshots, and start a new one on PV1.

Maybe merging the snapshots is not necessary… maybe we can have snapshots after snapshot after snapshot, like:
PV1: [snapshotted dom0][October’s snapshot][November’s snapshot][current snapshot]
PV2: [snapshotted dom0][October’s snapshot][November’s snapshot]
And in January I start a new snapshot on PV1 and copy [December’s snapshot] to PV2
That way I extend the lifetime of PV2, and if PV1 fails, I’m only one month’s updates behind.

But as I said… no experience here. I used to do something similar in Ubuntu a decade ago… but that was on partition-levels (pre LVS), and back then I didn’t use LUKS.

while doing something else I was thinking… why don’t I install a second qubes-os on the second SSD… and boot (or chroot) it once a month to update dom0? No need to mess with snapshots that way…
@Emily not sure if reinstalling qubes on your external HD would give you what you’re looking for…

1 Like

I’m testing a few approaches. We’ll see what wins out.
I’m looking for the most seemless way to swap from the over layer Qubes environment reading/writing to the primary HD to a hidden layer Qubes environment reading/writing to another location on an external HD.

…Ideally be able to swap from overt to hidden on the fly by firing a script without rebooting.

Somewhere in there is a config param that defines Qubes root storage pool.

If could somehow copy all Qubes root folders to a Veracrypt hidden vault, change the storage pool param in the Veracrypt vault, then bind the root folder to the Veracrypt vault, I think that would give me an on the fly ghost layer.

Question is where is the top level config param defining where Qubes read/writes downstream?

That’s way above my head… but I would love to see your approach with some pointers of the solution you will find. Will be handy and useful to others!
Have fun! :smiley:

From redhat documentation :

  • The devices in /dev/mapper are created early in the boot process. Use these devices to
    access the multipathed devices, for example when creating logical volumes.
  • Any devices of the form /dev/dm-n are for internal use only and should never be used.

According to your problem this is possible to do, if you read my guide about detached boot partition, you may get some hint when configuring disk.

What you need to learn is, bootloader, initramfs, fstab, crypttab.

1 Like