qubes-dom0-update template reinstallation option

[adrelanos]

qubes-dom0-update currently excludes qubes-template-* packages.

• https://github.com/marmarek/qubes-core-admin-linux/blob/6c7443223bb13348da1f3ff20d3dc1fec19073d6/dom0-updates/qubes-dom0-update#L26
• https://github.com/marmarek/qubes-core-admin-linux/blob/master/dom0-updates/qubes-dom0-update
• unconfigureable TEMPLATE_EXCLUDE_OPTS variable

This makes template reinstallation instructions more difficult than possible.

Feature request:
Please add an option to qubes-dom0-update to allow template reinstallation.

Related mailing list discussion:
Is there a standard procedure to reinstall whonix?

[adrelanos]

marmarek/qubes-core-admin-linux#2 would allow TEMPLATE_EXCLUDE_OPTS=--tolerant qubes-dom0-update qubes-template-whonix-gw. (--tolerant just as dummy option to fill the variable.) Not pretty, not great.

[adrelanos]

marmarek/qubes-core-admin-linux#2 would allow TEMPLATE_EXCLUDE_OPTS=--tolerant qubes-dom0-update qubes-template-whonix-gw. (--tolerant just as dummy option to fill the variable.) Not pretty, not great.

[adrelanos]

Lets's forget about marmarek/qubes-core-admin-linux#2 and pretend it never happened. ;)

[adrelanos]

Lets's forget about marmarek/qubes-core-admin-linux#2 and pretend it never happened. ;)

[marmarek]

Generally this is just another problem with packaging templates as RPMs. Package manager want to have newest available version, but updating template at template package level will rollback all the changes / updates installed already there. This is why templates are excluded.
But as you've pointed out, there are cases when it would be useful to update/reinstall template package.
We need some better way of shipping templates... Or a consistent workflow how to handle RPM templates.

[marmarek]

Generally this is just another problem with packaging templates as RPMs. Package manager want to have newest available version, but updating template at template package level will rollback all the changes / updates installed already there. This is why templates are excluded.
But as you've pointed out, there are cases when it would be useful to update/reinstall template package.
We need some better way of shipping templates... Or a consistent workflow how to handle RPM templates.

[adrelanos]

To solve that, I propose qubes-template-manager (QTM) cli tool #2064.

And to solve this very ticket, I suggest adding a --no-exclude option to qubes-dom0-update.

[adrelanos]

To solve that, I propose qubes-template-manager (QTM) cli tool #2064.

And to solve this very ticket, I suggest adding a --no-exclude option to qubes-dom0-update.

[marmarek]

Maybe better --no-template-exclude?

[marmarek]

Maybe better --no-template-exclude?

[tasket]

I've already tested the basic reinstall mechanics on a fedora minimal template I altered so it was unbootable. I simply removed the exclusion from qubes-dom0-update. It seems to do its job: no funky problems with files or menu entries.

For implementation, my preference would be to check for the appropriate parameter (--action=reinstall or whatever) in qubes-dom0-update before adding qubes-template-* to the exclusion string.

The other check I would perform is to make sure no running vms are based on that template.

As for the actual option name, I'd prefer to use --action=reinstall if this use case were common and repetitive. In that case it would be better to strive for more elegant expressions. However, for something like this that is a bit rare and impacts possibly many vms, going for explicitness and requiring --no-template-exclude in tandem with --action=reinstall may be best.

But adding the explicit option means you will have to handle the condition(s) that the user specifies it without --action=reinstall, or no template package name, etc.. It means creating conditions we may not catch.

[tasket]

I've already tested the basic reinstall mechanics on a fedora minimal template I altered so it was unbootable. I simply removed the exclusion from qubes-dom0-update. It seems to do its job: no funky problems with files or menu entries.

For implementation, my preference would be to check for the appropriate parameter (--action=reinstall or whatever) in qubes-dom0-update before adding qubes-template-* to the exclusion string.

The other check I would perform is to make sure no running vms are based on that template.

As for the actual option name, I'd prefer to use --action=reinstall if this use case were common and repetitive. In that case it would be better to strive for more elegant expressions. However, for something like this that is a bit rare and impacts possibly many vms, going for explicitness and requiring --no-template-exclude in tandem with --action=reinstall may be best.

But adding the explicit option means you will have to handle the condition(s) that the user specifies it without --action=reinstall, or no template package name, etc.. It means creating conditions we may not catch.

[tasket]

Another step I'd perform is to do a lock just before dom0 yum is run, to prevent vms from starting while an existing template is being reinstalled (don't want vms based on that template to start during the procedure).

