Hi Johnny,
thank you for your answer. I always accepted release cycle of CentOS
without any problem (maybe with EL8 but it is ok).
I don't need SLA and I don't blame anyone for this, errors can occour.
For
example in this story, I applied blindly updates without check what and how
so really I ran the command that brake my installation...and as I said no
problem for this.
You said:" We TRY to
validate all fixes, but if something is broken in the source code, it
will likely be borken in CentOS Linux as well". This means that if a rhel
package break something, the centos team releases it with the bug anyway
also if the bug is already known? The update cannot be delayed until the
correct version is released if the package bug is already known? Is it not
possible by policy or other? Validate is equal to "test if nothing get
breakage"?
I repeat, I don't need SLA or QA or faster update/release. What sound
strange to me is that the testing procedure for a released update to see if
all works has failed and has not revealed the problem when the bug showed
up right away to me on a workstation and on a fresh install with minimal
and on a personal "server" with mdadm raid devices? In all my cases,
when
updating shim I got several and clear messages of failed update without the
need to perform a reboot and see that grub was broken.
I have another question. I know that the gear that provides notification
for el8 updates does not work due to koji. How is the current status for
notification of updates for centos 8? We can see update notifications soon
re-enabled?
Thank you for your time. I appreciate your work.
Il Dom 2 Ago 2020, 14:42 Johnny Hughes <johnny at centos.org> ha scritto:
> On 8/2/20 2:47 AM, Alessandro Baggi wrote:
> >
> > Il 02/08/20 00:42, Mike McCarthy, W1NR ha scritto:
> >> It appears that it is affecting multiple distributions including
Debian
> >> and Ubuntu so it looks like the grub2 team messed up. See
> >>
> >>
>
https://www.zdnet.com/article/boothole-fixes-causing-boot-problems-across-multiple-linux-distros/
> >>
> >>
> >> Mike
> >>
> >> On 8/1/2020 6:11 PM, Marc Balmer via CentOS wrote:
> >>>
> >>>> Am 01.08.2020 um 23:52 schrieb Leon Fauster via CentOS
> >>>> <centos at centos.org>:
> >>>>
> >>>> ?Am 01.08.20 um 23:41 schrieb Kay Schenk:
> >>>>> Well misery loves company but still...just truly
unfathomable!
> >>>>> Time for a change.
> >>>>
> >>>> I can only express my incomprehension for such statements!
> >>>>
> >>>> Stay and help. Instead running away or should I say out of
the
> >>>> frying pan and into the fire? :-)
> >>> The thing, RHEL and CentOS not properly testing updates, cost
me at
> >>> minimum 3-4 full working days, plus losses at customer sites.
> >>>
> >>> This is really a huge failure of RHEL and CentOS.
> >>>
> >>> A lot of trust has been destroyed.
> >
> > Hi Mike,
> >
> > I'm not interested that the issue is present on Debian, Ubuntu and
the
> > others. Currently I'm using CentOS, I'm a CentOS user and
currently I'm
> > interested what is happening on CentOS because I have machines that
runs
> > CentOS. If the "wrong" patch was not pushed as update so
fast (maybe
> > waiting more time before release with more testing to get all cases
[yes
> > because when you update grub and depending on the fix you can break a
> > system easily]) there would have been no problem, by the way I prefer
> > wait some days (consider that I can accept the release delay of
> > minor/major release) then break my systems...and without messages on
ML
> > announces about this type of problem does not help. Sorry I can't
know
> > what and when a packages is updated, why it is updated, what type of
> > problem (CVE) it suffers and do my reasoning for an update process.
This
> > is a missing for me but I still use centos and I should not need a
RHEL
> > account to access to get advisories and see what applies on CentOS
> > (6,7,8 and Stream).
> >
> > Many of us, choose CentOS due to its stability and enteprise-ready
> > feature (and because is partially/enterely backed by RH). Due to
actual
> > problem, many server and workstation died and it's normal that
some user
> > said "A lot of trust has been destroyed." because they
placed a lot of
> > trust on the pro-redhat support. On the other side, all of us can fall
> > in error and this is the case (like me that I updated blindy, so its
> > also my fault not only the broken update).
> >
> > Only one error in many years could not destroy a distro and its
> > stability reputation (I think and correct me if I'm wrong) and I
hope it
> > won't happen again.
>
> Well, I am sorry to tell you, but it most likely WILL happen again at
> some point.
>
> CentOS Linux is a rebuild of RHEL source code, nothing more. We TRY to
> validate all fixes, but if something is broken in the source code, it
> will likely be borken in CentOS Linux as well. If you need software
> with Service Level Agreement type stability and timing .. that is
> absolutely NOT CentOS.
>
> We have 3 people who build updates as fast as we can and this sofware is
> free and unvalidated. We don't do any security testing .. we build and
> release RHEL source code. RHEL is what you want if you want software
> assurance or the fastest release cycle or an SLA grade software release.
>
>
> I have released the new shim update for el7 that should fix this issue.
>
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> https://lists.centos.org/mailman/listinfo/centos
>