Can someone please walk me through this entire process in even more detail and explain exactly what I need to do? It’s still too difficult for me to get this process started, and I’m not sure how to make the switch. Otherwise, if it doesn’t work, I won’t have any internet access later on.
Enter this in the Dom0 terminal
sudo lvresize --size 40G /dev/qubes_dom0/root
sudo resize2fs /dev/mapper/qubes_dom0-root
What exactly happens next?
What do I need to do next?
Hopefully someone will chime in with an easy, safe, noninvasive solution. I suspect though there is risk of data loss in resizing dom0-root unless there is substantial unused space after the partition, which seems unlikely, as by default the Qubes installer assigns a purpose to all space on your drive.
In your shoes what I would do (what I have done) is run a full backup of the system to separate storage, reinstall Qubes, and then restore the backup. During the reinstallation you have a chance to set the size of dom0 to 40G (from the default 20G). It is tedious, but safe.
Yes, I just did a full backup of about 4 TB, so I’d really like to change all of that now.
Is there some way to do this with the Qubes installer, except for manual partition setup? I do not think I found a simple method.
Edited to delete possibly wrong OT.
Yes, the installer has an integrated partitioning GUI and can also call out to blivet-gui for more advanced stuff. It’s been months since I tried it but @Melanie you shouldn’t need to shell out to a terminal to make dom0-root 40GB, it should just be: click a few things, change a 20 to a 40, press apply/refresh/whatever.
It depends on whether you’re shrinking the volume or extending it.
If you know that you are extending you’re pretty much safe. To be even more confident you could replace lvresize with lvextend and compare current volume size (sudo lvdisplay /dev/qubes_dom0/root, displayed as “LV Size”) with free space available in the volume group (sudo vgdisplay qubes_dom0, displayed as “Free PE / Size”). If volume group has enough free space to get the root volume to 40 GiB it will work.
Another precaution you could take is to ensure your filesystem is ext (resize2fs resizes ext filesystems). See “Type” in the output of df -hT /dev/mapper/qubes_dom0-root.
sudo lvextend --size 40G /dev/qubes_dom0/root resizes the volume up to the specified size.
sudo resize2fs /dev/mapper/qubes_dom0-root resizes the filesystem on the volume up to the size of the volume. On modern kernels it extends even currently mounted filesystems.
You don’t need to do anything next, at this point usable space have been extended. Use it, I guess?
If you’re shrinking it’s both more risky and more involved. I’ll write a lot but even that is omitting plenty, ask if not sure. First, check information on filesystem on the volume:
$ df -hT /dev/mapper/qubes_dom0-root
Filesystem Type Size Used Avail Use% Mounted on
/dev/mapper/qubes_dom0-root ext4 60G 11G 48G 18% /
In the output you are first interested in the filesystem type - this will determine the process of shrinking the filesystem. I’ll make an assumption that you have ext4 from now on, but you must not follow if it is not - search for the process applicable to your filesystem.
Next most important thing is Size and Avail. In this example total filesystem size is 60G, 48G of which is unused - this is enough to shrink total size to 40G.
resize2fs cannot shrink mounted filesystems. There are various workarounds for this but they might be complicated for you… Try searching around on this yourself, perhaps you find them better than booting a live OS. If you choose to use a live filesystem, download anything you feel familiar with, like debian live image for example, write it to a USB stick as usual and reboot into it.
I also must add that using a live OS has considerable security implications. Use only if you trust it and know how to use it without undermining security.
Once booted, assuming your Qubes OS drive is encrypted, you must decrypt it. We have documentation on this: How to mount a Qubes partition from another OS — Qubes OS Documentation but it is very limited (and also cryptsetup syntax is old but should work??). You only need the decryption step, perhaps followed by pvscan/vgscan/lvscan if live system doesn’t detect lvm structure autmatically. Another possible problem is live system may not have lvm installed, but I’ll leave lvm installation up to the system documentation.
After booting up live system and unlocking Qubes drive you need to locate the volume again, which should be easy - see “LV path” in the output of sudo lvdisplay qubes_dom0/root.
Once there, you can shrink. I would advise shrinking to a bit less than 40G at first (if you have enough file system free space) - this saves you from figuring out the exact size lvresize is going to shrink the volume to in the next step. After that you can resize the volume and extend the filesystem back to the size of the volume. For example:
$ sudo resize2fs <path_to_lv> 35G
$ sudo lvresize --size 40G <path_to_lv>
$ sudo resize2fs <path_to_lv>
Replace <path_to_lv> above with the path you get from “LV path” in the previous step.
That’s it, you can reboot back into Qubes after this.
Thanks, that change just went very smoothly—I thought it would be harder.
For about 3 weeks now, the second line has been showing this:
UUID=3 /boot 165.5 MB free 82%
Is that still correct?
What second line?
There’s a second line right below this message—that’s the one I’m talking about!
Xfce 4 Mount Extension - Devices and Mount Points
Looks okay for a boot partition