Discuss

discuss@lists.centos.org

8 participants
34745 discussions

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

Update path question in connection with CentOS Stream?
by Walter H. 10 Dec '20

10 Dec '20

Hello, when someone has installed a CentOS 7.1 in the past, and did 'yum update' regularily, his/she got a CentOS 7.8 now without any reinstallation procedure or other complications; when the same wanted to update to CentOS 8 he/she had to do a new install; what happens to CentOS Stream? when some is now installing CentOS Steam and will do 'dnf update' or 'yum update' regularily in the future, what does he/she get till the "end"? is this a rolling release like Win10 which doesn't need to be reinstalled now and in future? (the fact that hardware can break is not the question) Thanks, Walter

3 2

CentOS-announce Digest, Vol 189, Issue 3
by centos-announce-request＠centos.org 10 Dec '20

10 Dec '20

Send CentOS-announce mailing list submissions to centos-announce(a)centos.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request(a)centos.org You can reach the person managing the list at centos-announce-owner(a)centos.org When replying, please edit your Subject line so it is more specific than "Re: Contents of CentOS-announce digest..." Today's Topics: 1. CESA-2020:5239 Important CentOS 7 firefox Security Update (Johnny Hughes) 2. CESA-2020:5235 Important CentOS 7 thunderbird Security Update (Johnny Hughes) ---------------------------------------------------------------------- Message: 1 Date: Wed, 9 Dec 2020 20:21:57 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CESA-2020:5239 Important CentOS 7 firefox Security Update Message-ID: <20201209202157.GA1948(a)bstore1.rdu2.centos.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2020:5239 Important Upstream details at : https://access.redhat.com/errata/RHSA-2020:5239 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: cb3a549fe050cd75184479500b542065e37366ce62d90769646352bf2d9798a2 firefox-78.5.0-1.el7.centos.i686.rpm 4276584eb593d2fb304ab50518d7e2c4f955abe8fc5b3d1b9f0dd053d363f298 firefox-78.5.0-1.el7.centos.x86_64.rpm Source: 3d26716ee84904cf6f57b0e9d00d84765a498c15b8f0ac649d7f49248c61dca0 firefox-78.5.0-1.el7.centos.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net Twitter: @JohnnyCentOS ------------------------------ Message: 2 Date: Wed, 9 Dec 2020 20:24:41 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CESA-2020:5235 Important CentOS 7 thunderbird Security Update Message-ID: <20201209202441.GA2130(a)bstore1.rdu2.centos.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2020:5235 Important Upstream details at : https://access.redhat.com/errata/RHSA-2020:5235 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: f57d7074e8e50a23c9a10a230c6edbd1f48bc3130046704525be72e10c371656 thunderbird-78.5.0-1.el7.centos.x86_64.rpm Source: 6d147795bfe6c18c042e338932f14bdfcde9403bec0ccbb0c9c1132545645e57 thunderbird-78.5.0-1.el7.centos.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net Twitter: @JohnnyCentOS ------------------------------ Subject: Digest Footer _______________________________________________ CentOS-announce mailing list CentOS-announce(a)centos.org https://lists.centos.org/mailman/listinfo/centos-announce ------------------------------ End of CentOS-announce Digest, Vol 189, Issue 3 ***********************************************

1 0

Centos Developers Opinion
by Sergio Belkin 10 Dec '20

10 Dec '20

I would like to know the opinion of the CentOS developers on the decision to end CentOS. Because people already made his voice heard... What do you think? Is it a great decision and master play of business? Because you know 'devops-container-facebook-intel-thing' and "hey is the inevitable train of history? "Adapt or die?" Really? How could you explain what hundred of people around the world that already implemented CentOS 8 and helped reporting bugs, many of them cannot afford RH subscription? How could somebody trust on a company that one day happily says "if you don't like CentOS Stream, pay us?" and sents to trash a project of 16 years? Did nobody know what Red Hat was working on this? How strange is... I read you, we, the CentOS community read you, what do you think? Thanks in advance -- -- Sergio Belkin LPIC-2 Certified - http://www.lpi.org

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss