Le 02/08/2020 à 09:47, Alessandro Baggi a écrit : > > 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. > > > > > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos I am an "old unix admin" and I remember that many years ago (let say 1990), on my unix systems, I was creating a backup before each update. All updates were not successful.... Today, we run "yum update" blindly, sometime daily, as it is "always" running fine, have rollback commands.... even on critical servers. But not sure that "always" exist really. Patrick