[tasket]

Another step I'd perform is to do a lock just before dom0 yum is run, to prevent vms from starting while an existing template is being reinstalled (don't want vms based on that template to start during the procedure).

[tasket]

Here's a patch for testing it: QubesOS/qubes-core-admin-linux@master...ttasket:patch-1

It works but doesn't have sanity checks yet.

If I do a reinstall while a dependent appvm is running, yum says that a "volatile.img already exists. not overriding." Then "warning %post ... scriptlet failed, exit status 1" and "non-fatal POSTIN scriptlet failure in rpm package". VM keeps working and when I restart it, its back to original root image.

[tasket]

Here's a patch for testing it: QubesOS/qubes-core-admin-linux@master...ttasket:patch-1

It works but doesn't have sanity checks yet.

If I do a reinstall while a dependent appvm is running, yum says that a "volatile.img already exists. not overriding." Then "warning %post ... scriptlet failed, exit status 1" and "non-fatal POSTIN scriptlet failure in rpm package". VM keeps working and when I restart it, its back to original root image.

[marmarek]

It should be possible to reinstall (rpm) template while AppVMs based on it are running. The important part is to not modify root.img (or other *.img) but unlink old ones and create new ones in place. Not sure what rpm does, but I guess it behaves exactly this way.

[marmarek]

It should be possible to reinstall (rpm) template while AppVMs based on it are running. The important part is to not modify root.img (or other *.img) but unlink old ones and create new ones in place. Not sure what rpm does, but I guess it behaves exactly this way.

[tasket]

Rpm and dpkg and others generally adhere to the unix tradition of 'unlink first' to avoid conflicts and corruption at runtime.

I re-installed the same template again:

1. The inode number for root.img changed, so it was unlinked cleanly
2. Same POSTIN 'failure' appeared, with vms not running this time
3. The private.img inode was unchanged.. the rpm package is not trying to replace it

Number 3 is definitely a problem. Is this an rpm install script issue?

[tasket]

Rpm and dpkg and others generally adhere to the unix tradition of 'unlink first' to avoid conflicts and corruption at runtime.

I re-installed the same template again:

1. The inode number for root.img changed, so it was unlinked cleanly
2. Same POSTIN 'failure' appeared, with vms not running this time
3. The private.img inode was unchanged.. the rpm package is not trying to replace it

Number 3 is definitely a problem. Is this an rpm install script issue?

[marmarek]

I guess private.img is not recreated at all:
https://github.com/QubesOS/qubes-linux-template-builder/blob/master/templates.spec#L81-L88

As for volatile.img, it should just work if the script would remove it before recreating:
https://github.com/QubesOS/qubes-linux-template-builder/blob/master/templates.spec#L74

