-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fail snapshot if snapper fails to set it as default #118
Comments
ping? |
Implementing now. |
If snapper returns with an error code an exception will be thrown, which in turn will result in the snapshot being deleted again (see https://github.com/openSUSE/transactional-update/blob/master/lib/Snapshot/Snapper.cpp). I guess the later is causing a problem because then the snapper plugins won't be executed any more? |
yes. If snapper fails but t-u still treats the snapshot as good, the snapshot may not be bootable |
For compatibility reasons (older snapper versions don't support some parameters) some snapper calls also have an alternate fallback call. With [gh#openSUSE#118] / [poo#127169] snapper can also return errors from plugins now, so only try an alternate way if snapper fails because of unsupported command line parameters.
For compatibility reasons (older snapper versions don't support some parameters) some snapper calls also have an alternate fallback call. With [gh#openSUSE#118] / [poo#127169] snapper can also return errors from plugins now, so only try an alternate way if snapper fails because of unsupported command line parameters.
Added with transactional-update 4.6.0. |
snapper now returns failures from plugins. That is important with systemd-boot. It could happen that the ESP runs out of space for example. In that case sdbootutil would fail to copy the kernel to the ESP and signal failure to snapper which in turn exits with code != 0. Transactional-update must then consider the snapshot as failed as it wouldn't boot.
The text was updated successfully, but these errors were encountered: