Skip to content
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.

Sign up for GitHub

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

Jump to bottom

livefs - rolling back to pre-live applied commit seems wrong #802

Closed
dustymabe opened this issue May 28, 2017 · 8 comments
Closed

livefs - rolling back to pre-live applied commit seems wrong #802

dustymabe opened this issue May 28, 2017 · 8 comments
Labels
kind/enhancement

Comments

@dustymabe
Copy link
Member

I don't think the rollback behavior with livefs is quite what we want. We are able to get the system into a state where we actually 'rollback' to a livecommit. My understanding is that livecommits should only really be used for the duration of the boot in which they were applied, but I could be wrong.

Starting from an image based on 25.127 (cdd359911de49f3a8199ffd41a9894019562001d6cf9be66e1894c31b6fa1c66) I did the following to update to testing branch with newer version of rpm-ostree:

$ sudo rpm-ostree rebase fedora-atomic/25/x86_64/testing/docker-host
$ reboot
$ rpm-ostree status
State: idle
Deployments:
● fedora-atomic:fedora-atomic/25/x86_64/testing/docker-host
                Version: 25.140 (2017-05-28 07:39:08)
                 Commit: 4ac6627d1f8055414b14cdbfdebd049259f567dbc7524cb47ca7eda29a3580da

  fedora-atomic:fedora-atomic/25/x86_64/docker-host
                Version: 25.127 (2017-05-19 21:57:03)
                 Commit: cdd359911de49f3a8199ffd41a9894019562001d6cf9be66e1894c31b6fa1c66

$ sudo rpm-ostree install fuse-sshfs
...
Overlaying... done
Writing rpmdb... done
Writing OSTree commit... done
Copying /etc changes: 24 modified, 0 removed, 58 added
Transaction complete; bootconfig swap: yes deployment count change: 0
Freed objects: 250.6 MB
Added:
  fuse-sshfs-2.8-1.fc25.x86_64
Run "systemctl reboot" to start a reboot
$ rpm-ostree status
State: idle
Deployments:
  fedora-atomic:fedora-atomic/25/x86_64/testing/docker-host
                Version: 25.140 (2017-05-28 07:39:08)
             BaseCommit: 4ac6627d1f8055414b14cdbfdebd049259f567dbc7524cb47ca7eda29a3580da
        LayeredPackages: fuse-sshfs

● fedora-atomic:fedora-atomic/25/x86_64/testing/docker-host
                Version: 25.140 (2017-05-28 07:39:08)
                 Commit: 4ac6627d1f8055414b14cdbfdebd049259f567dbc7524cb47ca7eda29a3580da
$ sudo rpm-ostree ex livefs
notice: "livefs" is an experimental command and subject to change.
Diff Analysis: 4ac6627d1f8055414b14cdbfdebd049259f567dbc7524cb47ca7eda29a3580da => fef827690932652eabff56573832f64a49d2225958b657354b716cadbe8704fa
Files:
 modified: 0
 removed: 0
 added: 6
Packages:
 modified: 0
 removed: 0
 added: 1
Preparing new rollback matching currently booted deployment
Copying /etc changes: 24 modified, 0 removed, 58 added
Transaction complete; bootconfig swap: yes deployment count change: 1
Overlaying /usr... done
$ rpm-ostree status
State: idle
Deployments:
  fedora-atomic:fedora-atomic/25/x86_64/testing/docker-host
                Version: 25.140 (2017-05-28 07:39:08)
             BaseCommit: 4ac6627d1f8055414b14cdbfdebd049259f567dbc7524cb47ca7eda29a3580da
                 Commit: fef827690932652eabff56573832f64a49d2225958b657354b716cadbe8704fa
        LayeredPackages: fuse-sshfs

● fedora-atomic:fedora-atomic/25/x86_64/testing/docker-host
                Version: 25.140 (2017-05-28 07:39:08)
           BootedCommit: 4ac6627d1f8055414b14cdbfdebd049259f567dbc7524cb47ca7eda29a3580da
             LiveCommit: fef827690932652eabff56573832f64a49d2225958b657354b716cadbe8704fa

  fedora-atomic:fedora-atomic/25/x86_64/testing/docker-host
                Version: 25.140 (2017-05-28 07:39:08)
                 Commit: 4ac6627d1f8055414b14cdbfdebd049259f567dbc7524cb47ca7eda29a3580da
$ rpm -q fuse-sshfs
fuse-sshfs-2.8-1.fc25.x86_64

Then reboot:

$ sudo rpm-ostree status
State: idle
Deployments:
● fedora-atomic:fedora-atomic/25/x86_64/testing/docker-host
                Version: 25.140 (2017-05-28 07:39:08)
             BaseCommit: 4ac6627d1f8055414b14cdbfdebd049259f567dbc7524cb47ca7eda29a3580da
                 Commit: fef827690932652eabff56573832f64a49d2225958b657354b716cadbe8704fa
        LayeredPackages: fuse-sshfs

  fedora-atomic:fedora-atomic/25/x86_64/testing/docker-host
                Version: 25.140 (2017-05-28 07:39:08)
           BootedCommit: 4ac6627d1f8055414b14cdbfdebd049259f567dbc7524cb47ca7eda29a3580da
             LiveCommit: fef827690932652eabff56573832f64a49d2225958b657354b716cadbe8704fa

  fedora-atomic:fedora-atomic/25/x86_64/testing/docker-host
                Version: 25.140 (2017-05-28 07:39:08)
                 Commit: 4ac6627d1f8055414b14cdbfdebd049259f567dbc7524cb47ca7eda29a3580da
$ rpm -q fuse-sshfs
fuse-sshfs-2.8-1.fc25.x86_64

Then rollback:

