View previous topic :: View next topic |
Author |
Message |
crocket Guru
Joined: 29 Apr 2017 Posts: 558
|
Posted: Fri Dec 07, 2018 11:31 am Post subject: How can I upgrade gentoo atomically or transactionally? |
|
|
I want to scrap upgrades that fail. I want atomic upgrades that can be scrapped conveniently. How can I achieve that? |
|
Back to top |
|
|
mike155 Advocate
Joined: 17 Sep 2010 Posts: 4438 Location: Frankfurt, Germany
|
Posted: Fri Dec 07, 2018 10:46 pm Post subject: |
|
|
Sorry, but I don't understand your question. Please tell us what you did, what happened, why you don't like the result and what you want to achieve instead.
Are you looking for option '--keep-going', as in
Code: | emerge -e --keep-going -av @world
| ??? |
|
Back to top |
|
|
1clue Advocate
Joined: 05 Feb 2006 Posts: 2569
|
Posted: Sat Dec 08, 2018 2:30 am Post subject: |
|
|
AFAIK that does not exist on any distribution.
If it does, it will be one of the Enterprise Linux distros, where you pay a ton of money just to install it, and then you have the built-in support contract. They might go so far as to say that this particular snapshot of RHEL works on all tested hardware, and allow some mechanism to only upgrade to known-working combinations on your hardware. But I doubt it.
More likely, their testing is much better than Gentoo's (no insult to Gentoo) much older than Gentoo's (because of all that testing) and theoretically much more stable than Gentoo. Any of us who have used Enterprise Linux distros know that there are always bad days no matter who supplies the operating system.
Also without a doubt, their paid customer support can most likely get you help, learn what's wrong with your system, fix it, and get it back up in record time. |
|
Back to top |
|
|
1clue Advocate
Joined: 05 Feb 2006 Posts: 2569
|
Posted: Sat Dec 08, 2018 2:33 am Post subject: |
|
|
Another keyword you might look for is mission-critical in the distro's home page. This generally means that it can be used where people might die if the system breaks.
Of course a distro like that will likely insist on a relatively narrow set of hardware (the sort you might use in an airplane or similar) which will make the hardware extremely expensive, and they would likely want to supply the hardware too. And not let you have root password. |
|
Back to top |
|
|
crocket Guru
Joined: 29 Apr 2017 Posts: 558
|
Posted: Sat Dec 08, 2018 5:54 am Post subject: |
|
|
`emerge -quDN --keep-going @world` can fail in the middle. If the build doesn't fail, the end result might contain some broken packages. The details differ every time. Instead of having to waste hours on fixing issues right away, I want to step back, roll back a failed upgrade, and deal with issues on my pace.
On Arch Linux, upgrades are not atomic, but you can roll back an upgrade if you record what packages were upgraded. On Arch Linux, you can revert a package back to its previous version because there is a package cache that contains previous versions of packages.
In particular, I want to cancel the effects of `emerge -quDN --keep-going @world` with a single command such as `emerge --rollback @the-last-build`.
Though I can probably revert the root partition to a ZFS snapshot, it is also going to revert `/var`. I don't know which subdirectories of `/var` need to be protected from reversion. |
|
Back to top |
|
|
Goverp Advocate
Joined: 07 Mar 2007 Posts: 2008
|
Posted: Sat Dec 08, 2018 10:07 am Post subject: |
|
|
Why on earth "--keep-going" if you don't like the result?
I presume you've got portage configured to make and keep binary packages for everything, so when an emerge fails, you "just" need a script to read emerge.log backwards. Reinstall the previous version of each changed package - qlop and equery can both find the previous version (probably from further back in the log).
Of course, if emerge barfs reinstalling the previous version, then you've real fun. _________________ Greybeard |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54237 Location: 56N 3W
|
Posted: Sat Dec 08, 2018 10:22 am Post subject: |
|
|
crocket,
You need to build away from the target system - a chroot will do and create binary packages during the build.
You can test as much as you like before you roll out the binaries on the 'real' system.
There are two forms of breakage. The build breaks. That's easy to spot.
The build succeeds but the package doesn't work as expected. That's where your testing comes in.
There is also a half way house. Save binary packages everything you build. Eventually, you can roll back on a package by package basis using the binaries.
That works well on all ~arch, where some breakage is forecast.
I have all my binaries going back to April 2009, which are mostly no longer useful but I'm kind of attached to them :) _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
Fitzcarraldo Advocate
Joined: 30 Aug 2008 Posts: 2034 Location: United Kingdom
|
Posted: Sat Dec 08, 2018 11:42 am Post subject: |
|
|
Red Hat uses Docker or runC for atomic update/rollback. Have not seen anything as sophisticated or polished as that in Gentoo for updating packages. Would be nice, though. Btrfs supports snapshotting, which could be used for atomic updates on a filesystem-wide basis. One of these days I must try openSUSE and Snapper. A 'quick-and-dirty' approach in Gentoo would be to run Gentoo in a VM and snapshot before merging anything. Rather naff, though. _________________ Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC udev elogind & KDE on both.
Fitzcarraldo's blog |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54237 Location: 56N 3W
|
Posted: Sat Dec 08, 2018 11:46 am Post subject: |
|
|
Fitzcarraldo,
LVM can provide snapshots too. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
crocket Guru
Joined: 29 Apr 2017 Posts: 558
|
Posted: Mon Dec 10, 2018 8:51 am Post subject: |
|
|
I would make a snapshot of my ZFS filesystem, make a chroot on the snapshot, build binary packages on it, test those packages on the chroot for a while, and install binary packages on my real system.
How would you do it? |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54237 Location: 56N 3W
|
Posted: Mon Dec 10, 2018 11:10 am Post subject: |
|
|
crocket,
I build on a a system with lots of cores and RAM then push to a binhost.
The weaker system then updates from the binhost.
Testing is done on the target system but that's just a matter of convenience to me. I could do a lot of the testing on the build box.
Updating is still not atomic but its a lot better than building on the smaller system. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Mon Dec 10, 2018 9:06 pm Post subject: |
|
|
Btrfs snapshots will do it, I've used those for risky updates before (going from no-multilib to multilib). I guess the ZFS/LVM/XFS(?) equivalents would also work... |
|
Back to top |
|
|
|