Discuss

discuss@lists.centos.org

34729 discussions

Debug information packages for 8.3 missing?
by Oliver Freyermuth 12 Dec '20

12 Dec '20

Dear all, after the upgrade from 8.2 to 8.3 one of the applications we use has unclear Kerberos authentication issues. I was going to diagnose these and tried: yum debuginfo-install krb5-libs However, I get: Could not find debuginfo package for the following installed packages: krb5-libs-1.18.2-5.el8.x86_64 Could not find debugsource package for the following installed packages: krb5-libs-1.18.2-5.el8.x86_64 Checking on http://debuginfo.centos.org/8/x86_64/Packages/ , I do indeed not find these packages, also glibc and other debug info packages are missing. Are they still being uploaded, or am I using a wrong repository? Thanks and cheers, Oliver

2 4

Question on nmcli CentOS 8
by Jerry Geis 11 Dec '20

11 Dec '20

I am trying to modify the current eth0 with nmcli I ran this: nmcli con mod eth0 ipv4.addr 192.168.1.15/22 gw4 192.168.1.1 ipv4.dns 192.168.1.14 and now nmcli shows (two ipv4) addresses. inet4 192.168.1.15/22 inet4 192.168.2.212/22 I think the original connection was DHCP... the 2.212 item listed. So I want to change the original DHCP to a static network - how do I do that? I only want the one address not two. So now I need to "remove" both or all and add the 1 I want as static ? how do I do that? Thanks, Jerry

3 2

Re: [CentOS] Moving to CentOS 8 Stream
by Kienker, Fred 11 Dec '20

11 Dec '20

"It takes years to build a reputation and seconds to destroy it." -- Business 101 class Best regards, Fred

6 6

8-stream dnf overly verbose
by Pete Biggs 11 Dec '20

11 Dec '20

In moving a test machine from 8.3 to 8-stream the main thing I've noticed is that dnf has become very verbose. It's as if someone has turned on the -v permanently. I've tried using '-q' (it says nothing then) and I've tried adjusting the debuglevel, but nothing seems to affect it. I get things like this: Downloading: http://mirrorlist.centos.org/?release=8-stream&arch=x86_64&repo=BaseOS&infr… Downloading: http://mirror.cov.ukservers.com/centos/8-stream/BaseOS/x86_64/os/repodata/r… 0 B --:-- ETA Downloading: http://mirror.cov.ukservers.com/centos/8-stream/BaseOS/x86_64/os/repodata/c… Downloading: http://mirror.cov.ukservers.com/centos/8-stream/BaseOS/x86_64/os/repodata/b… Downloading: http://mirror.cov.ukservers.com/centos/8-stream/BaseOS/x86_64/os/repodata/6… CentOS Stream 8 - BaseOS 13 MB/s | 2.3 M For every repo when there's nothing cached. It never used to do this. How can I turn off the "Downloading:" messages? P.

7 10

CentOS 8 Stream: The Good, The Bad, The Ugly
by Joshua Kramer 11 Dec '20

11 Dec '20

