Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On 03/09/2015 11:50 AM, Tom Metro wrote:
> 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.)

Sorry, no help w.r.t. to question you asked, but it reminded me of a
related issue.  I remember wanting to do something similar, but thinking
that LVM snapshots were the way to go.  The issue for non-virtualized
servers for me was typically a problem because of my
small-scale/hobbyist scenario: you need a working system to roll back
the snapshots, but rolling back the root fs was especially tricky.  What
this meant was using rescue disks, and the rescue disks had to have the
right version of LVM to allow you to roll back to the older snapshot.
And I had long since gotten out of the habit of burning media for every
OS upgrade... And then you had the whole boot-loader issue, which could
be managed (/boot isn't so big that you couldn't just stuff it somewhere
for manual reconstitution, but again you need to boot into a rescue
environment for that).

I think it makes more sense if you've got a VM.  I think (it was a while
ago, forgive my foggy memory) I successfully used qcow2's snapshotting
for this sort of roll-back scenario.

With btrfs the situation might be better, since you can more easily
define the mount points for directly interacting with snapshots.  For
instance, you could have a grub config that booted the old kernel using
the snapshot from the old fs.

The trick is still that all upgrades try to "fix" your boot loader
config by removing the old stuff.  If you're careful and have a big
/boot, you could hide everything needed for the old system, and
reconstitute it (and manually edit grub.conf) after the upgrade is
complete but before it reboots into the new system.  There may be other
little gotchas like needing to reformat your swap, but that's easy
enough if you can get the old system back online.

But then some new release will come out with grub 3 and you'll be in a
new kind of pain, since there is still only one /boot, and you can only
have one boot loader.

I think I'm convincing myself that if you want to roll back, use VMs.
/boot is too complicated to deal with.

Matt



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org