template reinstall not ported to Qubes 4.0 #3169

marmarek · Oct 13, 2017

Qubes OS version (e.g., `R3.2`): R4.0

Steps to reproduce the behavior:

sudo qubes-dom0-update --action=reinstall qubes-template-fedora-25

Expected behavior:

Template got reinstalled. This include preserving its properties. Technically, only root volume should be overwritten, and private volume should be cleaned.

Actual behavior:

qvm-prefs: error: no such property: 'root_img'

And generally the code heavily depends on root.img being a file, and rpm replacing it.

In general it would be nice to be able re-install or downgrade packages in dom0.

3hhh · Oct 13, 2017

In general it would be nice to be able re-install or downgrade packages in dom0.

I'm installing R4 tonight and will look into this.

tasket · Oct 19, 2017

I'm installing R4 tonight and will look into this.

Some hints:

If a backup is needed, use qvm-clone. It is cheap on LVM.
qvm-template-postprocess tool imports root.img (a file) into actual template root volume (LVM or else). Probably it needs to learn how to reinstall template (or maybe will just work in install mode?)

marmarek · Oct 19, 2017

Some hints:

If a backup is needed, use qvm-clone. It is cheap on LVM.
qvm-template-postprocess tool imports root.img (a file) into actual template root volume (LVM or else). Probably it needs to learn how to reinstall template (or maybe will just work in install mode?)

I'll be trying a fix hopefully this week.

tasket · Mar 7, 2018

I'll be trying a fix hopefully this week.

Aspects of this issue that need to be addressed:

Should not try to delete template on import_data failure when template already existed. Easily addressed in qvm_template_postprocess.py
Resizing of root volume fails when the existing one had been expanded past the default size. Possibly a security as well as functional issue. Probably there should be a qubesd function that can initialize or zero-out a volume and make this accessible from qubesadmin. Or maybe volume should be deleted and re-created on each import, but I'm not sure where to put this.

tasket · Mar 10, 2018

Aspects of this issue that need to be addressed:

Should not try to delete template on import_data failure when template already existed. Easily addressed in qvm_template_postprocess.py
Resizing of root volume fails when the existing one had been expanded past the default size. Possibly a security as well as functional issue. Probably there should be a qubesd function that can initialize or zero-out a volume and make this accessible from qubesadmin. Or maybe volume should be deleted and re-created on each import, but I'm not sure where to put this.

@tasket the second point is already tracked here: #2256 (comment)

marmarek · Mar 14, 2018

@tasket the second point is already tracked here: #2256 (comment)

And should be addressed by QubesOS/qubes-core-admin#203 - import is performed on fresh temporary volume, renamed to final name only when finished.

I'm also going to relax anti-shrink protection - move it to qvm-volume tool (GUI settings already prevent it) and allow to do that at API level (and with some option to qvm-volume, probably --force). This way, it will be possible to reinstall template and really have it in initial state.

marmarek · Mar 17, 2018

And should be addressed by QubesOS/qubes-core-admin#203 - import is performed on fresh temporary volume, renamed to final name only when finished.

I'm also going to relax anti-shrink protection - move it to qvm-volume tool (GUI settings already prevent it) and allow to do that at API level (and with some option to qvm-volume, probably --force). This way, it will be possible to reinstall template and really have it in initial state.

Thanks. This is pretty extensive.

The direction I was going was only to remove and re-create the volume in lvm.py. But I was having trouble tracking the call paths from the admin code to qubesd import_data() so that the size of the new data set could be passed to it.

BTW - The reflink.py handler appears to deal with import volume safety already, but file.py does not.

tasket · Mar 17, 2018

Thanks. This is pretty extensive.

The direction I was going was only to remove and re-create the volume in lvm.py. But I was having trouble tracking the call paths from the admin code to qubesd import_data() so that the size of the new data set could be passed to it.

BTW - The reflink.py handler appears to deal with import volume safety already, but file.py does not.

Thanks. This is pretty extensive.

Yes. This ticket is not the only reason for it (actually, importing into temporary volume could be done without all the other changes). Other thing is commit operation required multiple steps, which, if something goes wrong, can lead to data loss, or at least need for manual recovery. Extreme result was #3164.
I think the scheme I've finally implemented was proposed by @jpouellet about that time, but I can't find the reference right now.

marmarek · Mar 17, 2018

Thanks. This is pretty extensive.

Yes. This ticket is not the only reason for it (actually, importing into temporary volume could be done without all the other changes). Other thing is commit operation required multiple steps, which, if something goes wrong, can lead to data loss, or at least need for manual recovery. Extreme result was #3164.
I think the scheme I've finally implemented was proposed by @jpouellet about that time, but I can't find the reference right now.

I'm also going to relax anti-shrink protection - move it to qvm-volume tool (GUI settings already prevent it) and allow to do that at API level (and with some option to qvm-volume, probably --force).

AFAICT we could even make shrinking safe enough for the GUI, by doing the operations in reverse order. Growing a volume is currently

