[Discuss] --sandbox switch for Ubuntu's do-release-upgrade/update-manager

[tmetro+blu at gmail.com (Tom Metro)]

I was looking to do a "dry run" test with do-release-upgrade to see if a
system could successfully be upgraded from 12.04 to 14.04 after some
changes had been made. (An earlier attempted failed to map packages from
the old release to the new release.)

do-release-upgrade doesn't have a dry run option, but does have a
--sandbox option, which is tersely documented[1] as:

"Test upgrade with a sandbox aufs overlay"

OK...but that leaves a lot of unanswered questions.

Anyone used this feature?

I searched but couldn't find any more in-depth documentation, or a wiki
page. All I could turn up were oblique references to --sandbox, such as
bug reports of it not working[2][3].

I did find a tangential comment[4] in a stack exchange Q&A asking
whether it was better to use 'apt-get dist-upgrade' or
do-release-upgrade, which said, "do-release-upgrade has some other cool
features, like --sandbox, which remounts your filesystems with aufs so
that the upgrade can be rolled back!"

OK, so how do you roll it back?

Another blog posting[5] says, "Simply just run 'do-release-upgrade -s'
to sandbox the upgrade. From that point any changes made to your system
will actually be written to a ramdisk, and reset upon reboot via the
magic os Aufs. This lets you test your machine thoroughly in a fully
functioning state, without risking breaking it."

So how do you "test" an OS upgrade if you can't reboot to the new OS
version? (Use of RAM disk also seems unlikely.)

Eventually I ran across a 2009 mailing list posting describing the
option when it was first introduced:

https://lists.ubuntu.com/archives/ubuntu-devel/2009-March/027747.html

  "The idea...was to create a writable overlay into /tmp on top the
  systemdirs in "/" and then run the release upgrade. This way we can
  test easily if the system would upgrade cleanly (if no dpkg
  errors/maintainer script failures happen). All writes go into /tmp so
  after the upgrade and on the next reboot the system is back to its
  pre-upgraded state again (modulo /home, that is not overlayed)."

OK, more details. Now we know the files are stored in /tmp. But I'm
still not following why you wouldn't want to preserve this across a
reboot, and have an explicit command to roll back the upgrade.

It seems like they only care about testing the package conflict
resolution and the package installation scripts. (Half of that you can
test without even writing to the file system.) What I care about is how
badly will my alternate desktop manager be broken after an upgrade.

Digging into the Python code that implements do-release-upgrade
uncovered the 'mount' command line they use to create the AuFS[6] file
system (a derivative of UnionFS), that there are options specified via
config file to specify the location of the overlay file system (so you
could put it outside of /tmp; it defaults to /tmp/upgrade-rw), and code
to rsync the overlay filesystem back to the real file system (but
unclear what calls that code).

Using this feature with update-manager potentially addresses an idea I
brought up here previously: an apt-get that can revert an upgrade. (If
only it was a console program instead of a GUI. And it would still need
to be tweaked to persist across reboot.)

I'm wondering why this isn't better documented and promoted. I'm left
with the impression that the feature may be half-baked. Particularly due
to things like the bug report[2] suggesting that any upgrade that causes
grub to update the bootloader will fail, as the overlay FS gets in the
way. Then again if it all evaporates when you reboot, you've already
learned what you're going to learn by the time the grub update stage of
the upgrade runs.

 -Tom

1.
http://manpages.ubuntu.com/manpages/precise/man8/do-release-upgrade.8.html
2. http://osdir.com/ml/ubuntu-bugs/2014-04/msg30955.html
3. http://ubuntuforums.org/showthread.php?t=2113373
4.
http://serverfault.com/questions/322810/whats-the-difference-between-apt-get-dist-upgrade-and-do-release-upgrade
5.
http://blog.coopersphotos.co.uk/technology/two-tech-tips-sandboxing-ubuntu-ssh-configs-on-the-fly
6. http://www.thegeekstuff.com/2013/05/linux-aufs/

-- 
Tom Metro
The Perl Shop, Newton, MA, USA
"Predictable On-demand Perl Consulting."
http://www.theperlshop.com/