similar to: Safe to do yum update now?

? > Am 04.08.2020 um 17:59 schrieb Jerome Lille <jerome.lille at ownbay.net>: > > ?Hello > > Luckily I was not afflicted by this boot hole problem. I haven't done > yum update in a week or so. I just want to make sure that now it is > safe to do yum update? It is. > > /Jerome > > _______________________________________________ > CentOS mailing

You get so used to yum upgrades going so smoothly but I learned the hard way to always make a thorough inspection after a yum update. I let yum go ahead and upgrade from 3.5 to 3.6. Afterwards I made some basic queries to httpd, postfix and bind named (probably a cached query). I even checked the /var/named/ directory and saw all my hosts files. So looked like another smooth ride, well until

RedHat is recommending not to patch. https://access.redhat.com/solutions/5272311 Andrea -----Original Message----- From: CentOS <centos-bounces at centos.org> On Behalf Of Alessandro Baggi Sent: Friday, July 31, 2020 11:25 AM To: centos at centos.org Subject: {EXTERNAL} Re: [CentOS] 8.2.2004 Latest yum update renders machine unbootable CAUTION:??This email originated outside of BSWH;

On Fri, May 6, 2016 3:13 am, Gary Stainburn wrote: > On Thursday 05 May 2016 17:16:17 Valeri Galtsev wrote: >> There were several heated discussions on this list, and elsewhere. This >> is >> not intended to start the new one, but to help someone who missed them >> to >> define their statute. >> >> People split into two groups: >> >>

On Fri, May 6, 2016 8:46 am, Johnny Hughes wrote: > On 05/06/2016 08:38 AM, Valeri Galtsev wrote: >> >> On Fri, May 6, 2016 3:13 am, Gary Stainburn wrote: >>> On Thursday 05 May 2016 17:16:17 Valeri Galtsev wrote: >>>> There were several heated discussions on this list, and elsewhere. >>>> This >>>> is >>>> not intended to

On 7/31/20 11:24 AM, Alessandro Baggi wrote: > > Il 31/07/20 13:08, ja ha scritto: >> On Fri, 2020-07-31 at 22:35 +1200, Alan McRae via CentOS wrote: >>> I am running an Intel x64 machine using UEFI to boot an SSD. >>> >>> Installing the latest yum update which includes grub2 and kernel >>> 4.18.0-193.14.2.el8_2.x86_64 renders the machine

On 05/06/2016 08:38 AM, Valeri Galtsev wrote: > > On Fri, May 6, 2016 3:13 am, Gary Stainburn wrote: >> On Thursday 05 May 2016 17:16:17 Valeri Galtsev wrote: >>> There were several heated discussions on this list, and elsewhere. This >>> is >>> not intended to start the new one, but to help someone who missed them >>> to >>> define their

At 01:03 PM 8/1/2020, you wrote: >On 8/1/20 6:56 AM, david wrote: >>At 02:54 AM 8/1/2020, Alessandro Baggi wrote: >>>Hi Johnny, >>>thank you very much for clarification. >>> >>>You said that in the centos infrastructure only one server got the problem. >>>What are the conditions that permit the breakage? There is a particular

On Thursday 05 May 2016 17:16:17 Valeri Galtsev wrote: > There were several heated discussions on this list, and elsewhere. This is > not intended to start the new one, but to help someone who missed them to > define their statute. > > People split into two groups: > > Opponents of systemd (, firewqalld, etc.) who argue that from formerly > Unix-like system Linux becomes

On 03/12/2018 10:50 AM, Jerome Glisse wrote: > On Mon, Mar 12, 2018 at 06:30:09PM +0100, Daniel Vetter wrote: >> On Sat, Mar 10, 2018 at 04:01:58PM +0100, Christian K??nig wrote: > > [...] > >>>> They are work underway to revamp nouveau channel creation with a new >>>> userspace API. So we might want to delay upstreaming until this lands.

On Thu, May 5, 2016 9:58 am, Gary Stainburn wrote: > On Thursday 05 May 2016 15:19:47 John Hodrien wrote: >> I'd take a stab at: >> journalctl -fu dovecot >> The full RHEL7 System Administrators Guide is well worth a read, but here's >> the bit you're probably after. >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/ht

Ok, I'm trying way too hard to shovel myself out of a hole. We have a bunch of remote CentOS 6 servers, that were configured with kickstart. They've subsequently had additional RPMs installed/updated via the 'rpm' utility. We have reason to occasionally rewind the state of the server back to it's original set of RPMs. Of late, we've found that 'yum' handles this

Hi Johnny, thank you very much for clarification. You said that in the centos infrastructure only one server got the problem. What are the conditions that permit the breakage? There is a particular configuration (hw/sw) case that match always the problem or it is random? Thank you Il Sab 1 Ago 2020, 05:20 Johnny Hughes <johnny at centos.org> ha scritto: > On 7/31/20 11:24 AM,

Hello, I'm coming from Slackware and I'm searching for another distribution to run on my desktop and in near future also on a server. The *top priority* for me is security! I've test-installed CentOS on one of my test systems. So far anything went OK. After trying a bit, I would like to ask some questions: - What is the suggested way to get *secure and trusted* additional packages?

My housemate has formalized a sortof new attack against unix-style operating systems. He''s a BSD fan, so that''s where he developed the attack. He asked me to check Linux, which I did. It seems Linux is not vulnerable to it. This attack is going out to BUGTRAQ tonight. The attack isn''t too serious because it requires physical access to the console, but it

Il 31/07/20 13:08, ja ha scritto: > On Fri, 2020-07-31 at 22:35 +1200, Alan McRae via CentOS wrote: >> I am running an Intel x64 machine using UEFI to boot an SSD. >> >> Installing the latest yum update which includes grub2 and kernel >> 4.18.0-193.14.2.el8_2.x86_64 renders the machine unbootable, blank >> screen where grub should be, no error messages, just hangs.

Hi guys: I saw the pelthora of threads where people had trouble moving to 4.4. So I'm chicken now and I was trying to wait for the dust to settle, I suppose it has and its been long enough I'm nervous about not upgrading. I need to do a a production server that is located in a data center far away so even more than normal I want a smooth upgrade. Can someone tell the what the

I have had in years past seen hardware (SCSI) RAID controllers lose it electronically causing the kernel to fill the logs with scary SCSI messages and ext3 to complain about "holes" in the filesystem like so: Sep 7 14:47:17 thewarehouse1 kernel: EXT3-fs error (device sd(8,81)): ext3_readdir: directory #376833 contains a hole at offset 0 I'm using drbd and heartbeat so whatever

On Thu, May 26, 2016 10:51, Juan Bernhard wrote: > > El 26/05/2016 a las 11:39 a.m., Valeri Galtsev escribi?: >> I guess, it is just me in general unhappy about all Linuxes >> getting much less "UNIX"y lately. > > I feel you Valerei, im switching new server instalations to FreeBSD. > Im tired to spend useful time learning new ways (systemd, firewalld, > dnf,

Hi list, After kudos, time comes again with problems. This time, still on the same setup as before : - Linux PDC with ldapsam, ran by RH9, OpenLDAP 2.0.27 (stock RH9 RPM+Solaris RootDSE patch), Samba 3.0.1rc1 recompiled from SRPM ; - Linux BDC is the same ; The PDC and BDC are working Ok, so I won't include the smb.conf from these. - Solaris 9 domain member (jersey) gets Posix accounts