At 12:50 PM 8/1/2020, Kay Schenk wrote:
Totally and completely on my HP microfiber. Wouldn't get past anything to even get me into the grub menu. NOT AMUSED!
Kay Schenk
I was going to confirm the same, but the system that became unbootable was my mail system :-(
Apparently, the SHIM/GRUB bug has hit both Centos 7 and 8.
Too bad Ubuntu is enough different that makes it hard to switch.
David
Well misery loves company but still...just truly unfathomable! Time for a change.
_______________________ Sent from MzK's phone.
On Sat, Aug 1, 2020, 13:04 david david@daku.org wrote:
At 12:50 PM 8/1/2020, Kay Schenk wrote:
Totally and completely on my HP microfiber. Wouldn't get past anything to even get me into the grub menu. NOT AMUSED!
Kay Schenk
I was going to confirm the same, but the system that became unbootable was my mail system :-(
Apparently, the SHIM/GRUB bug has hit both Centos 7 and 8.
Too bad Ubuntu is enough different that makes it hard to switch.
David
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
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? :-)
-- Leon
Am 01.08.2020 um 23:52 schrieb Leon Fauster via CentOS centos@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.
-- Leon _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
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-mu...
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@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.
-- Leon _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
" UEFI-related updates have had a history of making devices unusable, and vendors will need to be very cautious."
https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/
The fix for this vulnerability is complex and the fix will have different results on different machines. The volunteers that support CentOS do the very best they can to test patches, but they can't possibly test for everything. If people have problems with the way patches are tested, maybe they should step up to the plate and become part of the solution.
We should be offering our thanks to those who donate their time and energy to supporting the CentOS project.
Andrea
-----Original Message----- From: CentOS centos-bounces@centos.org On Behalf Of Mike McCarthy, W1NR Sent: Saturday, August 1, 2020 5:42 PM To: centos@centos.org Subject: {EXTERNAL} Re: [CentOS] Boot failed on latest CentOS 7 update
CAUTION: This email originated outside of BSWH; avoid action unless you know the content is safe. Send suspicious emails as attachments to BadEmail@BSWHealth.org.
It appears that it is affecting multiple distributions including Debian and Ubuntu so it looks like the grub2 team messed up. See
https://urldefense.com/v3/__https://www.zdnet.com/article/boothole-fixes-cau...
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@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.
-- Leon _______________________________________________ CentOS mailing list CentOS@centos.org https://urldefense.com/v3/__https://lists.centos.org/mailman/listinfo /centos__;!!JA_k2roV-A!Qbogq3YCBtqgCyV83UWwK0fOy32CkVABRN-pzz0HoElpMB _0b7TaqLKl4zPsGV6qgw$
CentOS mailing list CentOS@centos.org https://urldefense.com/v3/__https://lists.centos.org/mailman/listinfo/ centos__;!!JA_k2roV-A!Qbogq3YCBtqgCyV83UWwK0fOy32CkVABRN-pzz0HoElpMB_0 b7TaqLKl4zPsGV6qgw$
_______________________________________________ CentOS mailing list CentOS@centos.org https://urldefense.com/v3/__https://lists.centos.org/mailman/listinfo/centos...
********************************************************************** The information contained in this e-mail may be privileged and/or confidential, and protected from disclosure, and no waiver of any attorney-client, work product, or other privilege is intended. If you are the intended recipient, further disclosures are prohibited without proper authorization. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden and possibly a violation of federal or state law and regulations. The sender and Baylor Scott & White Health, and its affiliated entities, hereby expressly reserve all privileges and confidentiality that might otherwise be waived as a result of an erroneous or misdirected e-mail transmission. No employee or agent is authorized to conclude any binding agreement on behalf of Baylor Scott & White Health, or any affiliated entity, by e-mail without express written confirmation by the CEO, the Senior Vice President of Supply Chain Services or other duly authorized representative of Baylor Scott & White Health.
Another ZDNet story on the issue:
https://www.zdnet.com/article/red-hat-enterprise-linux-runs-into-boothole-pa...
I use debian buster on my old notebook, an asus f3ja and I have not grub throuble. I try a virtual mschine with testing and unstable, and both boot regularly
Il dom 2 ago 2020, 00:42 Mike McCarthy, W1NR sysop@w1nr.net 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-mu...
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@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.
-- Leon _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Hi Paride,
I also have a debian 10 on a workstation and some VMs for test purpose. Probably you updated after the grub-regression update but I noticed several stories about debian breakage.
Il 02/08/20 01:13, paride desimone ha scritto:
I use debian buster on my old notebook, an asus f3ja and I have not grub throuble. I try a virtual mschine with testing and unstable, and both boot regularly
Il dom 2 ago 2020, 00:42 Mike McCarthy, W1NR sysop@w1nr.net 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-mu...
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@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.
-- Leon _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Mike --
Thanks for the clarification and more information.
_______________________ Sent from MzK's phone.
On Sat, Aug 1, 2020, 15:42 Mike McCarthy, W1NR sysop@w1nr.net wrote:
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-mu...
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@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.
-- Leon _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Questions re this statement in the ZDNET article --
"In all cases, users reported that downgrading systems to a previous release to reverse the BootHole patches usually fixed their problems."
A previous release of what? GRUB2
So that's my first question.
Second. I'm assuming the the muti-screen UEFI settings I see are standard for more recent BIOS -- not sure of version. Do we have any guidance for that?
If it is the case that a downgrade to previous grub2 can fix the problem -- and not latest kernel? Does this matter? -- maybe booting from your chosen "rescue" option AND reinstalling older grub (somehow) can get us further along.
_______________________ Sent from MzK's phone.
On Sat, Aug 1, 2020, 15:42 Mike McCarthy, W1NR sysop@w1nr.net wrote:
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-mu...
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@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.
-- Leon _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Am 02.08.20 um 04:15 schrieb Kay Schenk:
Questions re this statement in the ZDNET article --
"In all cases, users reported that downgrading systems to a previous release to reverse the BootHole patches usually fixed their problems."
A previous release of what? GRUB2
So that's my first question.
There are some canonical packages - the combination/grouping is important.
https://lists.centos.org/pipermail/centos-announce/2020-July/035779.html
Furthermore the corresponding shim and kernel rpms should be installed together (or the kernel should be reinstalled)
https://lists.centos.org/pipermail/centos/2020-August/351180.html
Second. I'm assuming the the muti-screen UEFI settings I see are standard for more recent BIOS -- not sure of version. Do we have any guidance for that?
If it is the case that a downgrade to previous grub2 can fix the problem -- and not latest kernel? Does this matter? -- maybe booting from your chosen "rescue" option AND reinstalling older grub (somehow) can get us further along.
-- Leon
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-mu...
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@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.
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-mu...
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@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@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
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-mu...
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@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.
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-mu...
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@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. -------------------------------------------------------------------------
Johnny,
Is the latest update : shim-x64 x86_64 15-7.el7_9
Greg
On Aug 2, 2020, at 9:14 AM, Gregory P. Ennis PoMec@PoMec.Net wrote:
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-mu...
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@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.
Gregory, Johnny, and everybody on CentOS team: Thanks a lot for great job you are doing!
And yes, we, humble users, do realize what you just said, Gregory. We know about “no guarantee” clause, and go with RedHat's reputation which through the great job you are doing translates into CentOS reliability level. My reading of many comments on this issue is, basically, the RedHat just lost a notch in the reputation level. Hopefully, it is not new lower level now, which hopefully again will be confirmed over long trouble-free period in a future.
On the side note: it is Microsoft that signs one of Linux packages now. We seem to have made one more step away from “our” computers being _our computers_. Am I wrong?
Valeri
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.
Johnny,
Is the latest update : shim-x64 x86_64 15-7.el7_9
Greg
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On the side note: it is Microsoft that signs one of Linux packages now. We seem to have made one more step away from “our” computers being _our computers_. Am I wrong?
Secure booting using UEFI requires that the code is signed - that is the "secure" bit. Microsoft are the CA for that signing. There's nothing sinister about it, they aren't signing the RPM package just one of the bits of code in the package. I seem to remember that Microsoft were the most vocal advocates for secure booting to get around boot sector viruses and in order to facilitate a more universal uptake they committed to signing any UEFI boot code from other OSes so long as it came from a bona fide source.
You don't have to use UEFI secure booting - most machines can fall back to legacy booting using BIOS settings. If you do that, you won't use any Microsoft signed code.
I haven't looked in detail at the bug this all was supposed to fix, but I think it had the capability of by-passing the UEFI security checking, hence why the release of the advisory was delayed until the OSes were patched and why there was a scramble to get everything out in time. It's a nasty bug and was difficult to fix from what I've heard.
P.
On Aug 2, 2020, at 14:43, Pete Biggs pete@biggs.org.uk wrote:
You don't have to use UEFI secure booting - most machines can fall back to legacy booting using BIOS settings. If you do that, you won't use any Microsoft signed code.
Back in 2017, Intel said that it was going to deprecate the “Legacy” CSM by 2020. They might have changed their schedule but I suspect we’ll start seeing hardware without anything but UEFI.
-- Jonathan Billings billings@negate.org
Once upon a time, Jonathan Billings billings@negate.org said:
On Aug 2, 2020, at 14:43, Pete Biggs pete@biggs.org.uk wrote:
You don't have to use UEFI secure booting - most machines can fall back to legacy booting using BIOS settings. If you do that, you won't use any Microsoft signed code.
Back in 2017, Intel said that it was going to deprecate the “Legacy” CSM by 2020. They might have changed their schedule but I suspect we’ll start seeing hardware without anything but UEFI.
I believe that is still Intel's plan.
However, as happens often, people are confusing UEFI and Secure Boot. UEFI is a replacement for the ages-old BIOS - Secure Boot is an extension to UEFI to create a "trusted" (for whatever that may mean) boot chain to get to the OS. You can have UEFI without having Secure Boot enabled (that's what I do on my systems).
On Sun, Aug 2, 2020 at 7:14 PM Chris Adams linux@cmadams.net wrote:
Once upon a time, Jonathan Billings billings@negate.org said:
On Aug 2, 2020, at 14:43, Pete Biggs pete@biggs.org.uk wrote:
You don't have to use UEFI secure booting - most machines can fall back to legacy booting using BIOS settings. If you do that, you won't use any Microsoft signed code.
Back in 2017, Intel said that it was going to deprecate the “Legacy” CSM
by 2020. They might have changed their schedule but I suspect we’ll start seeing hardware without anything but UEFI.
I believe that is still Intel's plan.
However, as happens often, people are confusing UEFI and Secure Boot. UEFI is a replacement for the ages-old BIOS - Secure Boot is an extension to UEFI to create a "trusted" (for whatever that may mean) boot chain to get to the OS. You can have UEFI without having Secure Boot enabled (that's what I do on my systems).
Legacy BIOS has its own set of issues, like no GPT support, MBR disks are max 2TB.
On 2020-08-03 05:56, John Pierce wrote:
Legacy BIOS has its own set of issues, like no GPT support, MBR disks are max 2TB.
I'm booting just fine on an old BIOS system from a pair (mdraid 1) of 3 TB GPT disks. The MBR compatibility on GPT disks allow the old machine to boot from a GPT disk and load GRUB. Then GRUB takes over and loads the kernel and the kernel has no problems understanding GPT disks.
The boot disks must have an EFI boot partition even though it's not used in this case.
On 8/3/20 2:21 AM, Jyrki Tikka wrote:
The boot disks must have an EFI boot partition even though it's not used in this case.
IIRC, they need a partition at the beginning of the drive to reserve space for GRUB2. That should be a "BIOS boot partition" not an "EFI System partition" for GRUB2. It's not used for a filesystem, but it is used to store GRUB2's second stage image.
On 2020-08-03 18:43, Gordon Messmer wrote:
On 8/3/20 2:21 AM, Jyrki Tikka wrote:
The boot disks must have an EFI boot partition even though it's not used in this case.
IIRC, they need a partition at the beginning of the drive to reserve space for GRUB2. That should be a "BIOS boot partition" not an "EFI System partition" for GRUB2. It's not used for a filesystem, but it is used to store GRUB2's second stage image.
Yes, you are absolutely right. I'm away from home right now and I don't have access to my home systems. My memory failed me which is not unusual.
<(*) Jyrki
On 02/08/2020 16:26, Valeri Galtsev wrote:
On the side note: it is Microsoft that signs one of Linux packages now. We seem to have made one more step away from “our” computers being _our computers_. Am I wrong?
Valeri
Microsoft are the Certificate Authority for SecureBoot and most SB-enabled hardware (most x86 hardware) comes with a copy of the Microsoft key preinstalled allowing binaries that are signed by Microsoft to work. In the case of linux, that is the shim which becomes the root of trust to load everything else. If you are not happy with that you can always become your own certificate authority by generating your own keys, install your signing keys in the hardware's firmware (MOK list) and sign stuff yourself to use on your own machine(s).
However if you wish to distribute stuff to others and have it work seamlessly on hardware outside of your direct control and without the need for every user to import your CA SecureBoot signing key into the MOK list on every device, you would rely on Microsoft to sign SB related content.
On Sun, Aug 2, 2020 at 11:45 AM Phil Perry pperry@elrepo.org wrote:
On 02/08/2020 16:26, Valeri Galtsev wrote:
On the side note: it is Microsoft that signs one of Linux packages now.
We seem to have made one more step away from “our” computers being _our computers_. Am I wrong?
Valeri
Microsoft are the Certificate Authority for SecureBoot and most SB-enabled hardware (most x86 hardware) comes with a copy of the Microsoft key preinstalled allowing binaries that are signed by Microsoft to work. In the case of linux, that is the shim which becomes the root of trust to load everything else. If you are not happy with that you can always become your own certificate authority by generating your own keys, install your signing keys in the hardware's firmware (MOK list) and sign stuff yourself to use on your own machine(s).
However if you wish to distribute stuff to others and have it work seamlessly on hardware outside of your direct control and without the need for every user to import your CA SecureBoot signing key into the MOK list on every device, you would rely on Microsoft to sign SB related content.
now, does Microsoft have to sign each released module themselves, or will they issue a CA cert to an authorized OS creator, like RH, then let RH sign their own modules?
EG, Microsoft RootCA -> Signed Package vs, Microsoft RootCA -> RH Child CA -> Signed Package ....
On 02/08/2020 19:54, John Pierce wrote:
On Sun, Aug 2, 2020 at 11:45 AM Phil Perry pperry@elrepo.org wrote:
On 02/08/2020 16:26, Valeri Galtsev wrote:
On the side note: it is Microsoft that signs one of Linux packages now.
We seem to have made one more step away from “our” computers being _our computers_. Am I wrong?
Valeri
Microsoft are the Certificate Authority for SecureBoot and most SB-enabled hardware (most x86 hardware) comes with a copy of the Microsoft key preinstalled allowing binaries that are signed by Microsoft to work. In the case of linux, that is the shim which becomes the root of trust to load everything else. If you are not happy with that you can always become your own certificate authority by generating your own keys, install your signing keys in the hardware's firmware (MOK list) and sign stuff yourself to use on your own machine(s).
However if you wish to distribute stuff to others and have it work seamlessly on hardware outside of your direct control and without the need for every user to import your CA SecureBoot signing key into the MOK list on every device, you would rely on Microsoft to sign SB related content.
now, does Microsoft have to sign each released module themselves, or will they issue a CA cert to an authorized OS creator, like RH, then let RH sign their own modules?
EG, Microsoft RootCA -> Signed Package vs, Microsoft RootCA -> RH Child CA -> Signed Package ....
I believe Microsoft signs the shim which then becomes the trusted authority and embeds RH (or CentOS) signing cert, so (I believe) every release of the shim needs to be signed by Microsoft. So it's not quite as efficient as MS signing a RH/CentOS CA key, but is not far off.
On Sun, Aug 2, 2020 at 1:01 PM Phil Perry pperry@elrepo.org wrote:
I believe Microsoft signs the shim which then becomes the trusted authority and embeds RH (or CentOS) signing cert, so (I believe) every release of the shim needs to be signed by Microsoft. So it's not quite as efficient as MS signing a RH/CentOS CA key, but is not far off.
One of the things that bugs me about PKI trust chains like this, what happens if the unthinkable happens, and Microsoft's RootCA gets compromised and has to be revoked... does that mean every single piece of UEFI hardware out there needs a BIOS upgrade? and don't UEFI bios updates have to be signed too?
On 8/2/20 1:19 PM, John Pierce wrote:
One of the things that bugs me about PKI trust chains like this, what happens if the unthinkable happens, and Microsoft's RootCA gets compromised and has to be revoked... does that mean every single piece of UEFI hardware out there needs a BIOS upgrade?
Yes. They'll be vulnerable to malware signed by the old CA until they're updated.
That's better than systems without a PKI trust chain, which are vulnerable all of the time.
On Sun, Aug 2, 2020 at 3:54 PM Gordon Messmer gordon.messmer@gmail.com wrote:
On 8/2/20 1:19 PM, John Pierce wrote:
One of the things that bugs me about PKI trust chains like this, what happens if the unthinkable happens, and Microsoft's RootCA gets
compromised
and has to be revoked... does that mean every single piece of UEFI hardware out there needs a BIOS upgrade?
Yes. They'll be vulnerable to malware signed by the old CA until they're updated.
That's better than systems without a PKI trust chain, which are vulnerable all of the time.
isn't it more that they simply won't work with newer boots that were signed by the new keys? and the updated BIOS's won't boot older OS versions that weren't signed by the new keys?
BIOS updates are often not available for sligthly older hardware, once it goes out of production most vendors lose all interest.
On 8/2/20 4:11 PM, John Pierce wrote:
isn't it more that they simply won't work with newer boots that were signed by the new keys? and the updated BIOS's won't boot older OS versions that weren't signed by the new keys?
I don't know if the Secure Boot PKI has a publicly documented contingency plan for a compromised CA, but my understanding is that there are multiple slots for signatures:
http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-e...
So, I would guess that clients would receive a new trust DB that did not contain the old root CA, and new bootloaders signed by both the old root CA and the new CA. The new bootloaders would work on both new and old systems, having signatures from both. Old bootloaders would not work on new clients.
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@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-mu...
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@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@centos.org https://lists.centos.org/mailman/listinfo/centos
On Sun, 2 Aug 2020 at 12:08, Alessandro Baggi alessandro.baggi@gmail.com wrote:
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"?
For CentOS-4, CentOS-5 and CentOS-6, the motto was "Bug for bug compatible with RHEL." If things failed for RHEL, they would fail in the same way for CentOS as much as possible. Many users of CentOS were exceedingly proud of it and expected it to be the case for when they needed justifications and such. The problem is that no one likes it when a major problem comes out from RHEL. THis happens probably once every 3 to 5 years and then everyone starts wanting to know why CentOS doesn't ship things when people find something wrong. People usually get motivated and start testing things more.. but after about 6 months of no other problems.. can justify that bugs aren't common so why do it.
On a side note, you keep emphasizing you aren't expecting an SLA.. but all your questions are what someone asks to have in a defined SLA. I have done the same thing in the past when things have gone badly, but couching it in 'I am not asking' just makes the people being asked grumpy. Better to be open and say 'Look I would like to know what my expectations should be for CentOS' and be done with it.
Il 02/08/20 18:54, Stephen John Smoogen ha scritto:
On a side note, you keep emphasizing you aren't expecting an SLA.. but all your questions are what someone asks to have in a defined SLA. I have done the same thing in the past when things have gone badly, but couching it in 'I am not asking' just makes the people being asked grumpy. Better to be open and say 'Look I would like to know what my expectations should be for CentOS' and be done with it.
Sorry, but you are wrong about this.
If I want SLA and QA I will use RHEL.
Now permit me to say one thing: the update on my machines, failed in a so bad way that my first thought was "WTF? they tested this fix?" and I'm not the only one that
On 8/2/20 12:09 PM, Alessandro Baggi wrote:
Il 02/08/20 18:54, Stephen John Smoogen ha scritto:
On a side note, you keep emphasizing you aren't expecting an SLA.. but all your questions are what someone asks to have in a defined SLA. I have done the same thing in the past when things have gone badly, but couching it in 'I am not asking' just makes the people being asked grumpy. Better to be open and say 'Look I would like to know what my expectations should be for CentOS' and be done with it.
Sorry, but you are wrong about this.
If I want SLA and QA I will use RHEL.
Now permit me to say one thing: the update on my machines, failed in a so bad way that my first thought was "WTF? they tested this fix?" and I'm not the only one that
And this complaint has to fall onto RedHat. Slightly underestimating the job CentOS team is doing, one could say: CentOS in just a binary replica of RedHat Enterprise.
And again, we use distributions for what benefit they give us, and any trouble we may encounter, we have just ourselves to blame for the choice we had made. And I here am not restricting the choices we could have made to variety of Linux flavors, but include in general anything one could use: a bunch of BSD descendants, MacOS (which server administration wise I excluded from chain BSD --> Darwin --> MacOS 10, or rather ignore that to be a chain), MS Windows (no, I am not asking for shots at me, I for one use FreeBSD for servers, not MS Windows), etc.
I use CentOS on workstation (except for my own_ and numbercrunchers. And once again, thanks a lot to the whole CentOS team for the great job, you, guys are doing!
Just my abstract view of this.
Valeri
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Il 02/08/20 19:22, Valeri Galtsev ha scritto:
On 8/2/20 12:09 PM, Alessandro Baggi wrote:
Il 02/08/20 18:54, Stephen John Smoogen ha scritto:
On a side note, you keep emphasizing you aren't expecting an SLA.. but all your questions are what someone asks to have in a defined SLA. I have done the same thing in the past when things have gone badly, but couching it in 'I am not asking' just makes the people being asked grumpy. Better to be open and say 'Look I would like to know what my expectations should be for CentOS' and be done with it.
Sorry, but you are wrong about this.
If I want SLA and QA I will use RHEL.
Now permit me to say one thing: the update on my machines, failed in a so bad way that my first thought was "WTF? they tested this fix?" and I'm not the only one that
And this complaint has to fall onto RedHat. Slightly underestimating the job CentOS team is doing, one could say: CentOS in just a binary replica of RedHat Enterprise.
Hi Valeri,
Yes you are right.
And again, we use distributions for what benefit they give us, and any trouble we may encounter, we have just ourselves to blame for the choice we had made. And I here am not restricting the choices we could have made to variety of Linux flavors, but include in general anything one could use: a bunch of BSD descendants, MacOS (which server administration wise I excluded from chain BSD --> Darwin --> MacOS 10, or rather ignore that to be a chain), MS Windows (no, I am not asking for shots at me, I for one use FreeBSD for servers, not MS Windows), etc.
I use CentOS on workstation (except for my own_ and numbercrunchers. And once again, thanks a lot to the whole CentOS team for the great job, you, guys are doing!
Just my abstract view of this.
Valeri
the previous message was sent incomplete.
I appreciate very much the great job done by the CentOS team with so low resource.
Il 02/08/20 19:09, Alessandro Baggi ha scritto:
Il 02/08/20 18:54, Stephen John Smoogen ha scritto:
On a side note, you keep emphasizing you aren't expecting an SLA.. but all your questions are what someone asks to have in a defined SLA. I have done the same thing in the past when things have gone badly, but couching it in 'I am not asking' just makes the people being asked grumpy. Better to be open and say 'Look I would like to know what my expectations should be for CentOS' and be done with it.
I press send wrongly.
Sorry, but you are wrong about this.
If I want SLA and QA I will use RHEL.
Now permit me to say one thing: the update on my machines, failed in a so BAD way that my first thought was "WTF? they tested this fix?" and I'm not the only one that who thought about this. I expect that a package is tested to not break a machine/service like for other distro like debian, opensuse, ubuntu and this is DIFFERENT than expect a defined SLA or QA level. How I can expect SLA from CentOS for personal usage and free? But if this happen on CentOS I read "Eh, you want SLA and you should use RHEL", ifthis happen on Ubuntu "Ah, don't use Ubuntu, I abondoned it for this type of problems"... I need only that the update does not destroy the entire installation. Now, if expect that a distro, with a strong reputation like centos, make test on a package that could break the boot process of a system, for a good number of usage case is not requiring SLA or QA, is only expect a good practice like I would expect for other distro.
When I release a patch/fix to a script or an RPM package or php page or python script, before I apply the change I ensure that this change does not break anything. I'm not sure about this? Good I'll wait to push it and test it again ( this not imply that bugs are not present) but this is not a SLA request man because I know that centos can't offer it.
Probably this is a my misconception, but hey I'm really and very surprised that this happend in a bad way (specially on the upstream). As I said, I will use again centos and won't expect any type of SLA, QA, fast release in a different way like for the previous version, I can only send a thank you to the CentOS team.
As Johnny explained this happened and will happen in the future, this problem is not related to CentOS directly and the great job that Johnny done today is amazing.
My 2 cent.
On Sun, 2 Aug 2020 at 13:35, Alessandro Baggi alessandro.baggi@gmail.com wrote:
Il 02/08/20 19:09, Alessandro Baggi ha scritto:
Il 02/08/20 18:54, Stephen John Smoogen ha scritto:
On a side note, you keep emphasizing you aren't expecting an SLA.. but all your questions are what someone asks to have in a defined SLA. I have done the same thing in the past when things have gone badly, but couching it in 'I am not asking' just makes the people being asked grumpy. Better to be open and say 'Look I would like to know what my expectations should be for CentOS' and be done with it.
I press send wrongly.
Sorry, but you are wrong about this.
My apologies. I should have asked for clarification.
-
Alessandro Baggi -
Chris Adams -
david -
Gordon Messmer -
Gregory P. Ennis -
John Pierce -
Johnny Hughes -
Jonathan Billings -
Jyrki Tikka -
Kay Schenk -
Kenneth Porter -
Laack, Andrea P -
Leon Fauster -
Marc Balmer -
Mike McCarthy, W1NR -
paride desimone -
Patrick Bégou -
Pete Biggs -
Phil Perry -
Stephen John Smoogen -
Valeri Galtsev