But there is another potential problem. The script will try to start the template (which in itself isn't a problem):
https://github.com/QubesOS/qubes-linux-template-builder/blob/master/templates.spec#L120-L129
But it changes netvm to none for that (which is still fine) and then change back to default, not the one originally set there. This would be fine if that would be initial installation, but for reinstall, this means netvm will be changed (will be a problem for Whonix templates).

[marmarek]

I guess private.img is not recreated at all:
https://github.com/QubesOS/qubes-linux-template-builder/blob/master/templates.spec#L81-L88

As for volatile.img, it should just work if the script would remove it before recreating:
https://github.com/QubesOS/qubes-linux-template-builder/blob/master/templates.spec#L74

But there is another potential problem. The script will try to start the template (which in itself isn't a problem):
https://github.com/QubesOS/qubes-linux-template-builder/blob/master/templates.spec#L120-L129
But it changes netvm to none for that (which is still fine) and then change back to default, not the one originally set there. This would be fine if that would be initial installation, but for reinstall, this means netvm will be changed (will be a problem for Whonix templates).

[tasket]

Should we mv the private.img to backup file before processing it?

I'm unfamiliar with the parameter handling here, but some of the logic looks tentative with a reference to "upgrading template" in the %pre section.

[tasket]

Should we mv the private.img to backup file before processing it?

I'm unfamiliar with the parameter handling here, but some of the logic looks tentative with a reference to "upgrading template" in the %pre section.

[marmarek]

As for private.img - mv to backup is a good idea.
As for parameter handling in RPM, see here: http://www.rpm.org/max-rpm/s1-rpm-inside-scripts.html

[marmarek]

As for private.img - mv to backup is a good idea.
As for parameter handling in RPM, see here: http://www.rpm.org/max-rpm/s1-rpm-inside-scripts.html

[tasket]

Where to put the backup? If just private.img-bak in the same folder, then we end up with a big lump that could sit there forgotten, taking up space. If it does get moved as a backup, it should be in a place that's very visible to the user, like their home folder.

Alternative is to make deletion of the old img standard and issue a warning.

[tasket]

Where to put the backup? If just private.img-bak in the same folder, then we end up with a big lump that could sit there forgotten, taking up space. If it does get moved as a backup, it should be in a place that's very visible to the user, like their home folder.

Alternative is to make deletion of the old img standard and issue a warning.

[marmarek]

Maybe you're right about its deletion. Old root.img is lost by design, so indeed removing private.img too seems logical.

[marmarek]

Maybe you're right about its deletion. Old root.img is lost by design, so indeed removing private.img too seems logical.

[tasket]

Two PRs for testing:
QubesOS/qubes-core-admin-linux#7
QubesOS/qubes-linux-template-builder#1

[tasket]

Two PRs for testing:
QubesOS/qubes-core-admin-linux#7
QubesOS/qubes-linux-template-builder#1

[tasket]

@marmarek This version currently works: https://github.com/ttasket/qubes-core-admin-linux/blob/ttasket-patch-1/dom0-updates/qubes-dom0-update
However, it still leaves private.img in place (old %post script?). Maybe we could have qubes-dom0-update handle that, too?

[tasket]

@marmarek This version currently works: https://github.com/ttasket/qubes-core-admin-linux/blob/ttasket-patch-1/dom0-updates/qubes-dom0-update
However, it still leaves private.img in place (old %post script?). Maybe we could have qubes-dom0-update handle that, too?

[marmarek]

patch-1/dom0-updates/qubes-dom0-update
However, it still leaves private.img in place (old %post script?). Maybe we could have qubes-dom0-update handle that, too?

Yes, good idea.

[marmarek]

patch-1/dom0-updates/qubes-dom0-update
However, it still leaves private.img in place (old %post script?). Maybe we could have qubes-dom0-update handle that, too?

Yes, good idea.

[tasket]

That conditional in %post means the private.img won't get regenerated, though. Maybe there is a way to make yum use the new scriptlets instead?

[tasket]

That conditional in %post means the private.img won't get regenerated, though. Maybe there is a way to make yum use the new scriptlets instead?

[tasket]

OK, simplest way forward is to have qubes-dom0-update check for private.img an re-create it if missing...
PR tasket/qubes-core-admin-linux#2

[tasket]

OK, simplest way forward is to have qubes-dom0-update check for private.img an re-create it if missing...
PR tasket/qubes-core-admin-linux#2

[tasket]

I also noticed %post does 'exit 1' because volatile.img is already there; want to add rm -f for volatile.img before calling yum.

[tasket]

I also noticed %post does 'exit 1' because volatile.img is already there; want to add rm -f for volatile.img before calling yum.

[tasket]

New PR with fixes tasket/qubes-core-admin-linux#3
Works well for me. You guys can start testing it.

[tasket]

New PR with fixes tasket/qubes-core-admin-linux#3
Works well for me. You guys can start testing it.

[marmarek]

Thanks!

[marmarek]

Thanks!

[tasket]

I just noticed, if yum exits then template is left without volatile.img, but it gets re-created when you run the template vm. If this is not OK, I'll handle volatile just like the other img files so it can be restored on error.

[tasket]

I just noticed, if yum exits then template is left without volatile.img, but it gets re-created when you run the template vm. If this is not OK, I'll handle volatile just like the other img files so it can be restored on error.

[marmarek]

Automated announcement from builder-github

The package qubes-core-dom0-linux-3.2.4-1.fc23 has been pushed to the r3.2 testing repository for dom0.
To test this update, please install it with the following command:

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

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-core-dom0-linux-3.2.4-1.fc23 has been pushed to the r3.2 testing repository for dom0.
To test this update, please install it with the following command:

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

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-core-dom0-linux-3.1.12-1.fc20 has been pushed to the r3.1 testing repository for dom0.
To test this update, please install it with the following command:

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

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-core-dom0-linux-3.1.12-1.fc20 has been pushed to the r3.1 testing repository for dom0.
To test this update, please install it with the following command:

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

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-core-dom0-linux-3.1.12-1.fc20 has been pushed to the r3.1 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-core-dom0-linux-3.1.12-1.fc20 has been pushed to the r3.1 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-core-dom0-linux-3.2.5-1.fc23 has been pushed to the r3.2 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-core-dom0-linux-3.2.5-1.fc23 has been pushed to the r3.2 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update