Hello All- After reading and digesting a ton of community chatter about the recent CentOS announcement I've come to the conclusion that there's a lot of good about this, but there are also a lot of concerns that are being ignored. And nobody so far has stared directly into the eyes of the elephant in the room. So here goes. The Good: From a technical perspective- both in the sense of "getting newer software" and "technical community being more involved in bugfixes, etc"- having *a version* of CentOS called "AppStream" is fantastic. The various RedHat and CentOS folks who have been extolling these virtues in blog posts and twitter feeds are right-on. But from responses I've seen, it appears to me that they think that these virtues are enough to completely gloss over the complete and utter clusterfrackas they've caused. The Bad: No point releases. There is POSITIVELY NO* REASON that they can't have AppSream and still do point releases. Brand new stuff would go into AppStream, at some point they do a point release of RHEL, then follow the normal CentOS procedure to spin a CentOS build of that point release. This is already a tried and true process. It will cost RedHat all of what, low five digits (if that) in developer salary to do this. Heck I'm sure some volunteers would step up to use the existing infrastructure if RedHat didn't want to spend any paid developer time on this. The Ugly: I denoted "NO* REASON" above because there actually *are* reasons that we are not privy to. https://twitter.com/JoshuaPKr/status/1336744681716244480 Since RedHat is not being transparent with this, we are forced to speculate and remain bewildered at why they would make a decision that is going to cost them so much in the long run. The most common (and most likely) theory is that some MBA somewhere in middle management saw all of this CentOS being used in production environments (and otherwise downloaded for free), and had the idea that if CentOS had its head cut off people would just buy RHEL subscriptions. That may happen in a few cases, but for the most part, that is NOT what is going to happen. By handling the CentOS situation in this way, RedHat has branded itself as a company that acts in bad faith. If a company acts in bad faith towards a community where non-monetary value is exchanged, WHY would you trust that company to hold up its obligations for contracts that are actually paid? People are going to do whatever they can to get away from RedHat. Debian, Ubuntu, SuSE will all benefit from this. Even in cases where non-profits and other similar clients "contact RedHat about options because Stream won't meet their needs"- why would such entities have ANY reason to trust anything that RedHat says to them? There have been hundreds of other messages that describe exactly what RedHat loses in this deal so I won't go into that here. But branding oneself as a "bad faith actor" is usually a terrible way to try to pick up a little bit of subscription revenue. In the end it's going to be a losing scenario. This is an absolutely UNMITIGATED DISASTER from a marketing and community goodwill standpoint. It can, however, be mitigated if RedHat backtracks, admits their mistake, and affirmatively commits to support future CentOS point releases. I'll be interested to see how this turns out. --JK

12 14

Have lost access to ZFS pools with latest CentOS 8 kernels
by Robert G. (Doc) Savage 11 Dec '20

11 Dec '20

With the release of the vmlinuz-4.18.0-240.x and vmlinuz- 4.18.0.193.19.x kernels, ZoL cannot connect with a ZFS pool. I'm not 100% sure, but I believe the last CentOS 8 kernel to work with ZFS 0.8.5 was 4.18.0.6.x. Obviously CentOS does not support ZFS, so this means the ZoL folks must find and fix the problem. Otherwise, I think Fedora 33 is the only choice we have for hosting ZFS. --Doc Savage Fairview Heights, IL

2 1

CentOS Stream from bottom works, what is this?
by Walter H. 10 Dec '20

10 Dec '20

Hello, I just tried installing a VM from the stream ISO and it worked; the only thing I would like to have changed as a default config is GRUB_CMDLINE_LINUX=".... net.ifnames=0 ..." the reason, I find eth0, eth1, eth2 easier to use than cryptic names like ens33 or ens0p3 or so; Walter p.s. can someone tell in as short as possible what this CentOS Stream is in comparison to CentOS 8?

16 35

Current CentOS Stream already the downstream of the upcoming RH EL 8.4?
by Gianluca Cecchi 10 Dec '20

10 Dec '20

RH EL 8.3 released at the end of October 2020. Planned 8.4 would be at the end of April 2021. Now that CentOS has bridged the gap with 8.3 + updates, can we tell that what is going into Stream right now will begin to be the upcoming RH EL 8.4 and so that in the next five months we will get a real scenario of what is planned up to 2024? Thanks, Gianluca

2 1

Future of CentosPlus?
by Gerhard Schneider 10 Dec '20

10 Dec '20

Is there anything known about the future of CentosPlus after moving to a Pre-RHEL CentOS Stream? It would be of no interest to RedHat.. Gerhard Schneider -- Gerhard Schneider Institute of Lightweight Design and e-Mail: gs(a)ilsb.tuwien.ac.at Structural Biomechanics (E317) Tel.: +43 1 58801 31716 TU Wien / Vienna / Austria Fax: +43 1 58801 31799 A-1060 Wien, Gumpendorfer Straße 7 http://www.ilsb.tuwien.ac.at/~gs/

3 2

Re: [CentOS] https://blog.centos.org/2020/12/future-is-centos-stream/
by Gionatan Danti 10 Dec '20

