Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Keeping Gentoo up to date
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
Irre
Apprentice
Apprentice


Joined: 09 Nov 2013
Posts: 271
Location: Stockholm

PostPosted: Sun Aug 06, 2017 8:30 pm    Post subject: Keeping Gentoo up to date Reply with quote

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
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 39299
Location: 56N 3W

PostPosted: Sun Aug 06, 2017 8:38 pm    Post subject: Reply with quote

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
View user's profile Send private message
fedeliallalinea
Bodhisattva
Bodhisattva


Joined: 08 Mar 2003
Posts: 16918
Location: here

PostPosted: Sun Aug 06, 2017 8:42 pm    Post subject: Reply with quote

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
View user's profile Send private message
Irre
Apprentice
Apprentice


Joined: 09 Nov 2013
Posts: 271
Location: Stockholm

PostPosted: Sun Aug 06, 2017 8:55 pm    Post subject: Reply with quote

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
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 39299
Location: 56N 3W

PostPosted: Sun Aug 06, 2017 9:51 pm    Post subject: Reply with quote

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
View user's profile Send private message
Irre
Apprentice
Apprentice


Joined: 09 Nov 2013
Posts: 271
Location: Stockholm

PostPosted: Sun Aug 06, 2017 10:07 pm    Post subject: Reply with quote

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
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 5572
Location: Austria

PostPosted: Sun Aug 06, 2017 10:08 pm    Post subject: Reply with quote

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.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
jonathan183
Apprentice
Apprentice


Joined: 13 Dec 2011
Posts: 271

PostPosted: Sun Aug 06, 2017 11:59 pm    Post subject: Re: Keeping Gentoo up to date Reply with quote

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
View user's profile Send private message
russK
Guru
Guru


Joined: 27 Jun 2006
Posts: 520

PostPosted: Mon Aug 07, 2017 12:12 am    Post subject: Reply with quote

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 :D
Back to top
View user's profile Send private message
arnvidr
Guru
Guru


Joined: 19 Aug 2004
Posts: 558
Location: Oslo, Norway

PostPosted: Tue Aug 08, 2017 11:46 am    Post subject: Re: Keeping Gentoo up to date Reply with quote

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.
_________________
Noone wrote:
anything
Back to top
View user's profile Send private message
Irre
Apprentice
Apprentice


Joined: 09 Nov 2013
Posts: 271
Location: Stockholm

PostPosted: Tue Aug 08, 2017 6:07 pm    Post subject: Re: Keeping Gentoo up to date Reply with quote

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
View user's profile Send private message
SP2340
n00b
n00b


Joined: 01 Nov 2016
Posts: 50
Location: KeyStoneState

PostPosted: Tue Aug 08, 2017 8:00 pm    Post subject: Reply with quote

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
View user's profile Send private message
arnvidr
Guru
Guru


Joined: 19 Aug 2004
Posts: 558
Location: Oslo, Norway

PostPosted: Thu Aug 10, 2017 10:02 am    Post subject: Re: Keeping Gentoo up to date Reply with quote

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.
_________________
Noone wrote:
anything
Back to top
View user's profile Send private message
Irre
Apprentice
Apprentice


Joined: 09 Nov 2013
Posts: 271
Location: Stockholm

PostPosted: Thu Aug 10, 2017 4:58 pm    Post subject: Re: Keeping Gentoo up to date Reply with quote

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
View user's profile Send private message
jonathan183
Apprentice
Apprentice


Joined: 13 Dec 2011
Posts: 271

PostPosted: Thu Aug 10, 2017 10:24 pm    Post subject: Reply with quote

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
View user's profile Send private message
Irre
Apprentice
Apprentice


Joined: 09 Nov 2013
Posts: 271
Location: Stockholm

PostPosted: Thu Aug 10, 2017 11:39 pm    Post subject: Reply with quote

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
View user's profile Send private message
russK
Guru
Guru


Joined: 27 Jun 2006
Posts: 520

PostPosted: Thu Aug 10, 2017 11:54 pm    Post subject: Reply with quote

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. :lol:

That's not a dig against gentoo, it's just knowing that sh*t happens.
Back to top
View user's profile Send private message
russK
Guru
Guru


Joined: 27 Jun 2006
Posts: 520

PostPosted: Sat Aug 12, 2017 6:02 pm    Post subject: Reply with quote

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. :lol:

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
View user's profile Send private message
Fitzcarraldo
Veteran
Veteran


Joined: 30 Aug 2008
Posts: 1336
Location: United Kingdom

PostPosted: Sat Aug 12, 2017 7:31 pm    Post subject: Reply with quote

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. :lol:

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, OpenRC, nvidia-drivers & xf86-video-intel.
Compal NBLB2: ~amd64, OpenRC, xf86-video-ati, dual booting with Win 7 Pro 64-bit.
KDE on both laptops.

Fitzcarraldo's blog
Back to top
View user's profile Send private message
russK
Guru
Guru


Joined: 27 Jun 2006
Posts: 520

PostPosted: Sat Aug 12, 2017 8:43 pm    Post subject: Reply with quote

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
View user's profile Send private message
ian.au
Guru
Guru


Joined: 07 Apr 2011
Posts: 391
Location: Australia

PostPosted: Sat Aug 12, 2017 11:44 pm    Post subject: Reply with quote

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
View user's profile Send private message
jonathan183
Apprentice
Apprentice


Joined: 13 Dec 2011
Posts: 271

PostPosted: Wed Sep 20, 2017 11:39 pm    Post subject: Reply with quote

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
View user's profile Send private message
Yak
Tux's lil' helper
Tux's lil' helper


Joined: 01 Sep 2002
Posts: 107

PostPosted: Thu Sep 21, 2017 1:15 am    Post subject: Reply with quote

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 8)

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
View user's profile Send private message
HungGarTiger
Tux's lil' helper
Tux's lil' helper


Joined: 04 Feb 2014
Posts: 130
Location: /nz/auckland

PostPosted: Thu Sep 21, 2017 2:50 am    Post subject: Reply with quote

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 :lol:
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 16756

PostPosted: Thu Sep 21, 2017 4:03 am    Post subject: Reply with quote

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."
_________________
Those who dream by day are cognizant of many things that escape those who dream only at night. --Poe
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum