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
- Subject: [Discuss] --sandbox switch for Ubuntu's do-release-upgrade/update-manager
- From: me at mattgillen.net (Matthew Gillen)
- Date: Mon, 09 Mar 2015 16:03:52 -0400
- In-reply-to: <54FDC150.7050504@gmail.com>
- References: <54FDC150.7050504@gmail.com>
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
- Follow-Ups:
- [Discuss] --sandbox switch for Ubuntu's do-release-upgrade/update-manager
- From: richard.pieri at gmail.com (Richard Pieri)
- [Discuss] --sandbox switch for Ubuntu's do-release-upgrade/update-manager
- References:
- [Discuss] --sandbox switch for Ubuntu's do-release-upgrade/update-manager
- From: tmetro+blu at gmail.com (Tom Metro)
- [Discuss] --sandbox switch for Ubuntu's do-release-upgrade/update-manager
- Prev by Date: [Discuss] adb devices and Macbook Air/Pro old and new
- Next by Date: [Discuss] --sandbox switch for Ubuntu's do-release-upgrade/update-manager
- Previous by thread: [Discuss] --sandbox switch for Ubuntu's do-release-upgrade/update-manager
- Next by thread: [Discuss] --sandbox switch for Ubuntu's do-release-upgrade/update-manager
- Index(es):