10 Dec '20

Il 2020-12-10 18:40 Brendan Conoboy ha scritto: > Hey, you dropped Centos-devel from your reply. I'll assume that was > intentional, but if it wasn't feel free to quote any of this back > there. Hi Brendan, no, it was not intentional - I replied from the smartphone and I accidentally dropped the centos-devel list. I'll reply quoting the entire conversation to let others read your useful information. > On Thu, Dec 10, 2020 at 9:26 AM Gionatan Danti <g.danti(a)assyoma.it> > wrote: > >> Il 2020-12-10 14:35 Brendan Conoboy ha scritto: >>>> - are you going to keep stable ABI between Stream kernel >> releases, >>>> or >>>> should we expect each kernel to break 3rd party drivers/modules? >>> >>> All our kernel changes are implemented against the kernel ABI- >> there >>> is no point in time during release development when we have >> interim >>> changes in the kernel that ignore the symbols in the whitelist. >> So >>> basically if your experience of going from one minor release to >>> another has been smooth, the incremental kernels between those two >>> releases would also tend to run smooth, assuming whatever motions >>> happen with the 3rd party drivers/modules behind the scenes >> continue >>> to happen (for example, rebuilding from source). >> >> Let's forget about minor release upgrades and focus on the >> incremental >> kernel updates between point releases for a moment. Can we expect a >> stable kernel ABI for these releases, or should we expect breaking >> changes? In other words, should 3rd party kmod be constantly updated >> for >> *any* kernel released on the Stream channel, or can we expect them >> to >> keep working until a "next-release" kernel appears? >> >> Regarding symbol whitelist, I understand it as related to a single >> minor >> releases - ie: all kernels of 8.3 branch will obey it, but this can >> be >> false for kernel on, say, 8.4 >> >> Am I missing something? > > I think it's a question of nuance. In broad strokes we don't break > the kernel ABI as outlined by the whitelist starting with the first > major release. In fact, taht whitelist grows throughout the life of > the release, making the ABI more predictable. The problem you've > likely experienced is that loadable kernel modules have access to > symbols not included in the whitelist. Whether we're pushing new code > upstream or backporting new code from upstream, we endeavor to keep > symbols the same, even if they aren't on the whitelist. But if for > strong technical reasons it's better to change a symbol, that will > happen upstream, and if it wasn't part of our whitelist, it can happen > in RHEL as well. Usually these changes only require minor updates in > the loadable kernel modules, but for an end user this is the > difference between a module loading or not loading, so the impact is > glaring. > > I'm not sure how things will take shape with CentOS Stream and > external drivers, whether some gating activity wil elrepo will hold > back kernel updates until elrepo is updated, or if a SIG will form, or > some other thing. All I can say for sure is that when you have a > group of people with common problems, they will create solutions, and > we want those solutions for CentOS Stream. So we'll work it out, I'm > just not sure how yet (kABI isn't my focus, I'm simply familiar with > the dynamics because I was the overall RHEL 8 development lead). > >>>> - what/how many synchronization points are going to be with RHEL >>>> releases? >>> >>> I'm not sure I'm interpreting your question correctly, could you >>> restate? I don't want to hit you with detailed process >> information >>> only to find out I'm answering the wrong question! >> >> With Stream, all is going to change constantly. We will have any >> "sync >> point" where Stream is 100% identical to a specific RHEL point >> release? > > OK, I understand now, thanks! I don't think there will be a point > where a RHEL minor release compose will be NVR identical to a CentOS > Stream compose, though they will be pretty close. The reason for this > is that there is a period of time where we're working on 2 RHEL > releases at once: The one that is about to release, and the one that > will follow. CentOS Stream, I believe, will follow the source tree of > "the one that will follow." All the same fixes will be there, but > CentOS Stream will also get additional fixes and features not included > in the near term RHEL release. > >> Thank you for taking the time to reply. >> Regards. > > I appreciate the questions! Regards, Thank you for the clear replies. Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.danti(a)assyoma.it - info(a)assyoma.it GPG public key ID: FF5F32A8

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss