CentOS Stream From Bottom Works, What Is This?

Home » CentOS » CentOS Stream From Bottom Works, What Is This?
CentOS 35 Comments

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?

35 thoughts on - CentOS Stream From Bottom Works, What Is This?

  • CentOS Stream is built from the currently released RHEL Source Code + 0.1

    So if RHEL 8.3 is released .. Stream is the Source Code (built) that will become 8.4 in a few months.

  • CentOS Stream is built from the currently released RHEL Source Code + 0.1

    So if RHEL 8.3 is released .. Stream is the Source Code (built) that will become 8.4 in a few months.

    If this statement is exactly correct, then I think a lot of the issues in this thread may be easy to address. However, the question is whether it is really
    “That will become”
    or actually
    “That might become, if it turns out to be stable enough,”

    I.e., to me the critical question is how often (in practice) will updates that have problems, and will not actually make it into RHEL, end up in CentOS Stream. Presumably all such updates will be superseded in Stream by corrected ones, before they’re in RHEL.

    In fact, would it be possible, to list the final versions of each package’s update at the moment of the RHEL release, and only do the CentOS Stream update based on that list?

    Noam

  • There is one source for the source code that will be used. While in stream it will iterative (the push a bunch of changes today .. the build those change today). Those go through a CI process and get released into stream.

    When it comes time to build rhel 8.4 it will come from the same source code.

  • If a bug were to make it into CentOS Stream, and identified before RHEL
    8.4 was released, would an updated/fixed package be produced and placed into CentOS Stream?

    If a bug were to make it past CentOS Stream and into RHEL 8.4 and the bug is then identified and fixed after the release of RHEL 8.4 would an updated/fixed package be produced and placed into CentOS Stream in the same timeframe or only if/when updated packages and their dependencies were made/released into CentOS Stream for updated features for RHEL 8.5?

    If the same happened in the previous question but was in a package or set of packages that was being rebased in 8.5 would it work the same way?

    Thanks, Barry

  • The companies that pay for RHEL licenses for production and use CentOS for test will be left with a large problem. They will either need to purchase double the number of RHEL licenses and switch to RHEL for testing or go to another distribution. RHEL + 1 will not work for testing application compatibility with patches.

    No company will want to pay double the amount they are currently paying for RHEL licenses. This is not even addressing the cost and time it will take to switch over all the test servers.

    This will cost Red Hat credibility with major companies that they might never recover from. This will cost Red Hat major business.

    I will be recommending that my company change to Oracle Linux 8, instead of upgrading to RHEL 8. We will get the same model we are currently using, Paid support for production and free for test servers.

    Andrea

    —–Original Message—

  • Am 09.12.20 um 15:54 schrieb Bernstein, Noam CIV USN NRL (6393)
    Washington DC (USA) via CentOS:

    What should be also taking into account:
    – There is no “CentOS” (Linux or Stream does not matter)
    that have a life span of 10 years. CentOS Stream 8 will be retired and deleted from the mirrors end of May 2024 Q1!

  • what does this mean in comparison to CentOS 8, which sources are used for this?

    to be concrete:

    I can download this ISO of CentOS 8

    (1) CentOS-8.3.2011-x86_64-dvd1.iso

    and this ISO fo CentOS Stream

    (2) CentOS-Stream-8-x86_64-20201203-dvd1.iso

    which sources are used for (1) and which for (2)?

    and what does it mean of the update process be ‘yum update’

    e.g. if one would do this with CentOS 6, there is no way; the support ended;

    with CentOS 8 this will haben one day (somewhat in 2029), and what is said about this of CentOS Stream?

    Thanks,

    Walter

  • CentOS Linux 8 is the source code from released current RHEL 8 .. for now 8.3. The EOL of CentOS Linux 8 is 31 DEC 2021

    CentOS Stream 8 is the source cdoe from what be RHEL + 0.1 .. so currently 8.3 + 0.1 = 8.4. It will EOL in 31 MAY 2024

    CentOS Linux 6 EOLed 30 NOV 2020.

  • Am 09.12.20 um 18:12 schrieb Johnny Hughes:

    A related question: Since Stream 8 will EoL in MAY 2024, when RHEL 8 will enter the 5-year-Maintenance Support phase, in which way will the sources of the updates released for RHEL 8 (modifications / patches of Open Source codes) be released?
    Will these still go to git.CentOS.org, or on a new, to-be-created platform?

    Cheers, Oliver

  • when doing ‘yum update’ regularly this would also be EOL the end of the following year?

    this is much longer here, can I update this ‘forever’ just doing ‘yum update’ regularly?

    why I am asking this, I need to choose one option, because my CentOS 6
    VMs are EOL;

    and I would practice this the same way I did, when my CentOS 4 became EOL, I installed CentOS 6
    VM by VM – never used CentOS 5;

    e.g. the first one was the DNS-VM, which I used CentOS 6.2, then the outgoing Mail-server-VM, I used CentOS 6.3
    and by doing ‘yum update’ regularly they all became finally 6.10;

    so which should I choose
    – CentOS 7: EOL in 2024
    – CentOS Stream: EOL also in 2024
    (CentOS 8 is no option I guess)

    comparing to Windows, when using Win10, there is no install needed any more, every half year function update, and the other time security/bug fix update;

    is doing CentOS Stream the same way?

    Thanks,

    Walter

  • In the cases where RHEL + 0.1 (note not +1) won’t work, I think it’s incredibly likely that this will be covered by the expanded low- and no-cost RHEL offerings.

    Part of the buried lede here is that with more RHEL accessibility, a lot of the function that CentOS served for users will not be necessary anymore.

    Yeah, Red Hat knows this. Hence the above. If you have a specific case, please email the CentOS-questions@redhat.com address — that goes to the people designing the new programs, not to sales.

  • Absolutely. The only path into RHEL minor releases that isn’t through Stream is for CVEs and other embargoed changes. And those will go back into Stream as soon as they can.

    It might depend on the situation, but I would expect the fix to land quickly in Stream.

    Hmmm. I’m not sure I understand you. There won’t be a dump of 8.5 packages into Stream at some point. They will be updated there as ready.

  • Does that mean that it will always be possible to recreate the set of final RHEL point release packages by cherry-picking from Stream? If so, isn’t that a solution (and, I’d argue, _the_ solution if there’s some officially supported way of grabbing that set)?

    Noam

  • Don’t you think it might have been a good idea to solicit these type of situations *before* killing CenOS 8?

    After the complete and utter disaster RedHat has shat upon the World with the handling of this, there is no way anyone will ever trust that a “free”
    or “low cost” version of RHEL will stay that way for any length of time. To suggest so to this list, today, is ludicrous.

    Unless there’s a reversal of course here, I, and many others, will never recommend any RHEL product to my superiors from now on.

    (I’m hoping the horse isn’t dead yet.)

  • It’s buried, but the decision-makers failed to understand that the suddenness of this decision, outside of the community expectation for CentOS Linux continuing to be a thing (remember: Scientific Linux continued supporting SL6 right up to the end even after announcing that there would be no SL8), calls into question the stability of a lot of RedHat’s actions when it comes to distro decisions. Based on other emails, the CentOS Board perhaps understood this and the people issuing directions from RedHat perhaps did not. That does not bode well.

    Enterprises, and enterprise users, need reliability and confidence that their choices are the correct ones. How will RedHat/IBM restore confidence in the longevity of the offerings it’s producing?

    -jc

  • The scenario I imagine is this:

    start out the same EL 8.4 foo-1.1.1-1
    stream-8 foo-1.1.1-1

    update stream for EL 8.5

    EL 8.4 foo-1.1.1-1
    stream-8 foo-1.2.0-1

    CVE!

    EL 8.4 foo-1.1.2-1
    stream-8 foo-1.2.1-1

    Result: foo-1.1.2-1 is in EL but not stream.

    Jim

  • Sure .. they only time things will match 100% is at point release time. All the packages in 8.4 will have at some point been in stream when rhel 8.4 is released.

    Packages in between point releases will not necessarily be in stream .. but their equivalent will be. It will have the CVE and/or bugfix .. it will not likely be the exact same envr, but the one that will be in the new point release.

  • If RH plans to release a successor for CentOS 8 like RHEL 8 Free or so, this has become a communication disaster par excellence. The announcement with all the associated uncertainties and criticism was already picked up by the major press. I’ve no clue who is in charge of RH for the communication, but the team was quite bad in their job.

    If I plan something like this I would say, listen, CentOS will be released as Stream only in the future but the deprecated CentOS versions will be replaced by X. Before we do this change we’ll provide to you a script that transforms your current CentOS installation into the designated successor. I’m quite relaxed as I don’t use CentOS anymore except for private stuff. But I can fully understand those who already upgraded to C8 with the assumption in mind that they can use CentOS for the next few years with the expected behaviour.

    Changes are part of the IT and maybe the situation won’t become as dramatic as the one or other may fear (especially if a kind of RHEL 8 Free will be released), but the communication around this change is a perfect example how you shouldn’t do the communication.

    Kind regards Thomas

  • Haven’t tried this one, but yes, this is from a principal point of view what I mean.

    Kind regards Thomas

  • So if I understand this correctly, CentOS8 + will basically be a rolling release and we will never know what we are really running. Is this correct?

    To put it another way all of the stability we are used to will be gone and in order to stay up to date with stream I could potentially need to reboot machines daily depending on what packages $REDHAT developer decides to work on that day.

    Am I missing something?

    Regards,

  • That’s my understanding, iff you automatically install all CentOS stream updates the moment they become available. But I still don’t see why nearly no one is going for the idea that there be some way (ideally automated) to tag all the packages at the point of the RedHat release, and install only those from Stream once the RHEL release is ready?

    Noam

  • No, this is not the case. There will be continuous updates, but all of these updates are ones that are planned to go into a RHEL minor release, with all of the normal things that will imply. As Brendan said, .y stream development is really not all that exciting.

    I mean, if there are updates you want that day, sure?

  • Yeah, I have some sysadmin friends already working on exactly this for their deployment in a large-scale academic setting.

  • Well, I don’t think you have to. But it’s open source and it’s cool that you
    *can* do things like this if you want to.

  • SMH, really lets jump through hoops based on an arbitrary decision made by somebody or somone, who really knows since no one has said how the decision was reached. I’m pretty sure that most are just going to pack up and find another home, if I have to spend time doing something i’d rather it be permanent vs who knows what decision is going to be made next by RH.

  • The blindness is absolutely amazing.

    We don’t look at this as a fun little project we can endlessly dick around with. The *vast* majority of CenOS installations are on servers/workstations in large *enterprises*. That’s what the “E” in RHEL
    stands for. Remember?.

    This is why we don’t use your Fedora. It’s too unstable. And the lifetime is *way* too short.

    We need a stable operating system. We had one. We no longer do because of what your company did to us. And we can’t afford $300+ per machine.

    I respectfully request that you keep that in mind when discussing things in the CenOS list. Your viewpoint is from the Fedora side.

  • “[W]e’ll be shifting focus from CentOS Linux, the rebuild of Red Hat Enterprise Linux (RHEL), to CentOS Stream, which tracks just/ahead/of a current RHEL release. CentOS Linux 8, as a rebuild of RHEL 8, will end at the end of 2021. CentOS Stream continues after that date, serving as the upstream (development) branch of Red Hat Enterprise Linux…. It gives the CentOS contributor community a great deal of influence in the future of RHEL.”

    Someone (or several someones) at RedHat is/are very confused.

    As I wrote elsewhere, CentOS Whatever cannot be both upstream and downstream of RHEL and serve both roles adequately. If CentOS Stream remains just a CR/Early Access for updates that have passed all decision-making and QA processes and are well on their way to the upcoming RHEL point release, then there’s no real input that can be had here, and there also appears to be no change from what CentOS Stream has been for this entire EL8 cycle.

    If so, then the “great deal of influence” and “development/upstream branch” is meaningless drivel and the death of CentOS Linux (the rebuild) needs to be considered on its own merits as a distinct act by RedHat without distraction.

    A true “Enterprise Upstream” distinct from Fedora, where the community has a snowball’s chance at preventing laptop-focused Fedora-isms from destabilizing the core, is a niche begging to be filled. But that’s not what’s being presented to us, and telling SIGs to poke around on Stream instead of Linux does nothing for the vast majority of use cases external to RedHat.

    If the decision-makers (not the CentOS board, clearly) are being presented these responses then they should realize that the community expects a real post-mortem and explanation here.

    -jc

  • Am 10.12.20 um 18:02 schrieb Bernstein, Noam CIV USN NRL (6393)
    Washington DC (USA) via CentOS:

    Evaluating all the fragmented informations (another topic; communication to community) I get the impression that CXStream will never have a state that reflects RHEL point releases (not 100%). Why? Well CVE are one reason and another will be the different parts that are moving differently forward and the late parts (CVE coming after RHEL release)
    and so on …

  • Am 10.12.20 um 18:09 schrieb Matthew Miller:

    Will we know that point in time everytime before releasing? Because on release day the Stream repo is already a step forward. Albeit when this works then the situation are more worse then with CentOS Linux release work and the time shift compared to RHEL release. Why? Because 6 month updates are accumulated and not installed? Even cherry-picking is crazy. The audience here needs something different – but this was already stated elsewhere!

  • You will be running CentOS Stream 8.

    It is not a rolling release in the sense of .. it moves from Stream 8 to Stream 9 .. it will be Stream 8 until you manually move to Stream 9 or we get to the EOL (Currently May 31 2024).

    Well .. they will be working on the next RHEL point release. So the package will be from 8.4 if the current release is 8.3 and you are running CentOS Stream 8.

    It would be from 9.2 if the current release was 9.1 and you were on CentOS Stream 9.