dom0 driver: resize backing storage
dom0 driver: resize view of backing storage (e.g. loop devices), if applicable
VM: resize partition/device-mapper table entry, if applicable
VM: resize filesystem

Shrinking would be 4, 3, 2, 1.

rustybird · Mar 17, 2018

I'm also going to relax anti-shrink protection - move it to qvm-volume tool (GUI settings already prevent it) and allow to do that at API level (and with some option to qvm-volume, probably --force).

AFAICT we could even make shrinking safe enough for the GUI, by doing the operations in reverse order. Growing a volume is currently

dom0 driver: resize backing storage
dom0 driver: resize view of backing storage (e.g. loop devices), if applicable
VM: resize partition/device-mapper table entry, if applicable
VM: resize filesystem

Shrinking would be 4, 3, 2, 1.

Problem with point 4 is that for most filesystems it can't be done while the filesystem is mounted (in contrary to extending). And for some it isn't supported at all (xfs, but in practice we care about ext4 only). This is definitely doable (for example from initramfs), but not just "doing the operations in reverse order".

BTW currently we recommend universal method for shrinking, by creating new smaller VM and moving data: https://www.qubes-os.org/doc/resize-disk-image/#shrinking-a-disk-image

marmarek · Mar 17, 2018

Problem with point 4 is that for most filesystems it can't be done while the filesystem is mounted (in contrary to extending). And for some it isn't supported at all (xfs, but in practice we care about ext4 only). This is definitely doable (for example from initramfs), but not just "doing the operations in reverse order".

BTW currently we recommend universal method for shrinking, by creating new smaller VM and moving data: https://www.qubes-os.org/doc/resize-disk-image/#shrinking-a-disk-image

Problem with point 4 is that for most filesystems it can't be done while the filesystem is mounted (in contrary to extending).

Damn, I never noticed that restriction in the resize2fs manpage. Too bad then.

rustybird · Mar 17, 2018

Problem with point 4 is that for most filesystems it can't be done while the filesystem is mounted (in contrary to extending).

Damn, I never noticed that restriction in the resize2fs manpage. Too bad then.

BTW - The reflink.py handler appears to deal with import volume safety already, but file.py does not.

Fixed here: marmarek/qubes-core-admin@f870272 (QubesOS/qubes-core-admin#206)

marmarek · Mar 19, 2018

BTW - The reflink.py handler appears to deal with import volume safety already, but file.py does not.

Fixed here: marmarek/qubes-core-admin@f870272 (QubesOS/qubes-core-admin#206)

I think we still have a problem with resizing during import, if new image is smaller:

https://github.com/QubesOS/qubes-core-admin/blob/e2b70306e558face4003b3e42e3dcedd6f31949f/qubes/api/admin.py#L470-L472

 def import_root_img(vm, source_dir):
     '''Import root.img into VM object'''
 
 
     root_size = get_root_img_size(source_dir)
     vm.volumes['root'].resize(root_size)

Won't an error get raised in lvm.py resize() if size < self.size ?

        if size < self.size:
            raise qubes.storage.StoragePoolException(
                'For your own safety, shrinking of %s is'
                ' disabled (%d < %d). If you really know what you'
                ' are doing, use `lvresize` on %s manually.' %
                (self.name, size, self.size, self.vid))


        if size == self.size:
            return


        if self.is_dirty():
            cmd = ['extend', self._vid_snap, str(size)]
            qubes_lvm(cmd, self.log)
        elif hasattr(self, '_vid_import') and \

tasket · Mar 19, 2018

I think we still have a problem with resizing during import, if new image is smaller:

https://github.com/QubesOS/qubes-core-admin/blob/e2b70306e558face4003b3e42e3dcedd6f31949f/qubes/api/admin.py#L470-L472

 def import_root_img(vm, source_dir):
     '''Import root.img into VM object'''
 
 
     root_size = get_root_img_size(source_dir)
     vm.volumes['root'].resize(root_size)

Won't an error get raised in lvm.py resize() if size < self.size ?

        if size < self.size:
            raise qubes.storage.StoragePoolException(
                'For your own safety, shrinking of %s is'
                ' disabled (%d < %d). If you really know what you'
                ' are doing, use `lvresize` on %s manually.' %
                (self.name, size, self.size, self.vid))


        if size == self.size:
            return


        if self.is_dirty():
            cmd = ['extend', self._vid_snap, str(size)]
            qubes_lvm(cmd, self.log)
        elif hasattr(self, '_vid_import') and \

You're right, working on it.

marmarek · Mar 19, 2018

You're right, working on it.

Also, is the new image size being propagated to (lvm|reflink|file).py import_data() when that function is called? I can't tell.

tasket · Mar 19, 2018

Also, is the new image size being propagated to (lvm|reflink|file).py import_data() when that function is called? I can't tell.

That's why qvm-template-postprocess calls volume.resize first.

marmarek · Mar 19, 2018

That's why qvm-template-postprocess calls volume.resize first.

I see, the size attribute gets set without doing lvextend/truncate. Makes sense now.

tasket · Mar 19, 2018

I see, the size attribute gets set without doing lvextend/truncate. Makes sense now.

PR QubesOS/qubes-core-admin-client#61

tasket · Mar 19, 2018

PR QubesOS/qubes-core-admin-client#61

--action=reinstall on qubes-template-fedora-26-minimal with qubes-core-admin-client 4.0.16 and qubes-core-dom0 4.0.24 (am I looking at the right package?) results in "VM directory does not exist: /var/lib/qubes/vm-templates/fedora-26-minimal". Are the fixes not yet in current? I see #3666 marked as a duplicate issue.

awokd · Apr 21, 2018

--action=reinstall on qubes-template-fedora-26-minimal with qubes-core-admin-client 4.0.16 and qubes-core-dom0 4.0.24 (am I looking at the right package?) results in "VM directory does not exist: /var/lib/qubes/vm-templates/fedora-26-minimal". Are the fixes not yet in current? I see #3666 marked as a duplicate issue.

Automated announcement from builder-github

The package python2-qubesadmin-4.0.17-0.1.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

QubesOS/qubes-issues

Join GitHub today

template reinstall not ported to Qubes 4.0 #3169

Comments

marmarek commented Oct 13, 2017

Qubes OS version (e.g., R3.2): R4.0

Steps to reproduce the behavior:

Expected behavior:

Actual behavior:

marmarek added bug C: core P: major labels Oct 13, 2017

marmarek added this to the Release 4.0 milestone Oct 13, 2017

This comment has been minimized.

3hhh commented Oct 13, 2017

3hhh referenced this issue Oct 13, 2017

marmarek referenced this issue Oct 19, 2017

This comment has been minimized.

tasket commented Oct 19, 2017

This comment has been minimized.

marmarek commented Oct 19, 2017

tasket referenced this issue Mar 7, 2018

This comment has been minimized.

tasket commented Mar 7, 2018

This comment has been minimized.

tasket commented Mar 10, 2018

This comment has been minimized.

marmarek commented Mar 14, 2018

This comment has been minimized.

marmarek commented Mar 17, 2018

This comment has been minimized.

tasket commented Mar 17, 2018

This comment has been minimized.

marmarek commented Mar 17, 2018

This comment has been minimized.

rustybird commented Mar 17, 2018

This comment has been minimized.

marmarek commented Mar 17, 2018

This comment has been minimized.

rustybird commented Mar 17, 2018

marmarek added a commit to marmarek/qubes-core-admin that referenced this issue Mar 19, 2018

This comment has been minimized.

marmarek commented Mar 19, 2018

This comment has been minimized.

tasket commented Mar 19, 2018

This comment has been minimized.

marmarek commented Mar 19, 2018

marmarek added a commit to marmarek/qubes-core-admin-client that referenced this issue Mar 19, 2018

marmarek added a commit to marmarek/qubes-core-admin-client that referenced this issue Mar 19, 2018

This comment has been minimized.

tasket commented Mar 19, 2018

This comment has been minimized.

marmarek commented Mar 19, 2018

This comment has been minimized.

tasket commented Mar 19, 2018

tasket referenced this issue in QubesOS/qubes-core-admin-client Mar 19, 2018

This comment has been minimized.

tasket commented Mar 19, 2018

marmarek added a commit to marmarek/qubes-core-admin-client that referenced this issue Mar 19, 2018

marmarek added a commit to marmarek/qubes-core-admin-client that referenced this issue Mar 19, 2018

This was referenced Mar 19, 2018

marmarek added a commit to marmarek/qubes-core-admin that referenced this issue Mar 21, 2018

qubesos-bot referenced this issue in QubesOS/updates-status Mar 21, 2018

qubesos-bot referenced this issue in QubesOS/updates-status Mar 29, 2018

andrewdavidwong modified the milestones: Release 4.0, Release 4.0 updates Mar 31, 2018

This comment has been minimized.

awokd commented Apr 21, 2018

marmarek closed this in marmarek/qubes-core-admin-client@c75c017 Apr 21, 2018

This comment has been minimized.

qubesos-bot commented Apr 21, 2018

qubesos-bot added the r4.0-dom0-cur-test label Apr 21, 2018

qubesos-bot referenced this issue in QubesOS/updates-status Apr 21, 2018

qubesos-bot added r4.0-buster-cur-test r4.0-jessie-cur-test labels Apr 21, 2018

This comment has been minimized.

qubesos-bot commented Apr 21, 2018

qubesos-bot added the r4.0-fc26-cur-test label Apr 21, 2018

This comment has been minimized.

qubesos-bot commented Apr 21, 2018

qubesos-bot added the r4.0-stretch-cur-test label Apr 21, 2018

This comment has been minimized.

awokd commented Apr 21, 2018

This comment has been minimized.

Qubes OS version (e.g., `R3.2`): R4.0

marmarek closed this in `marmarek/qubes-core-admin-client@c75c017` Apr 21, 2018