| View previous topic :: View next topic |
| Author |
Message |
Irre
Guru
Joined: 09 Nov 2013
Posts: 434
Location: Stockholm
|
 Posted: Sun Aug 06, 2017 8:30 pm Post subject: Keeping Gentoo up to date |
 |
|
What do you think about this strategy to keep Gentoo system in good shape?
1) wait at least 24h but not more than a month.
2) emerge -Duvb @world
3) emerge --sync
4) if everything is ok, then goto 1)
5) rerun or repair failing packages
6) goto 1)
Note that update is run before sync!
The advantage with this algorithm is that many problems are solved during the wait in step 1). |
|
| Back to top |
|
 |
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54237
Location: 56N 3W
|
| Posted: Sun Aug 06, 2017 8:38 pm Post subject: |
|
|
Irre,
I would add -N to your emerge command.
After emerge -DNuvb @world add
emerge --depclean -p (run it when you are happy)
etc-update
Read news and act on it
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
fedeliallalinea
Administrator
Joined: 08 Mar 2003
Posts: 30916
Location: here
|
| Posted: Sun Aug 06, 2017 8:42 pm Post subject: |
|
|
Switch step 2 and 3, first you should update portage tree (emerge --sync) and the update packages.
I would change command emerge -Duvb @world with emerge -uDNvb --with-bdeps y @world.
If you have live package (9999 version) you should use emerge @live-rebuild.
After package package @world you shoud run also etc-update or dispatch-conf.
_________________
Questions are guaranteed in life; Answers aren't. |
|
| Back to top |
|
|
Irre
Guru
Joined: 09 Nov 2013
Posts: 434
Location: Stockholm
|
| Posted: Sun Aug 06, 2017 8:55 pm Post subject: |
|
|
Thank you!
The order 2) 3) is intentional. Many problems in step 2) are probably solved after 24h or more! New try:
1) wait at least 24h but not more than a month.
2a) emerge -DNuvb --with-bdeps y @world
2b) emerge --depclean -p
2c) etc-update
2d) eselect news read
3) emerge --sync
4) if everything is ok, then goto 1)
5) rerun or repair failing packages
6) goto 1) |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54237
Location: 56N 3W
|
| Posted: Sun Aug 06, 2017 9:51 pm Post subject: |
|
|
Irre,
If you wait for a month after your --sync some of the source files needed for the emerge may be gone.
That's a risk any time but the longer you wait the worse it gets.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Irre
Guru
Joined: 09 Nov 2013
Posts: 434
Location: Stockholm
|
| Posted: Sun Aug 06, 2017 10:07 pm Post subject: |
|
|
OK! New try:
1) wait at least 24h but not more than a month.
2a) emerge -DNuvb --with-bdeps y @world
2b) emerge --depclean -p
2c) etc-update
2d) eselect news read
3a) emerge --sync
3b) emerge -DNuvb --with-bdeps y --fetchonly @world
4) if everything is ok, then goto 1)
5) rerun or repair failing packages
6) goto 1) |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 8936
|
| Posted: Sun Aug 06, 2017 10:08 pm Post subject: |
|
|
| NeddySeagoon wrote: | | I would add -N to your emerge command. |
...which is a matter of personal taste rather than a necessity. Me, I've always found -N to be overkill. I will check the resulting output from time to time but only rarely kick off the emerge resulting from that. A lot of CPU time will be spent for no change on the disk. |
|
| Back to top |
|
|
jonathan183
Guru
Joined: 13 Dec 2011
Posts: 318
|
| Posted: Sun Aug 06, 2017 11:59 pm Post subject: Re: Keeping Gentoo up to date |
|
|
| Irre wrote: | | The advantage with this algorithm is that many problems are solved during the wait in step 1). |
do you mean the community identifying issues and users posting requests for help/solutions ? if that is the case then somewhere between 1 and 3 days is probably about the limit for this (after that people are likely to be using a different portage snapshot ... certainly anything more than a week).
If you mean a fix for an issue then unless you sync again then there is no benefit.
If this is something critical then reliance on the community identifying and fixing the issue alone is unwise. IMHO some method of backing out of changes is likely to be more useful than a reliance on things being picked up by others ... the issue may be unique to your use case/hardware combination |
|
| Back to top |
|
|
russK
l33t
Joined: 27 Jun 2006
Posts: 665
|
| Posted: Mon Aug 07, 2017 12:12 am Post subject: |
|
|
The moment that you have the impulse to sync (or not sync) and update @world is completely unrelated to whether or not a fix is checked into portage, so I believe you are probably just as well served doing the sync at the beginning. I think you are just as likely to encounter the error then and need to wait 24 hours as your are if you do the sync at the end. Just my humble opinion.
Nice thread regardless, thanks  |
|
| Back to top |
|
|
arnvidr
l33t
Joined: 19 Aug 2004
Posts: 629
Location: Oslo, Norway
|
| Posted: Tue Aug 08, 2017 11:46 am Post subject: Re: Keeping Gentoo up to date |
|
|
| jonathan183 wrote: | | unless you sync again then there is no benefit. |
This is the critical flaw. Any problems that have been fixed in your wait period will not be to your benefit until you sync anew.
_________________
|
|
| Back to top |
|
|
Irre
Guru
Joined: 09 Nov 2013
Posts: 434
Location: Stockholm
|
| Posted: Tue Aug 08, 2017 6:07 pm Post subject: Re: Keeping Gentoo up to date |
|
|
Thanks for all comments.
| arnvidr wrote: | | This is the critical flaw. Any problems that have been fixed in your wait period will not be to your benefit until you sync anew. |
But that is what I do in step 3) |
|
| Back to top |
|
|
SP2340
n00b
Joined: 01 Nov 2016
Posts: 50
Location: KeyStoneState
|
| Posted: Tue Aug 08, 2017 8:00 pm Post subject: |
|
|
I use the following to keep my ssytem up to date:
| Code: |
eix-sync
glsa-check -l
emerge --ask --update --deep --with-bdeps=y @world
emerge --ask --depclean
etc-update
|
_________________
--
Regards
Robert
Smile, it increases your face value. |
|
| Back to top |
|
|
arnvidr
l33t
Joined: 19 Aug 2004
Posts: 629
Location: Oslo, Norway
|
| Posted: Thu Aug 10, 2017 10:02 am Post subject: Re: Keeping Gentoo up to date |
|
|
| Irre wrote: | | arnvidr wrote: | | This is the critical flaw. Any problems that have been fixed in your wait period will not be to your benefit until you sync anew. |
But that is what I do in step 3) |
But you do the updates in step 2, so the sync that you do doesn't change your system in any way until the next time you go through your steps.
_________________
|
|
| Back to top |
|
|
Irre
Guru
Joined: 09 Nov 2013
Posts: 434
Location: Stockholm
|
| Posted: Thu Aug 10, 2017 4:58 pm Post subject: Re: Keeping Gentoo up to date |
|
|
| arnvidr wrote: | | Irre wrote: | | arnvidr wrote: | | This is the critical flaw. Any problems that have been fixed in your wait period will not be to your benefit until you sync anew. |
But that is what I do in step 3) |
But you do the updates in step 2, so the sync that you do doesn't change your system in any way until the next time you go through your steps. |
No I do updates in step 5) in case of errors! |
|
| Back to top |
|
|
jonathan183
Guru
Joined: 13 Dec 2011
Posts: 318
|
| Posted: Thu Aug 10, 2017 10:24 pm Post subject: |
|
|
OK lets say you sync'd on the 1st July
| Irre wrote: | 3a) emerge --sync
3b) emerge -DNuvb --with-bdeps y --fetchonly @world
4) if everything is ok, then goto 1)
5) rerun or repair failing packages
6) goto 1) |
So at this point you have a portage tree from 1st July with packages downloaded ready for doing an install
| Irre wrote: | | 1) wait at least 24h but not more than a month. |
you wait until say 30th July and then run
| Irre wrote: | 2a) emerge -DNuvb --with-bdeps y @world
2b) emerge --depclean -p
2c) etc-update
2d) eselect news read |
Any fix to the portage tree which has been done between 1st July and 30th July will not be available to you (because your last sync was on the 1st July), so will not have been applied when you emerge packages on the 30th July.
You can benefit from users posting on the forums that they have problems with possible solutions, but this probably only helps for about a week after which time people will have been using sync at a later date. The things to ask yourself are:-
Does this seeing other users problems warrant doing a sync and then delaying the update for days/weeks?
What are all these problems you manage to avoid?
Are they things which break your system?
Do you have to deal with the issues when you update the system anyway?
Does something like demerge provide what you are after?
Do you have a system sufficiently critical that you should emerge on a test system and check things before an update to your critical system? |
|
| Back to top |
|
|
Irre
Guru
Joined: 09 Nov 2013
Posts: 434
Location: Stockholm
|
| Posted: Thu Aug 10, 2017 11:39 pm Post subject: |
|
|
| The idea is to keep the system 1 to 30 days old (step 2a). But if there are any problems I rebuild failing (only) packages using last sync (step 3a). |
|
| Back to top |
|
|
russK
l33t
Joined: 27 Jun 2006
Posts: 665
|
| Posted: Thu Aug 10, 2017 11:54 pm Post subject: |
|
|
| jonathan183 wrote: |
Do you have a system sufficiently critical that you should emerge on a test system and check things before an update to your critical system? |
I'm a huge fanboy for gentoo and I love using it on my personal desktop, but if I was betting my paycheck or my business on it I can't imagine a scenario where I would be doing an emerge on a critical system. 
That's not a dig against gentoo, it's just knowing that sh*t happens. |
|
| Back to top |
|
|
russK
l33t
Joined: 27 Jun 2006
Posts: 665
|
| Posted: Sat Aug 12, 2017 6:02 pm Post subject: |
|
|
| russK wrote: | | jonathan183 wrote: |
Do you have a system sufficiently critical that you should emerge on a test system and check things before an update to your critical system? |
I'm a huge fanboy for gentoo and I love using it on my personal desktop, but if I was betting my paycheck or my business on it I can't imagine a scenario where I would be doing an emerge on a critical system.
That's not a dig against gentoo, it's just knowing that sh*t happens. |
Pondering this for a couple days of course I started to imagine scenarios. You could use binary packages, binhosts, copious backups, a staging system in addition to production system, and perhaps a hot spare. The critical/production system would be using binary packages and therefor similar to a rpm install on RHEL / Centos or .deb packages on debian. I could see working out an approach like this if I was self-employed. |
|
| Back to top |
|
|
Fitzcarraldo
Advocate
Joined: 30 Aug 2008
Posts: 2034
Location: United Kingdom
|
| Posted: Sat Aug 12, 2017 7:31 pm Post subject: |
|
|
| russK wrote: | | jonathan183 wrote: |
Do you have a system sufficiently critical that you should emerge on a test system and check things before an update to your critical system? |
I'm a huge fanboy for gentoo and I love using it on my personal desktop, but if I was betting my paycheck or my business on it I can't imagine a scenario where I would be doing an emerge on a critical system.
That's not a dig against gentoo, it's just knowing that sh*t happens. |
I do bet my paycheck on an emerge on a critical system, and have been for the past decade. My two-years old main laptop (amd64, with some ~amd64 packages), and its seven-years old predecessor (~amd64) which I keep as a fallback and for occasional benchmarking/testing of new packages, both run Gentoo and are my sole machines for earning a living for me and my family. I can only recall two occasions -- both with an ~amd64 installation, one nine years ago (the predecessor to my current fallback laptop) and the other four years ago -- where the installation was unusable after merging world and I had to spend many hours in my hotel room fixing it so I could use it at work the next day.
For what it's worth, my procedure for rolling is roughly as follows:
1. emerge --sync # 'emaint sync -a' in my ~amd64 installation.
2. layman -S # Covered by Step 1 in my ~amd64 installation.
3. eix-update && updatedb
4. eselect news read
5. Read new news items and make necessary changes.
6. emerge -uvpDN --with-bdeps=y @world
7. If no problems flagged in Step 6, go to Step 11.
8. Sort out any problem(s) flagged by the emerge --pretend.
9. emerge -uvpDN --with-bdeps=y @world
10. If problem(s) remain(s), go to Step 8.
11. emerge -uvDN --with-bdeps=y --keep-going @world # Decision to include or not '--keep-going' depends on circumstances.
12. If Step 11 does not run to completion successfully, fix problem(s) and go to Step 11.
13. emerge @preserved-rebuild # If specified in output from Step 11.
14. revdep-rebuild -i # Only if I have any doubts.
15. emerge --ask --depclean
16. etc-update
17. updatedb # If I can be bothered.
18. eclean-dist --deep # Optional. I do it from time to time if I can be bothered.
19. eix-test-obsolete # If I remember.
20. Wait for at least 24 hours (usually a few days, or a week or two) then go to Step 1.
Actually, I have added the '--with-bdeps=y' to EMERGE_DEFAULT_OPS in /etc/portage/make.conf so I don't need to type it in Steps 6, 9 & 11. As my laptop has a Core i7 CPU, I also added '--jobs=8' and '--load-average=8' to EMERGE_DEFAULT_OPTS in order to merge packages in parallel, which speeds up updating.
_________________
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 |
|
|
russK
l33t
Joined: 27 Jun 2006
Posts: 665
|
| Posted: Sat Aug 12, 2017 8:43 pm Post subject: |
|
|
Fitzcarraldo,
Your use case is more closely in line with the OP and is something I would be quite comfortable with. Especially since you have so much experience maintaining a usable gentoo laptop as your steps show.
When jonathan183 mentioned a "critical" system, I was thinking something more along the lines of a high-availability server providing services for paying customers. In that case, it's the situation implied by your Step 7, "If no problems ...". In the high-availability use-case, there needs to be the equivalent of an ejector seat or something at Step 8. This is why I started suggesting binary packages and backups. Maybe that use case would be better served in a separate thread.
I have become accustomed to 'dispatch-conf' rather than etc-update. Wondering if anyone has any opinions on the use of one over the other. I also like using 'quickpkg' and/or --buildpkg. Having binary packages that you know worked in the past to fall back on is good for peace of mind.
Regards |
|
| Back to top |
|
|
ian.au
Guru
Joined: 07 Apr 2011
Posts: 591
Location: Australia
|
| Posted: Sat Aug 12, 2017 11:44 pm Post subject: |
|
|
| russK wrote: |
I have become accustomed to 'dispatch-conf' rather than etc-update. Wondering if anyone has any opinions on the use of one over the other. I also like using 'quickpkg' and/or --buildpkg. Having binary packages that you know worked in the past to fall back on is good for peace of mind.
Regards |
I also prefer dispatch-conf with colordiff set in the .conf file. As for updating maybe I'm just lucky but it's been years since I had any real problems with an emerge-sync (other than the odd issue where a dev has screwed up, which is almost always fixed with a re-sync in 24-48hrs). I've run my business exclusively on gentoo since about 2008 with no real downtime that I can remember (outside of a couple of self-inflicted wounds - tip: never take a phone call whilst trying to read --depclean proposals).
I update once a week, I'm usually doing this over ssh so always run in a screen session with one window tailing -f /var/log/emerge.log and /var/log/emerge-fetch.log so I can periodically check progress of the update - my general method:
| Code: | eix-sync
emerge --update --deep --changed-use --with-bdeps=y -pv @world
# check output from above and make any necessary changes to /etc/portage/{package.use,package.accept_keywords}
emerge --update --deep --changed-use --with-bdeps=y @world
# hopefully that all went okay - if not check logs, maybe -1 offending package, or increase --backtrack value and repeat
dispatch-conf # if required
eselect news read xx # if required
emerge @preserved-rebuild # if required
emerge --depclean -pv
# carefully check proposed depclean action (if any)
emerge --depclean # if packages to remove > 0
|
Every 2-3 months I will add eclean-dist to the list. If I add or remove overlays I will run eix-update as part of that process.
This process usually takes less than 5 minutes of my time per machine (unless there's a major gcc update or some other i.e. api change that requires some reading). I can't see how that is a big investment of time to keep a system up to date and consistent, nor why anyone would ever try to abridge it by putting the process in a script and, well, hoping for the best 
edit: typo edit 2: eselect news |
|
| Back to top |
|
|
jonathan183
Guru
Joined: 13 Dec 2011
Posts: 318
|
| Posted: Wed Sep 20, 2017 11:39 pm Post subject: |
|
|
| Quote: | | Do you have a system sufficiently critical that you should emerge on a test system and check things before an update to your critical system? |
| russK wrote: | | When jonathan183 mentioned a "critical" system, I was thinking something more along the lines of a high-availability server providing services for paying customers. |
Yes that is the sort of thing I meant, given that type of system I would complete the emerge on another non-critical system first and build binaries to install on the critical system when I was confident things would work. Actually I'd probably make a copy of the critical system, update the copy, test it and then create binaries to update the critical system ... but I am not in that position |
|
| Back to top |
|
|
Yak
Tux's lil' helper
Joined: 01 Sep 2002
Posts: 107
|
| Posted: Thu Sep 21, 2017 1:15 am Post subject: |
|
|
Really any of the above sounds like a better plan than this...
| Code: | Total: 845 packages (569 upgrades, 191 new, 47 in new slots, 38 reinstalls, 29 uninstalls), Size of downloads: 3,343,564 KiB
Conflict: 98 blocks (31 unsatisfied)
|
Ooops... 
Portage is quite amazing though. After a few unmerges (mostly old emul-linux junk from 2014):
| Code: | Total: 870 packages (568 upgrades, 191 new, 46 in new slots, 65 reinstalls, 27 uninstalls), Size of downloads: 3,329,394 KiB
Conflict: 70 blocks |
But my plan going forward is to keep one updated within the last few months, to rescue the others from EAPI changes with quickpkg portage 
Seriously though, updating monthly is probably best. And if I was running a mission critical gentoo server, I would be building/testing packages on another machine, because then you always know what's coming doing it the second time around. |
|
| Back to top |
|
|
HungGarTiger
Apprentice
Joined: 04 Feb 2014
Posts: 180
Location: /nz/auckland
|
| Posted: Thu Sep 21, 2017 2:50 am Post subject: |
|
|
| Yak wrote: | Really any of the above sounds like a better plan than this...
| Code: | Total: 845 packages (569 upgrades, 191 new, 47 in new slots, 38 reinstalls, 29 uninstalls), Size of downloads: 3,343,564 KiB
Conflict: 98 blocks (31 unsatisfied)
|
Ooops...
|
Ohh, kinky |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Thu Sep 21, 2017 4:03 am Post subject: |
|
|
When I run into ugly like that after having neglected updates for roughly 3-6 months at a time, I start by masking anything critical and packages which will take a long time to compile. After that, I go through depcelan items. If necessary, more masking. So far that's worked every time. I don't normally unmask everything immediately, but updates eventually come along and provide "reminders."
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
|
Gentoo Chat