$ sudo rpm-ostree rollback
Moving '4ac6627d1f8055414b14cdbfdebd049259f567dbc7524cb47ca7eda29a3580da.0' to be first deployment
Transaction complete; bootconfig swap: no deployment count change: 0
Removed:
  fuse-sshfs-2.8-1.fc25.x86_64
Run "systemctl reboot" to start a reboot
$ rpm-ostree status
State: idle
Deployments:
  fedora-atomic:fedora-atomic/25/x86_64/testing/docker-host
                Version: 25.140 (2017-05-28 07:39:08)
           BootedCommit: 4ac6627d1f8055414b14cdbfdebd049259f567dbc7524cb47ca7eda29a3580da
             LiveCommit: fef827690932652eabff56573832f64a49d2225958b657354b716cadbe8704fa

● fedora-atomic:fedora-atomic/25/x86_64/testing/docker-host
                Version: 25.140 (2017-05-28 07:39:08)
             BaseCommit: 4ac6627d1f8055414b14cdbfdebd049259f567dbc7524cb47ca7eda29a3580da
                 Commit: fef827690932652eabff56573832f64a49d2225958b657354b716cadbe8704fa
        LayeredPackages: fuse-sshfs

  fedora-atomic:fedora-atomic/25/x86_64/testing/docker-host
                Version: 25.140 (2017-05-28 07:39:08)
                 Commit: 4ac6627d1f8055414b14cdbfdebd049259f567dbc7524cb47ca7eda29a3580da

after reboot:

$ sudo rpm-ostree status
State: idle
Deployments:
● fedora-atomic:fedora-atomic/25/x86_64/testing/docker-host
                Version: 25.140 (2017-05-28 07:39:08)
           BootedCommit: 4ac6627d1f8055414b14cdbfdebd049259f567dbc7524cb47ca7eda29a3580da
             LiveCommit: fef827690932652eabff56573832f64a49d2225958b657354b716cadbe8704fa

  fedora-atomic:fedora-atomic/25/x86_64/testing/docker-host
                Version: 25.140 (2017-05-28 07:39:08)
             BaseCommit: 4ac6627d1f8055414b14cdbfdebd049259f567dbc7524cb47ca7eda29a3580da
                 Commit: fef827690932652eabff56573832f64a49d2225958b657354b716cadbe8704fa
        LayeredPackages: fuse-sshfs

  fedora-atomic:fedora-atomic/25/x86_64/testing/docker-host
                Version: 25.140 (2017-05-28 07:39:08)
                 Commit: 4ac6627d1f8055414b14cdbfdebd049259f567dbc7524cb47ca7eda29a3580da
$ 
$ rpm -q fuse-sshfs
fuse-sshfs-2.8-1.fc25.x86_64
@cgwalters
Copy link
Member

A definite general problem we have with rollback is knowing what's going to happen. That problem is certainly worse with livefs. I don't have any good ideas right now.

We could perhaps tweak rollback to prefer rolling back to a non-livefs commit?

But why were you rolling back? Just playing with it?

@jlebon
Copy link
Member

jlebon commented May 30, 2017

Or should the livefs commit just not be in the bootloader at all? I think we toyed with the idea a bit during discussions, and the issue is that it'd require breaking that assumption that len(deployment) == len(bootloader entries), which would be tricky. But OTOH, it would fit pretty well the use case here.

Essentially, in the workflow we're establishing, do we even want users to be able to reboot into livefs deployments? Or should we emphasize the fact that they're temporary until you're ready to upgrade?

@dustymabe
Copy link
Member Author

Is it possible to have deployments have sub-deployments? i.e. a base commit can have a package layered sub-commit and also a live-applied version of that sub-commit?

I would definitely propose that live commits are never booted into and basically are just "live versions" of the staged deployment for next boot. We should also make sure that any future actions to the live commit also make it back into an actual real staged deployment. i.e. a live-commit always has a 'real deployment' partner.

@cgwalters
Copy link
Member

We had a quick discussion about this, and I think everyone agreed that we should avoid booting into something that shows "live modified". (However we implement that - separating the deployment/bootloader entries would be one)

@dustymabe dustymabe mentioned this issue Nov 8, 2017
Closed
@jlebon jlebon mentioned this issue Jul 18, 2018
Closed
@cgwalters
Copy link
Member

Or should the livefs commit just not be in the bootloader at all? I think we toyed with the idea a bit during discussions, and the issue is that it'd require breaking that assumption that len(deployment) == len(bootloader entries), which would be tricky.

We did break that assumption with deployment staging; but I'm not following your proposed implementation here. The booted deployment is in the bootloader entries, so...we'd need to either do a dynamic mount, or remove it from the entries right?

Were you thinking of something like applying the livefs changes to an overlayfs?

@jlebon
Copy link
Member

jlebon commented Jul 23, 2018

Right, we'd still write to the bootloader, but we simply omit the booted (now live) deployment. Before staging, this meant: after ex livefs, write bootloader with only the pending deployment and the safety rollback deployment. Now that we have staging, this complicates things a bit since the pending deployment isn't even in the bootloader yet. So I think something like this could work:

  • during ex livefs, only write to bootloader the safety rollback and original rollback
  • if interrupted, we still get the "same" two deployments as before livefs ("same" in quotations since the safety rollback is technically a reconstructed one)
  • at shutdown, finalize staged, and write to bootloader only the staged and safety rollback -- this means we end up with the exact same checksum entries as if we hadn't done livefs during that session

@jlebon
Copy link
Member

jlebon commented Nov 26, 2020

Closing as stale with the new livefs implementation (#2293).

@jlebon jlebon closed this as completed Nov 26, 2020
@jlebon
Copy link
Member

jlebon commented Nov 26, 2020

(That implementation doesn't touch the bootloader at all.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
kind/enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@cgwalters @dustymabe @jlebon