From: Nikos Chantziaras <realnc@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: [gentoo-user] Re: Heads Up - glibc-2.27 breaks my system
Date: Sun, 4 Feb 2018 20:01:29 +0200 [thread overview]
Message-ID: <p57hki$lkl$1@blaine.gmane.org> (raw)
In-Reply-To: <6947ed70-7549-65ef-a8e9-345e2757d084@gmail.com>
On 03/02/18 16:08, Dale wrote:
> Nikos Chantziaras wrote:
>> It is perfectly fine to downgrade glibc if you didn't emerge anything
>> that compiled binaries.
>>
>> If you did, you can still downgrade, but then you need to rebuild the
>> packages that you emerged since the glibc upgrade. qlop is your friend
>> here; it lets you find out the dates on which you emerged packages.
>
> That makes sense. So, if worse comes to worse, downgrade, then emerge
> -e world if unsure what all has been updated since. If, using qlop or
> friends, you can figure what was done since the upgrade, emerge those to
> make sure the linking is correct. At least that is a option that should
> be doable. That's better than thinking you can't downgrade for any
> reason, period.
You might not be able to do that, if python (used by emerge) uses
something that breaks when downgrading glibc. Or gcc. Or binutils. Or
bash. Or anything else that's needed during an emerge.
So you need to check with qlop *before* downgrading, and if it looks
like something critical was built against the new glibc, then all bets
are off. Which is why the downgrade protection exists in the first place.
The only way out of this, is restoring from backup or fixing things by
booting from a sysrescuecd or similar.
If only firefox or your media player and stuff like that got built
against the new glibc, then it's fine to downgrade. Otherwise, you could
end up bricking your system.
next prev parent reply other threads:[~2018-02-04 18:02 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-02 17:34 [gentoo-user] Heads Up - glibc-2.27 breaks my system Helmut Jarausch
2018-02-02 21:07 ` Floyd Anderson
[not found] ` <5x7d1x01i1kktTk01x7eRl>
2018-02-03 5:42 ` John Campbell
2018-02-03 5:54 ` Dale
2018-02-03 8:23 ` [gentoo-user] " Nikos Chantziaras
2018-02-03 14:08 ` Dale
2018-02-04 18:01 ` Nikos Chantziaras [this message]
2018-02-04 18:23 ` Dale
2018-02-03 9:50 ` [gentoo-user] " Helmut Jarausch
2018-02-03 15:11 ` Marc Joliet
2018-02-03 17:34 ` Helmut Jarausch
2018-02-03 17:56 ` Marc Joliet
2018-02-03 23:21 ` Bill Kenworthy
2018-02-04 11:52 ` Helmut Jarausch
2018-02-04 8:39 ` Neil Bothwick
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='p57hki$lkl$1@blaine.gmane.org' \
--to=realnc@gmail.com \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox