Re: [CentOS] LVM failure after CentOS 7.6 upgrade -- possible corruption

2018-12-05 Thread Gordon Messmer 

On 12/5/18 8:34 PM, Gordon Messmer wrote:
I still can't reason why the lvm tools were scanning the component 
volumes to begin with.


I think I've figured it out.  The new lvm-tools package appears to have 
broken support for detecting dm metadata version 0.90.  The update 
should be stable for anyone who did not upgrade from earlier versions of 
CentOS.  (I don't actually know when Anaconda last used 0.90 metadata)


On a working system with "verbose = 6" in lvm.conf:

# mdadm --detail /dev/md/primary
/dev/md/primary:
   Version : 1.2
...
# pvs
...
#device/dev-io.c:609   Opened /dev/sda3 RO O_DIRECT
#device/dev-io.c:359 /dev/sda3: size is 1951133696 sectors
#device/dev-io.c:658   Closed /dev/sda3
#filters/filter-mpath.c:196   /dev/sda3: Device is a partition, 
using primary device sda for mpath component detection

#device/dev-io.c:336 /dev/sda3: using cached size 1951133696 sectors
#device/dev-md.c:163   Found md magic number at offset 4096 of 
/dev/sda3.

#filters/filter-md.c:108   /dev/sda3: Skipping md component device
...


On the broken system:

# mdadm --detail /dev/md/primary
/dev/md/primary:
   Version : 0.90
...
# pvs
...
#device/dev-io.c:609   Opened /dev/sda3 RO O_DIRECT
#device/dev-io.c:359 /dev/sda3: size is 5858142208 sectors
#device/dev-io.c:658   Closed /dev/sda3
#filters/filter-mpath.c:196   /dev/sda3: Device is a partition, 
using primary device sda for mpath component detection
#filters/filter-partitioned.c:30filter partitioned deferred 
/dev/sda3

#filters/filter-md.c:99filter md deferred /dev/sda3
#filters/filter-persistent.c:346   filter caching good /dev/sda3
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] LVM failure after CentOS 7.6 upgrade -- possible corruption

2018-12-05 Thread Gordon Messmer 

On 12/5/18 9:27 AM, Gordon Messmer wrote:

The content of /var/log/messages is here:
 https://paste.fedoraproject.org/paste/n-E6X76FWIKzIvzPOw97uw


I don't have much new information, other than that I tested booting a 
similar system with an intentionally degraded RAID volume.  That one 
booted properly, so I don't think that was the problem.  The dm-cache 
device still needs further investigation, but I'm going to wait for all 
RAID arrays to re-sync before further testing.


Going through the log again, I'm looking at this line:
Dec  4 21:17:34 ascension lvm: WARNING: Device mismatch detected for 
VolGroup/lv_root which is accessing /dev/md127 instead of /dev/sda3.


Since it says "is accessing /dev/md127", I think the kernel activated 
the LVs properly, in which case there shouldn't be any corruption risk.


I still can't reason why the lvm tools were scanning the component 
volumes to begin with.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] // RESEND // 7.6: Software RAID1 fails the only meaningful test

2018-12-05 Thread Gordon Messmer 

On 12/5/18 11:55 AM, Benjamin Smith wrote:

The point of RAID1 is to allow for continued uptime in a failure scenario.
When I assemble servers with RAID1, I set up two HDDs to mirror each other,
and test by booting from each drive individually to verify that it works. For
the OS partitions, I use simple partitions and ext4 so it's as simple as
possible.



I used my test system to test RAID failures.  It has a two-disk RAID1 
mirror.  I pulled one drive, waited for the kernel to acknowledge the 
missing drive, and then rebooted.  The system started up normally with 
just one disk (which was originally sdb).




### content of rdosreport.txt
It's big; see
http://chico.benjamindsmith.com/rdsosreport.txt

[    0.00] localhost kernel: Command line: 
BOOT_IMAGE=/boot/vmlinuz-0-rescue-4456807582104f8ab12eb6411a80b31a 
root=UUID=1b0d6168-50f1-4ceb-b6ac-85e55206e2d4 ro crashkernel=auto 
rd.md.uuid=ea5fede7:dc339c3b:81817fc4:aba0bd89 
rd.md.uuid=7a90faed:4e5a2b50:9baa8249:21a6c3da rhgb quiet


/dev/sda1: UUID="6f900f10-d951-2ae7-712c-a5710d8d7316" 
UUID_SUB="541c8849-58bd-8309-96fd-b45faf0d40bb" LABEL="localhost:home" 
TYPE="linux_raid_member"
/dev/sda2: UUID="ea5fede7-dc33-9c3b-8181-7fc4aba0bd89" 
UUID_SUB="f127cce4-82f6-fa86-6bc5-2c6b8e3f8e7a" LABEL="localhost:root" 
TYPE="linux_raid_member"
/dev/sda3: UUID="39f40c01-b62c-8434-741d-38ee40c227f9" 
UUID_SUB="18319e88-67c4-94da-e55f-204c37528ece" LABEL="localhost:var" 
TYPE="linux_raid_member"
/dev/sda5: UUID="7a90faed-4e5a-2b50-9baa-824921a6c3da" 
UUID_SUB="40034140-1c7f-96c9-d4bd-4f4e25577173" LABEL="localhost:swap" 
TYPE="linux_raid_member" 



The thing that stands out as odd, to me, is that your kernel command 
line includes "root=UUID=1b0d6168-50f1-4ceb-b6ac-85e55206e2d4" but that 
UUID doesn't appear anywhere in the blkid output.  It should, as far as 
I know.


Your root filesystem is in a RAID1 device that includes sda2 as a 
member.  Its UUID is listed as an rd.md.uuid option on the command line 
so it should be assembled (incomplete) during boot.  But I think your 
kernel command line should include 
"root=UUID=f127cce4-82f6-fa86-6bc5-2c6b8e3f8e7a" and not 
"root=UUID=1b0d6168-50f1-4ceb-b6ac-85e55206e2d4"


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] New CentOS7 Install Yum will not work

2018-12-05 Thread Gordon Messmer 

On 12/5/18 10:48 AM, Ed Morrison wrote:

This is the latest error I am seeing:
[root@localhost ~]# yum check-update
Could not retrieve mirrorlist
http://mirrorlist.centos.org/?release=7=x86_64=os=stock
error was
14: curl#7 - "Failed connect to mirrorlist.centos.org:80; Operation now in
progress"



What happens if you run "curl http://mirrorlist.centos.org/"?  I see this:

$ curl http://mirrorlist.centos.org/
arch not specified

Test that, and then use curl on some other url.  "curl 
http://www.google.com/; maybe.


This should establish whether or not you have general network 
connectivity.   Either way, you'll probably want to talk to your network 
admins regarding the result.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Weird problems with CentOS 7.6 1810 installer

2018-12-05 Thread Gordon Messmer 

On 12/4/18 11:03 PM, Nicolas Kovacs wrote:

I could manage to switch to another virtual console, and I have the
following kernel log messages:
WARNING: kernel:perf: interrupt took too long



Can you run "dmesg" and find out if there's any more info?  Often there 
will be a kernel stack trace that provides hints as to which module was 
handling the interrupt, and therefore which device or driver is at fault.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS-es] VSC para subir clientes de correo masivamente

2018-12-05 Thread Rhamyro Alcoser A. 
Estimados amigos,

por favor si me pueden ayudar un archivo VSC para subir masivamente
usuarios de correo a un servidor de correo con postfix.

gracias por su ayuda

-- 

*Rhamyro Alcoser A.*

*Mailto1:* rhamyr...@gmail.com

*¿Qué, pues, diremos a esto? Si Dios es por nosotros, ¿quién contra
nosotros?, Rm 8:31*
___
CentOS-es mailing list
CentOS-es@centos.org
https://lists.centos.org/mailman/listinfo/centos-es

Re: [CentOS] LVM failure after CentOS 7.6 upgrade -- possible corruption

2018-12-05 Thread Gordon Messmer 

On 12/5/18 9:56 AM, Simon Matter wrote:

When running "pvs" on the broken system, no RAID volumes
were listed, only component devices
After updating, look at the output of "pvs" if you use LVM on software
RAID.

What exactly did `pvs' show and instead of what?


It should print:

# pvs
  PV VG  Fmt  Attr PSize   PFree
  /dev/md127 VolGroup    lvm2 a--   <2.73t <768.41g
  /dev/md2   BackupGroup lvm2 a--   <2.73t   0
  /dev/sdd1  VolGroup    lvm2 a--  <55.88g   0

and IIRC, it printed:

# pvs
  PV VG  Fmt  Attr PSize   PFree
  /dev/sda3 VolGroup    lvm2 a--   <2.73t <768.41g
  /dev/sdc1   BackupGroup lvm2 a--   <2.73t   0

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS-es] OT Mails Zimbra

2018-12-05 Thread Carlos Martinez 
Saludos.

Ya entiendo cuál es el requerimiento. Hay Tres opciones:

1) zimbra1: Haces que el IP del servidor de la aplicación de
facturación haga parte de las redes confiables (MTA Trusted Networks).
Con esto queda habilitado el servidor para que pueda enviar correo sin
autenticarse. Esto es muy peligroso y debe usarse con mucho cuidado ya
que el servidor puede usarse para enviar SPAM o para suplantar
usuarios.

Este parámetro está en: Configure - Servers - [nombre del servidor de
correo] - MTA.
Globalmente está en: Configure - Global settings MTA

2) zimbra 2:  Habilitas la opción para que se pueda realizar la
autenticación de los usuarios sin necesidad de establecer un conexión
cifrada (desmarcas TLS authentication only). Nuevamente esto es muy
peligroso ya que con el tiempo se tiende a configurar los clientes de
correo para que usen conexiones sin cifrar y muchas cosas malas pasan
después de eso.

3) solución local: Esta es la opción más segura, pero es larga y
tediosa. Instala un servidor de correo local y que escuche solamente
en localhost en modo trust y haces mail relay hacia el servidor de
correo principal. Si el servidor es Unix-Linux es fácil hacerlo con
Postfix y se limitan grandemente los riesgos de seguridad. Si el
equipo es Windows habría que ver si postfix puede correrse con el
entorno Linux que ahora traen o instalar algún MTA nativo y hacer
nuevamente mail relay. o crear una VM con un servicio de correo para
esta aplicación.

Hasta la próxima.
Carlos Martínez.

On Wed, Dec 5, 2018 at 2:20 PM César Martínez M.
 wrote:
>
> Gracias Carlos el problema es que la aplicación de factiracion no permite 
> usar envió con tls o ssl.
>
> De echo el servidor tienen instalado un certificado letscript
>
> Saludos
>
> César Martínez M.
> Ingeniero de Sistemas
> Proyectos de Software Libre
> Servicom
> Móvil 0999374317
>
> Enviado desde mi móvil samsung S8
>
> El 5 de diciembre de 2018 13:57:56 GMT-05:00, Carlos Martinez 
>  escribió:
> >Saludos.
> >
> >Ahora es una necesidad que los servidores de correo usen SSL para
> >enviar correos (comunicarse con otros servidores). De otra forma, les
> >asignan una reputación pobre y se tienen muchos problemas de entrega.
> >Además es una necesidad para proteger las contraseñas de los usuarios.
> >
> >Un certificado digital cuesta unos USD$100 al año con godaddy. Si no
> >se desea pagar por ello, se puede usar letsencrypt con certbot que
> >funcionan muy bien para zimbra. Lo malo de este último acercamiento es
> >que cada tres meses hay que reiniciar el servicio de zimbra para que
> >tome los certificados renovados. Todo esto se puede hacer con un
> >script para despreocuparse de la tarea.
> >
> >Hasta la próxima.
> >
> >Carlos Martínez.
> >
> >
> >On Wed, Dec 5, 2018 at 1:30 PM Cesar Martinez M.
> > wrote:
> >>
> >> Saludos amigos tengo un servidor zimbra 8.8.10 el cuál esta
> >funcionando
> >> bien, ahora por temas de facturación se a implementado un sistema el
> >> cuál necesita enviar emails pero este sistema no soporta TLS o SSl,
> >la
> >> pregunta es:
> >>
> >> Existe alguna forma de configurar zimbra para que el envió de emails
> >no
> >> sea obligatorio con SSl, que se pueda usar el puerto 25 o 587 y este
> >> último sin TLS.
> >>
> >> De ante mano gracias a todos quienes puedan echarme una mano con esta
> >> consulta.
> >>
> >> --
> >> |Saludos Cordiales
> >> |César Martínez M. | Ingeniero de Sistemas
> >> |Consultor & Proyectos Software Libre| SERVICOM
> >> |Teléfono: (593-2)554-271 2221-386 | Ext 4501
> >> |Celular:593 999374317 |Skype servicomecuador
> >> |Web www.servicomecuador.com Síguenos en:
> >> |Twitter: @servicomecuador |Facebook: servicomec
> >> |Zona Clientes: www.servicomecuador.com/billing
> >> |Blog: http://servicomecuador.com/blog
> >> |Dir. Av. 10 de Agosto N29-140 Entre
> >> |Acuña y  Cuero y Caicedo
> >> |Quito - Ecuador - Sudamérica
> >>
> >> ___
> >> CentOS-es mailing list
> >> CentOS-es@centos.org
> >> https://lists.centos.org/mailman/listinfo/centos-es
> >___
> >CentOS-es mailing list
> >CentOS-es@centos.org
> >https://lists.centos.org/mailman/listinfo/centos-es
> ___
> CentOS-es mailing list
> CentOS-es@centos.org
> https://lists.centos.org/mailman/listinfo/centos-es
___
CentOS-es mailing list
CentOS-es@centos.org
https://lists.centos.org/mailman/listinfo/centos-es

Re: [CentOS] CR repo update disaster for my desktop.

2018-12-05 Thread Akemi Yagi 
On Wed, Dec 5, 2018 at 12:38 AM Rob Kampen  wrote:
>
> On 5/12/18 7:21 AM, Phil Perry wrote:

> > The only issue I've seen reported that sounds similar or possibly
> > related is:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1650634
> Yes, seems this is the laptop issue, will prove tomorrow.
> >
> > There is a patch in that bug you might like to try.
> Not too keen on this, would need to find a detailed howto as I have not
> done any rebuilds for a number of years. I presume that RH will at some
> point release a fix for this?

The submitter of RHBZ 1650634 is a developer of Scientific Linux. The
xorg packages in SL 7.6 have been published with the referenced patch
applied. If you so wish, you could install their packages.

ftp://linux1.fnal.gov/linux/scientific/7.6/x86_64/updates/security/

Note the "sl7" tag instead of "el7".

Akemi
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CR repo update disaster for my desktop.

2018-12-05 Thread Rob Kampen 


⁣Sent from BlueMail ​

On 05 Dec 2018, 7:22 AM, at 7:22 AM, Phil Perry  wrote:
>On 04/12/2018 09:54, Rob Kampen wrote:
>> 
>> So in an effort to narrow down the problem I also have an old Samsung
>
>> laptop - i5 with an nvidia card - all up-to-date 7.5 - I thought I
>would 
>> try a more conservative upgrade approach.
>> 
>> first updated to the CR kernel with yum upgrade kernel*
>> 
>> then after successful reboot did an update to gdm* and gnome*
>> 
>> another reboot and all is well
>> 
>> then update of xorg* (only 20 files)
>> 
>> Now it will not boot - keyboard is non responsive so cannot even do a
>
>> Ctrl Alt F2 to access a shell. Old kernel is also non boot. Left this
>
>> machine for now and back to my main desktop workstation.
>> 
>
>The only issue I've seen reported that sounds similar or possibly 
>related is:
>
>https://bugzilla.redhat.com/show_bug.cgi?id=1650634
>
>There is a patch in that bug you might like to try.
>
>> No idea if this xorg problem relates to my original workstation - so
>on 
>> that machine I did a downgrade of xorg* - seemed to complete ok, but
>on 
>> reboot and login - still the same problem.
>> 
>> As the only clue in the logs is the libc segfault I did a downgrade
>of 
>> glibc - this too seemed to work but no change to the system - gnome 
>> crashes after 5 - 10 seconds.
>> 
>
>I'm guessing that probably hasn't helped matters
>
>> Wasted far too much time on this, no idea what to do now so I have
>done 
>> a fresh 7.5 install and all works again - just need to install all
>the 
>> additional stuff I use each day, but at least I have a desktop that 
>> functions.
>> 
>___
>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

Re: [CentOS] LVM failure after CentOS 7.6 upgrade -- possible corruption

2018-12-05 Thread Benjamin Smith 
On Wednesday, December 5, 2018 11:38:50 AM PST Stephen John Smoogen wrote:
> You might want to point out which list you posted it on since it
> doesn't seem to be this one.

Apparently there's a size limit for emails. I've resent with one of the output 
files hosted on a personal webserver and it went through. 

For your issue, in my own testing, simply choosing an older kernel didn't 
resolve the "boot from a single drive degraded" issue. 

My suggestions for resolution: 

1) Boot up on another system. 
2) Install the degraded disk. 
3) Install another drive to match the degraded disk. 
4) Set up mdadm to pair the two drives, wait for them to sync. 
5) Install the newly fixed pair back into the original system and see if it 
boots. 

In any event, I'd consider dd'ing the entirety of the drive in its current 
form to another disk so you can recover to this point in time. Maybe even only 
try to resolve things with the dd'd copy so you don't risk wherever you're at 
now. 

Good luck. 

Ben 


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] // RESEND // 7.6: Software RAID1 fails the only meaningful test

2018-12-05 Thread Benjamin Smith 
(Resend: message didn't show, was my original message too big? Posted one of 
the output files to a website to see)

The point of RAID1 is to allow for continued uptime in a failure scenario. 
When I assemble servers with RAID1, I set up two HDDs to mirror each other, 
and test by booting from each drive individually to verify that it works. For 
the OS partitions, I use simple partitions and ext4 so it's as simple as 
possible.

Using the CentOS 7.6 installer (v 1810) I cannot get this test to pass in any 
way, with or without LVM. Using an older installer, it works fine (v 1611) and 
I am able to boot from either drive but as soon as I do a yum update then it 
fails. 

I think this may be related or the same issue reported in "LVM failure after 
CentOS 7.6 upgrade" since that also involves booting from a degraded RAID1 
array. 

This is a terrible bug. 

See below for some (hopefully) useful output while in recovery mode after a 
failed boot. 

### output of fdisk -l 

Disk /dev/sda: 500.1 GB, 500107862016 bytes, 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x000c1fd0

   Device Boot  Start End  Blocks   Id  System
/dev/sda12048   629409791   314703872   fd  Linux raid autodetect
/dev/sda2   *   629409792   839256063   104923136   fd  Linux raid autodetect
/dev/sda3   839256064   94417919952461568   fd  Linux raid autodetect
/dev/sda4   944179200   976773119162969605  Extended
/dev/sda5   944181248   97565491115736832   fd  Linux raid autodetect


### output of cat /prod/mdstat 
Personalities : 
md126 : inactive sda5[0](S)
  15727616 blocks super 1.2
   
md127 : inactive sda2[0](S)
  104856576 blocks super 1.2
   
unused devices: 


### content of rdosreport.txt 
It's big; see 
http://chico.benjamindsmith.com/rdsosreport.txt



___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] LVM failure after CentOS 7.6 upgrade -- possible corruption

2018-12-05 Thread Stephen John Smoogen 
On Wed, 5 Dec 2018 at 14:27, Benjamin Smith  wrote:
>
> My gut feeling is that this is related to a RAID1 issue I'm seeing with 7.6.
> See email thread "CentOS 7.6: Software RAID1 fails the only meaningful test"
>

You might want to point out which list you posted it on since it
doesn't seem to be this one.


> I suggest trying to boot from an earlier kernel. Good luck!
>
> Ben S
>
>
> On Wednesday, December 5, 2018 9:27:22 AM PST Gordon Messmer wrote:
> > I've started updating systems to CentOS 7.6, and so far I have one failure.
> >
> > This system has two peculiarities which might have triggered the
> > problem.  The first is that one of the software RAID arrays on this
> > system is degraded.  While troubleshooting the problem, I saw similar
> > error messages mentioned in bug reports indicating that sGNU/Linux
> > ystems would not boot with degraded software RAID arrays.  The other
> > peculiar aspect is that the system uses dm-cache.
> >
> > Logs from some of the early failed boots are not available, but before I
> > completely fixed the problem, I was able to bring the system up once,
> > and captured logs which look substantially similar to the initial boot.
> > The content of /var/log/messages is here:
> >   https://paste.fedoraproject.org/paste/n-E6X76FWIKzIvzPOw97uw
> >
> > The output of lsblk (minus some VM logical volumes) is here:
> >   https://paste.fedoraproject.org/paste/OizFvMeGn81vF52VEvUbyg
> >
> > As best I can tell, the LVM tools were treating software RAID component
> > devices as PVs, and detecting a conflict between those and the assembled
> > RAID volume.  When running "pvs" on the broken system, no RAID volumes
> > were listed, only component devices.  At the moment, I don't know if the
> > LVs that were activated by the initrd were backed by component devices
> > or the RAID devices, so it's possible that this bug might corrupt
> > software RAID arrays.
> >
> > In order to correct the problem, I had to add a global_filter to
> > /etc/lvm/lvm.conf and rebuild the initrd (dracut -f):
> >   global_filter = [ "r|vm_.*_data|", "a|sdd1|", "r|sd..|" ]
> >
> > This filter excludes the LVs that contain VM data, accepts "/dev/sdd1"
> > which is the dm-cache device, and rejects all other partitions on
> > SCSI(SATA) device nodes, as all of those are RAID component devices.
> >
> > I'm still working on the details of the problem, but I wanted to share
> > what I know now in case anyone else might be affected.
> >
> > After updating, look at the output of "pvs" if you use LVM on software RAID.
> > ___
> > 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



-- 
Stephen J Smoogen.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] LVM failure after CentOS 7.6 upgrade -- possible corruption

2018-12-05 Thread Benjamin Smith 
My gut feeling is that this is related to a RAID1 issue I'm seeing with 7.6. 
See email thread "CentOS 7.6: Software RAID1 fails the only meaningful test" 

I suggest trying to boot from an earlier kernel. Good luck! 

Ben S 


On Wednesday, December 5, 2018 9:27:22 AM PST Gordon Messmer wrote:
> I've started updating systems to CentOS 7.6, and so far I have one failure.
> 
> This system has two peculiarities which might have triggered the
> problem.  The first is that one of the software RAID arrays on this
> system is degraded.  While troubleshooting the problem, I saw similar
> error messages mentioned in bug reports indicating that sGNU/Linux
> ystems would not boot with degraded software RAID arrays.  The other
> peculiar aspect is that the system uses dm-cache.
> 
> Logs from some of the early failed boots are not available, but before I
> completely fixed the problem, I was able to bring the system up once,
> and captured logs which look substantially similar to the initial boot.
> The content of /var/log/messages is here:
>   https://paste.fedoraproject.org/paste/n-E6X76FWIKzIvzPOw97uw
> 
> The output of lsblk (minus some VM logical volumes) is here:
>   https://paste.fedoraproject.org/paste/OizFvMeGn81vF52VEvUbyg
> 
> As best I can tell, the LVM tools were treating software RAID component
> devices as PVs, and detecting a conflict between those and the assembled
> RAID volume.  When running "pvs" on the broken system, no RAID volumes
> were listed, only component devices.  At the moment, I don't know if the
> LVs that were activated by the initrd were backed by component devices
> or the RAID devices, so it's possible that this bug might corrupt
> software RAID arrays.
> 
> In order to correct the problem, I had to add a global_filter to
> /etc/lvm/lvm.conf and rebuild the initrd (dracut -f):
>   global_filter = [ "r|vm_.*_data|", "a|sdd1|", "r|sd..|" ]
> 
> This filter excludes the LVs that contain VM data, accepts "/dev/sdd1"
> which is the dm-cache device, and rejects all other partitions on
> SCSI(SATA) device nodes, as all of those are RAID component devices.
> 
> I'm still working on the details of the problem, but I wanted to share
> what I know now in case anyone else might be affected.
> 
> After updating, look at the output of "pvs" if you use LVM on software RAID.
> ___
> 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

Re: [CentOS-es] OT Mails Zimbra

2018-12-05 Thread César Martínez M . 
Gracias Carlos el problema es que la aplicación de factiracion no permite usar 
envió con tls o ssl.

De echo el servidor tienen instalado un certificado letscript 

Saludos

César Martínez M. 
Ingeniero de Sistemas
Proyectos de Software Libre
Servicom
Móvil 0999374317

Enviado desde mi móvil samsung S8

El 5 de diciembre de 2018 13:57:56 GMT-05:00, Carlos Martinez 
 escribió:
>Saludos.
>
>Ahora es una necesidad que los servidores de correo usen SSL para
>enviar correos (comunicarse con otros servidores). De otra forma, les
>asignan una reputación pobre y se tienen muchos problemas de entrega.
>Además es una necesidad para proteger las contraseñas de los usuarios.
>
>Un certificado digital cuesta unos USD$100 al año con godaddy. Si no
>se desea pagar por ello, se puede usar letsencrypt con certbot que
>funcionan muy bien para zimbra. Lo malo de este último acercamiento es
>que cada tres meses hay que reiniciar el servicio de zimbra para que
>tome los certificados renovados. Todo esto se puede hacer con un
>script para despreocuparse de la tarea.
>
>Hasta la próxima.
>
>Carlos Martínez.
>
>
>On Wed, Dec 5, 2018 at 1:30 PM Cesar Martinez M.
> wrote:
>>
>> Saludos amigos tengo un servidor zimbra 8.8.10 el cuál esta
>funcionando
>> bien, ahora por temas de facturación se a implementado un sistema el
>> cuál necesita enviar emails pero este sistema no soporta TLS o SSl,
>la
>> pregunta es:
>>
>> Existe alguna forma de configurar zimbra para que el envió de emails
>no
>> sea obligatorio con SSl, que se pueda usar el puerto 25 o 587 y este
>> último sin TLS.
>>
>> De ante mano gracias a todos quienes puedan echarme una mano con esta
>> consulta.
>>
>> --
>> |Saludos Cordiales
>> |César Martínez M. | Ingeniero de Sistemas
>> |Consultor & Proyectos Software Libre| SERVICOM
>> |Teléfono: (593-2)554-271 2221-386 | Ext 4501
>> |Celular:593 999374317 |Skype servicomecuador
>> |Web www.servicomecuador.com Síguenos en:
>> |Twitter: @servicomecuador |Facebook: servicomec
>> |Zona Clientes: www.servicomecuador.com/billing
>> |Blog: http://servicomecuador.com/blog
>> |Dir. Av. 10 de Agosto N29-140 Entre
>> |Acuña y  Cuero y Caicedo
>> |Quito - Ecuador - Sudamérica
>>
>> ___
>> CentOS-es mailing list
>> CentOS-es@centos.org
>> https://lists.centos.org/mailman/listinfo/centos-es
>___
>CentOS-es mailing list
>CentOS-es@centos.org
>https://lists.centos.org/mailman/listinfo/centos-es
___
CentOS-es mailing list
CentOS-es@centos.org
https://lists.centos.org/mailman/listinfo/centos-es

Re: [CentOS-es] OT Mails Zimbra

2018-12-05 Thread Carlos Martinez 
Saludos.

Ahora es una necesidad que los servidores de correo usen SSL para
enviar correos (comunicarse con otros servidores). De otra forma, les
asignan una reputación pobre y se tienen muchos problemas de entrega.
Además es una necesidad para proteger las contraseñas de los usuarios.

Un certificado digital cuesta unos USD$100 al año con godaddy. Si no
se desea pagar por ello, se puede usar letsencrypt con certbot que
funcionan muy bien para zimbra. Lo malo de este último acercamiento es
que cada tres meses hay que reiniciar el servicio de zimbra para que
tome los certificados renovados. Todo esto se puede hacer con un
script para despreocuparse de la tarea.

Hasta la próxima.

Carlos Martínez.


On Wed, Dec 5, 2018 at 1:30 PM Cesar Martinez M.
 wrote:
>
> Saludos amigos tengo un servidor zimbra 8.8.10 el cuál esta funcionando
> bien, ahora por temas de facturación se a implementado un sistema el
> cuál necesita enviar emails pero este sistema no soporta TLS o SSl, la
> pregunta es:
>
> Existe alguna forma de configurar zimbra para que el envió de emails no
> sea obligatorio con SSl, que se pueda usar el puerto 25 o 587 y este
> último sin TLS.
>
> De ante mano gracias a todos quienes puedan echarme una mano con esta
> consulta.
>
> --
> |Saludos Cordiales
> |César Martínez M. | Ingeniero de Sistemas
> |Consultor & Proyectos Software Libre| SERVICOM
> |Teléfono: (593-2)554-271 2221-386 | Ext 4501
> |Celular:593 999374317 |Skype servicomecuador
> |Web www.servicomecuador.com Síguenos en:
> |Twitter: @servicomecuador |Facebook: servicomec
> |Zona Clientes: www.servicomecuador.com/billing
> |Blog: http://servicomecuador.com/blog
> |Dir. Av. 10 de Agosto N29-140 Entre
> |Acuña y  Cuero y Caicedo
> |Quito - Ecuador - Sudamérica
>
> ___
> CentOS-es mailing list
> CentOS-es@centos.org
> https://lists.centos.org/mailman/listinfo/centos-es
___
CentOS-es mailing list
CentOS-es@centos.org
https://lists.centos.org/mailman/listinfo/centos-es

[CentOS] New CentOS7 Install Yum will not work

2018-12-05 Thread Ed Morrison 
Hi Everyone:

I have been fighting this all morning.  I did a new (several) installs of
CentOS7.  Yum will not update the system.  I have disabled ipv6, set
yum.conf to use IPv4 only, disabled firewalld, disabled selinux, used both
static ip and dhcp for network connectivity.  I can ping any where on the
Internet, including the mirrors, DNS works and ensured the base URL line
was uncommented.  Any help would be appreciated.

Thanks,
Ed

This is the latest error I am seeing:
[root@localhost ~]# yum check-update
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
Could not retrieve mirrorlist
http://mirrorlist.centos.org/?release=7=x86_64=os=stock
error was
14: curl#7 - "Failed connect to mirrorlist.centos.org:80; Operation now in
progress"
Could not retrieve mirrorlist
http://mirrorlist.centos.org/?release=7=x86_64=extras=stock
error was
14: curl#7 - "Failed connect to mirrorlist.centos.org:80; Operation now in
progress"


 One of the configured repositories failed (Unknown),
 and yum doesn't have enough cached data to continue. At this point the only
 safe thing yum can do is fail. There are a few ways to work "fix" this:

 1. Contact the upstream for the repository and get them to fix the
problem.

 2. Reconfigure the baseurl/etc. for the repository, to point to a
working
upstream. This is most often useful if you are using a newer
distribution release than is supported by the repository (and the
packages for the previous distribution release still work).

 3. Run the command with the repository temporarily disabled
yum --disablerepo= ...

 4. Disable the repository permanently, so yum won't use it by default.
Yum
will then just ignore the repository until you permanently enable it
again or use --enablerepo for temporary usage:

yum-config-manager --disable 
or
subscription-manager repos --disable=

 5. Configure the failing repository to be skipped, if it is
unavailable.
Note that yum will try to contact the repo. when it runs most
commands,
so will have to try and fail each time (and thus. yum will be be
much
slower). If it is a very temporary problem though, this is often a
nice
compromise:

yum-config-manager --save
--setopt=.skip_if_unavailable=true

Cannot find a valid baseurl for repo: extras/7/x86_64
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Accidentally nuked my system - any suggestions ?

2018-12-05 Thread Nicolas Kovacs 
Le 05/12/2018 à 08:31, Phil Perry a écrit :
> If you are confident in the state of sda, I would remove sdb from the
> array, copy the partition table from sda to sdb as Stephen suggested
> earlier, then add sdb back to the array and allow the data to be synced:
> 
> For example:
> 
> mdadm --fail /dev/md125 /dev/sdb2
> mdadm --remove /dev/md125 /dev/sdb2
> 
> mdadm --fail /dev/md126 /dev/sdb1
> mdadm --remove /dev/md126 /dev/sdb1
> 
> mdadm --fail /dev/md127 /dev/sdb3
> mdadm --remove /dev/md127 /dev/sdb3
> 
> sfdisk –d /dev/sda | sfdisk /dev/sdb
> 
> then add them back and watch then rebuild:
> 
> mdadm --add /dev/md125 /dev/sdb2
> mdadm --add /dev/md126 /dev/sdb1
> mdadm --add /dev/md127 /dev/sdb3
> 
> After they have all resynced, I would flush the device buffers for good
> measure. For example:
> 
> blockdev --flushbufs /dev/sdb1
> ...
> 
> Lastly, don't forget to reinstall grub to sdb:
> 
> grub2-install --recheck /dev/sdb

Thanks very much for the detailed answer. I'll probably give this a spin
next week, since right now I have an urgent job to finish, and I'm happy
to be able to work on a usable system even though it's a bit sluggish.
As soon as the stress is over, I'll try it out.

cheers,

Niki

-- 
Microlinux - Solutions informatiques durables
7, place de l'église - 30730 Montpezat
Site : https://www.microlinux.fr
Blog : https://blog.microlinux.fr
Mail : i...@microlinux.fr
Tél. : 04 66 63 10 32
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] 7.5 -> 7.6 problems

2018-12-05 Thread Stephen John Smoogen 
On Wed, 5 Dec 2018 at 13:00, Gregory P. Ennis  wrote:
>
>
>
> On Wed, 5 Dec 2018 at 10:17, Gregory P. Ennis  wrote:
>
>
> Can you post what they are missing? Without that info it is not clear
> what the problem is (I seem to have several of them installed on an
> upgrade so I am not sure what blocked you).
>
> Stephen,
>
> Here is the full result.  Part of the problem I am having is that this
> was a development lab testing machine, and I have some repositories on
> it that I normally do not enable.
>
> virtualbox.repo
> epel.repo
> CentOS-Xen-dependencies.repo
> CentOS-Xen.repo
>
> I have turned these off for now, and the list below is after the above
> repositories were disabled.
>

So the problem is because of those missing repositories. You have
things which are from them which either need a rebuild or removal. The
core problem looks to be:

> Error: Package: libvirt-daemon-driver-xen-4.1.0-2.xen48.el7.x86_64
> (@centos-virt-xen-48)

> Error: Package: libvirt-daemon-driver-xen-4.1.0-2.xen48.el7.x86_64
> (@centos-virt-xen-48)

> Error: Package: libvirt-daemon-driver-libxl-4.1.0-2.xen48.el7.x86_64
> (@centos-virt-xen-48)

Error: Package: libvirt-daemon-driver-xen-4.1.0-2.xen48.el7.x86_64
(@centos-virt-xen-48)

That is what stops the rest from updating.

>


-- 
Stephen J Smoogen.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS-es] OT Mails Zimbra

2018-12-05 Thread Cesar Martinez M. 
Saludos amigos tengo un servidor zimbra 8.8.10 el cuál esta funcionando 
bien, ahora por temas de facturación se a implementado un sistema el 
cuál necesita enviar emails pero este sistema no soporta TLS o SSl, la 
pregunta es:


Existe alguna forma de configurar zimbra para que el envió de emails no 
sea obligatorio con SSl, que se pueda usar el puerto 25 o 587 y este 
último sin TLS.


De ante mano gracias a todos quienes puedan echarme una mano con esta 
consulta.


--
|Saludos Cordiales
|César Martínez M. | Ingeniero de Sistemas
|Consultor & Proyectos Software Libre| SERVICOM
|Teléfono: (593-2)554-271 2221-386 | Ext 4501
|Celular:593 999374317 |Skype servicomecuador
|Web www.servicomecuador.com Síguenos en:
|Twitter: @servicomecuador |Facebook: servicomec
|Zona Clientes: www.servicomecuador.com/billing
|Blog: http://servicomecuador.com/blog
|Dir. Av. 10 de Agosto N29-140 Entre
|Acuña y  Cuero y Caicedo
|Quito - Ecuador - Sudamérica

___
CentOS-es mailing list
CentOS-es@centos.org
https://lists.centos.org/mailman/listinfo/centos-es

Re: [CentOS] 7.5 -> 7.6 problems

2018-12-05 Thread Gregory P. Ennis 



On Wed, 5 Dec 2018 at 10:17, Gregory P. Ennis  wrote:


Can you post what they are missing? Without that info it is not clear
what the problem is (I seem to have several of them installed on an
upgrade so I am not sure what blocked you).

Stephen,

Here is the full result.  Part of the problem I am having is that this
was a development lab testing machine, and I have some repositories on
it that I normally do not enable.

virtualbox.repo
epel.repo
CentOS-Xen-dependencies.repo
CentOS-Xen.repo

I have turned these off for now, and the list below is after the above
repositories were disabled.

Greg

Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
 * base: mirror.dal10.us.leaseweb.net
 * centosplus: mirror.dal10.us.leaseweb.net
 * extras: mirror.dal10.us.leaseweb.net
 * nux-dextop: li.nux.ro
 * updates: mirror.dal10.us.leaseweb.net
Resolving Dependencies
--> Running transaction check
---> Package libvirt-bash-completion.x86_64 0:4.1.0-2.xen48.el7 will be
updated
---> Package libvirt-bash-completion.x86_64 0:4.5.0-10.el7_6.3 will be
an update
---> Package libvirt-client.x86_64 0:4.1.0-2.xen48.el7 will be updated
---> Package libvirt-client.x86_64 0:4.5.0-10.el7_6.3 will be an update
---> Package libvirt-daemon.x86_64 0:4.1.0-2.xen48.el7 will be updated
--> Processing Dependency: libvirt-daemon = 4.1.0-2.xen48.el7 for
package: libvirt-daemon-driver-xen-4.1.0-2.xen48.el7.x86_64
--> Processing Dependency: libvirt-daemon = 4.1.0-2.xen48.el7 for
package: libvirt-daemon-driver-libxl-4.1.0-2.xen48.el7.x86_64
---> Package libvirt-daemon.x86_64 0:4.5.0-10.el7_6.3 will be an update
---> Package libvirt-daemon-config-network.x86_64 0:4.1.0-2.xen48.el7
will be updated
---> Package libvirt-daemon-config-network.x86_64 0:4.5.0-10.el7_6.3
will be an update
---> Package libvirt-daemon-config-nwfilter.x86_64 0:4.1.0-2.xen48.el7
will be updated
---> Package libvirt-daemon-config-nwfilter.x86_64 0:4.5.0-10.el7_6.3
will be an update
---> Package libvirt-daemon-driver-interface.x86_64 0:4.1.0-2.xen48.el7 
will be updated
---> Package libvirt-daemon-driver-interface.x86_64 0:4.5.0-10.el7_6.3
will be an update
---> Package libvirt-daemon-driver-lxc.x86_64 0:4.1.0-2.xen48.el7 will
be updated
---> Package libvirt-daemon-driver-lxc.x86_64 0:4.5.0-10.el7_6.3 will
be an update
---> Package libvirt-daemon-driver-network.x86_64 0:4.1.0-2.xen48.el7
will be updated
---> Package libvirt-daemon-driver-network.x86_64 0:4.5.0-10.el7_6.3
will be an update
---> Package libvirt-daemon-driver-nodedev.x86_64 0:4.1.0-2.xen48.el7
will be updated
---> Package libvirt-daemon-driver-nodedev.x86_64 0:4.5.0-10.el7_6.3
will be an update
---> Package libvirt-daemon-driver-nwfilter.x86_64 0:4.1.0-2.xen48.el7
will be updated
---> Package libvirt-daemon-driver-nwfilter.x86_64 0:4.5.0-10.el7_6.3
will be an update
---> Package libvirt-daemon-driver-qemu.x86_64 0:4.1.0-2.xen48.el7 will
be updated
---> Package libvirt-daemon-driver-qemu.x86_64 0:4.5.0-10.el7_6.3 will
be an update
---> Package libvirt-daemon-driver-secret.x86_64 0:4.1.0-2.xen48.el7
will be updated
---> Package libvirt-daemon-driver-secret.x86_64 0:4.5.0-10.el7_6.3
will be an update
---> Package libvirt-daemon-driver-storage.x86_64 0:4.1.0-2.xen48.el7
will be updated
---> Package libvirt-daemon-driver-storage.x86_64 0:4.5.0-10.el7_6.3
will be an update
---> Package libvirt-daemon-driver-storage-core.x86_64 0:4.1.0-
2.xen48.el7 will be updated
---> Package libvirt-daemon-driver-storage-core.x86_64 0:4.5.0-
10.el7_6.3 will be an update
---> Package libvirt-daemon-driver-storage-disk.x86_64 0:4.1.0-
2.xen48.el7 will be updated
---> Package libvirt-daemon-driver-storage-disk.x86_64 0:4.5.0-
10.el7_6.3 will be an update
---> Package libvirt-daemon-driver-storage-gluster.x86_64 0:4.1.0-
2.xen48.el7 will be updated
---> Package libvirt-daemon-driver-storage-gluster.x86_64 0:4.5.0-
10.el7_6.3 will be an update
---> Package libvirt-daemon-driver-storage-iscsi.x86_64 0:4.1.0-
2.xen48.el7 will be updated
---> Package libvirt-daemon-driver-storage-iscsi.x86_64 0:4.5.0-
10.el7_6.3 will be an update
---> Package libvirt-daemon-driver-storage-logical.x86_64 0:4.1.0-
2.xen48.el7 will be updated
---> Package libvirt-daemon-driver-storage-logical.x86_64 0:4.5.0-
10.el7_6.3 will be an update
---> Package libvirt-daemon-driver-storage-mpath.x86_64 0:4.1.0-
2.xen48.el7 will be updated
---> Package libvirt-daemon-driver-storage-mpath.x86_64 0:4.5.0-
10.el7_6.3 will be an update
---> Package libvirt-daemon-driver-storage-rbd.x86_64 0:4.1.0-
2.xen48.el7 will be updated
---> Package libvirt-daemon-driver-storage-rbd.x86_64 0:4.5.0-
10.el7_6.3 will be an update
---> Package libvirt-daemon-driver-storage-scsi.x86_64 0:4.1.0-
2.xen48.el7 will be updated
---> Package libvirt-daemon-driver-storage-scsi.x86_64 0:4.5.0-
10.el7_6.3 will be an update
---> Package libvirt-daemon-kvm.x86_64 0:4.1.0-2.xen48.el7 will be
updated
---> Package libvirt-daemon-kvm.x86_64 0:4.5.0-10.el7_6.3 will be an

Re: [CentOS] LVM failure after CentOS 7.6 upgrade -- possible corruption

2018-12-05 Thread Simon Matter 
> I've started updating systems to CentOS 7.6, and so far I have one
> failure.
>
> This system has two peculiarities which might have triggered the
> problem.  The first is that one of the software RAID arrays on this
> system is degraded.  While troubleshooting the problem, I saw similar
> error messages mentioned in bug reports indicating that sGNU/Linux
> ystems would not boot with degraded software RAID arrays.  The other
> peculiar aspect is that the system uses dm-cache.
>
> Logs from some of the early failed boots are not available, but before I
> completely fixed the problem, I was able to bring the system up once,
> and captured logs which look substantially similar to the initial boot.
> The content of /var/log/messages is here:
>   https://paste.fedoraproject.org/paste/n-E6X76FWIKzIvzPOw97uw
>
> The output of lsblk (minus some VM logical volumes) is here:
>   https://paste.fedoraproject.org/paste/OizFvMeGn81vF52VEvUbyg
>
> As best I can tell, the LVM tools were treating software RAID component
> devices as PVs, and detecting a conflict between those and the assembled
> RAID volume.  When running "pvs" on the broken system, no RAID volumes
> were listed, only component devices.  At the moment, I don't know if the
> LVs that were activated by the initrd were backed by component devices
> or the RAID devices, so it's possible that this bug might corrupt
> software RAID arrays.
>
> In order to correct the problem, I had to add a global_filter to
> /etc/lvm/lvm.conf and rebuild the initrd (dracut -f):
>   global_filter = [ "r|vm_.*_data|", "a|sdd1|", "r|sd..|" ]
>
> This filter excludes the LVs that contain VM data, accepts "/dev/sdd1"
> which is the dm-cache device, and rejects all other partitions on
> SCSI(SATA) device nodes, as all of those are RAID component devices.
>
> I'm still working on the details of the problem, but I wanted to share
> what I know now in case anyone else might be affected.
>
> After updating, look at the output of "pvs" if you use LVM on software
> RAID.

What exactly did `pvs' show and instead of what?

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Issue updating to 7.6

2018-12-05 Thread Stephen John Smoogen 
On Wed, 5 Dec 2018 at 12:06, Jerry Geis  wrote:
>
> Hi all... Great work on 7.6!
>
> I updated a number of boxes - all good! This "one" server I lost connection
> through the internet or something... Anyway 702 transactions left and its
> not happy. When I run yum-complete-transaction I get "many"
>
> Removing man-db.x86_64 0:2.6.3-9.el7 - ud from the transaction
> Removing man-db.x86_64 0:2.6.3-11.el7 - u from the transaction
> Removing python-ethtool.x86_64 0:0.8-5.el7 - ud from the transaction
> Removing python-ethtool.x86_64 0:0.8-7.el7 - u from the transaction
> Removing iprutils.x86_64 0:2.4.15.1-1.el7 - ud from the transaction
> Removing iprutils.x86_64 0:2.4.16.1-1.el7 - u from the transaction
> Removing strace.x86_64 0:4.12-6.el7 - ud from the transaction
> Removing strace.x86_64 0:4.12-9.el7 - u from the transaction
>
> and then nothing happens (This is just a short list) many are printed.
>
> Thoughts? What next?

I had a spurious problem on updating large number of packages which
would cause a similar problem. I needed to break the update on these
systems into 2 transactions:
1. yum update --skip-broken --exclude="gdm*" --exclude="java-1.7.0"
--exclude="NetworkManager*" --exclude="ModemManager*"
2. yum update

Not every system did this and there didn't seem to be a rhyme or
reason on why it happened for the ones I ran into it (plenty of
memory, plenty of CPU, etc etc)

> Jerry
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos



-- 
Stephen J Smoogen.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Issue updating to 7.6

2018-12-05 Thread Frank Cox 
On Wed, 5 Dec 2018 12:06:06 -0500
Jerry Geis wrote:

> This "one" server I lost connection
> through the internet or something... 

Not of any direct help to you now, but I learned the hard way that it's always 
wise to run yum in a screen session when updating anything other than your 
local computer.  That way if your connection to the box drops everything will 
just keep on truckin' anyway and you can reconnect any time and it's just like 
nothing bad happened at all.

-- 
MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] 7.5 -> 7.6 problems

2018-12-05 Thread Stephen John Smoogen 
On Wed, 5 Dec 2018 at 10:17, Gregory P. Ennis  wrote:
>
> To all,
>
> I started the process of updating some of our systems from 7.5 to 7.6.
> Most of the servers had no problems, but several of the desktops had
> some difficulties.  I was required to perform several yum commands to
> update as much as possible in the format of yum update a* then b* etc.
>
> Then after I got everything updated that would update in this manner
> and after the use of "rpm -Va --nofiles --nodigest" and with the use of
> yum update --skip-broken I am getting the following that would not
> update :
>
> Packages skipped because of dependency problems:
> libvirt-bash-completion-4.5.0-10.el7_6.3.x86_64 from updates
> libvirt-client-4.5.0-10.el7_6.3.x86_64 from updates
> libvirt-daemon-4.5.0-10.el7_6.3.x86_64 from updates
> libvirt-daemon-config-network-4.5.0-10.el7_6.3.x86_64 from updates
> libvirt-daemon-config-nwfilter-4.5.0-10.el7_6.3.x86_64 from updates
> libvirt-daemon-driver-interface-4.5.0-10.el7_6.3.x86_64 from updates
> libvirt-daemon-driver-lxc-4.5.0-10.el7_6.3.x86_64 from updates
> libvirt-daemon-driver-network-4.5.0-10.el7_6.3.x86_64 from updates
> libvirt-daemon-driver-nodedev-4.5.0-10.el7_6.3.x86_64 from updates
> libvirt-daemon-driver-nwfilter-4.5.0-10.el7_6.3.x86_64 from updates
> libvirt-daemon-driver-qemu-4.5.0-10.el7_6.3.x86_64 from updates
> libvirt-daemon-driver-secret-4.5.0-10.el7_6.3.x86_64 from updates
> libvirt-daemon-driver-storage-4.5.0-10.el7_6.3.x86_64 from updates
> libvirt-daemon-driver-storage-core-4.5.0-10.el7_6.3.x86_64 from updates
> libvirt-daemon-driver-storage-disk-4.5.0-10.el7_6.3.x86_64 from updates
> libvirt-daemon-driver-storage-gluster-4.5.0-10.el7_6.3.x86_64 from upd
> libvirt-daemon-driver-storage-iscsi-4.5.0-10.el7_6.3.x86_64 from upd
> libvirt-daemon-driver-storage-logical-4.5.0-10.el7_6.3.x86_64 from upd
> libvirt-daemon-driver-storage-mpath-4.5.0-10.el7_6.3.x86_64 from upd
> libvirt-daemon-driver-storage-rbd-4.5.0-10.el7_6.3.x86_64 from updates
> libvirt-daemon-driver-storage-scsi-4.5.0-10.el7_6.3.x86_64 from updates
> libvirt-daemon-kvm-4.5.0-10.el7_6.3.x86_64 from updates
> libvirt-devel-4.5.0-10.el7_6.3.x86_64 from updates
> libvirt-libs-4.5.0-10.el7.x86_64 from base
> libvirt-libs-4.5.0-10.el7_6.2.x86_64 from updates
> libvirt-libs-4.5.0-10.el7_6.3.x86_64 from updates
> libvirt-python-4.5.0-1.el7.x86_64 from base

Can you post what they are missing? Without that info it is not clear
what the problem is (I seem to have several of them installed on an
upgrade so I am not sure what blocked you).

>
> Is there something I can do to finish this process or is this just
> related to a repository problem.
>
> --
> Greg Ennis
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos



-- 
Stephen J Smoogen.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] LVM failure after CentOS 7.6 upgrade -- possible corruption

2018-12-05 Thread Gordon Messmer 

I've started updating systems to CentOS 7.6, and so far I have one failure.

This system has two peculiarities which might have triggered the 
problem.  The first is that one of the software RAID arrays on this 
system is degraded.  While troubleshooting the problem, I saw similar 
error messages mentioned in bug reports indicating that sGNU/Linux 
ystems would not boot with degraded software RAID arrays.  The other 
peculiar aspect is that the system uses dm-cache.


Logs from some of the early failed boots are not available, but before I 
completely fixed the problem, I was able to bring the system up once, 
and captured logs which look substantially similar to the initial boot. 
The content of /var/log/messages is here:

https://paste.fedoraproject.org/paste/n-E6X76FWIKzIvzPOw97uw

The output of lsblk (minus some VM logical volumes) is here:
https://paste.fedoraproject.org/paste/OizFvMeGn81vF52VEvUbyg

As best I can tell, the LVM tools were treating software RAID component 
devices as PVs, and detecting a conflict between those and the assembled 
RAID volume.  When running "pvs" on the broken system, no RAID volumes 
were listed, only component devices.  At the moment, I don't know if the 
LVs that were activated by the initrd were backed by component devices 
or the RAID devices, so it's possible that this bug might corrupt 
software RAID arrays.


In order to correct the problem, I had to add a global_filter to 
/etc/lvm/lvm.conf and rebuild the initrd (dracut -f):

global_filter = [ "r|vm_.*_data|", "a|sdd1|", "r|sd..|" ]

This filter excludes the LVs that contain VM data, accepts "/dev/sdd1" 
which is the dm-cache device, and rejects all other partitions on 
SCSI(SATA) device nodes, as all of those are RAID component devices.


I'm still working on the details of the problem, but I wanted to share 
what I know now in case anyone else might be affected.


After updating, look at the output of "pvs" if you use LVM on software RAID.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Issue updating to 7.6

2018-12-05 Thread Jerry Geis 
Hi all... Great work on 7.6!

I updated a number of boxes - all good! This "one" server I lost connection
through the internet or something... Anyway 702 transactions left and its
not happy. When I run yum-complete-transaction I get "many"

Removing man-db.x86_64 0:2.6.3-9.el7 - ud from the transaction
Removing man-db.x86_64 0:2.6.3-11.el7 - u from the transaction
Removing python-ethtool.x86_64 0:0.8-5.el7 - ud from the transaction
Removing python-ethtool.x86_64 0:0.8-7.el7 - u from the transaction
Removing iprutils.x86_64 0:2.4.15.1-1.el7 - ud from the transaction
Removing iprutils.x86_64 0:2.4.16.1-1.el7 - u from the transaction
Removing strace.x86_64 0:4.12-6.el7 - ud from the transaction
Removing strace.x86_64 0:4.12-9.el7 - u from the transaction

and then nothing happens (This is just a short list) many are printed.

Thoughts? What next?

Jerry
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] 7.5 -> 7.6 problems

2018-12-05 Thread Gregory P. Ennis 
To all,

I started the process of updating some of our systems from 7.5 to 7.6. 
Most of the servers had no problems, but several of the desktops had
some difficulties.  I was required to perform several yum commands to
update as much as possible in the format of yum update a* then b* etc. 

Then after I got everything updated that would update in this manner
and after the use of "rpm -Va --nofiles --nodigest" and with the use of
yum update --skip-broken I am getting the following that would not
update :

Packages skipped because of dependency problems:
libvirt-bash-completion-4.5.0-10.el7_6.3.x86_64 from updates
libvirt-client-4.5.0-10.el7_6.3.x86_64 from updates
libvirt-daemon-4.5.0-10.el7_6.3.x86_64 from updates
libvirt-daemon-config-network-4.5.0-10.el7_6.3.x86_64 from updates
libvirt-daemon-config-nwfilter-4.5.0-10.el7_6.3.x86_64 from updates
libvirt-daemon-driver-interface-4.5.0-10.el7_6.3.x86_64 from updates
libvirt-daemon-driver-lxc-4.5.0-10.el7_6.3.x86_64 from updates
libvirt-daemon-driver-network-4.5.0-10.el7_6.3.x86_64 from updates
libvirt-daemon-driver-nodedev-4.5.0-10.el7_6.3.x86_64 from updates
libvirt-daemon-driver-nwfilter-4.5.0-10.el7_6.3.x86_64 from updates
libvirt-daemon-driver-qemu-4.5.0-10.el7_6.3.x86_64 from updates
libvirt-daemon-driver-secret-4.5.0-10.el7_6.3.x86_64 from updates
libvirt-daemon-driver-storage-4.5.0-10.el7_6.3.x86_64 from updates
libvirt-daemon-driver-storage-core-4.5.0-10.el7_6.3.x86_64 from updates
libvirt-daemon-driver-storage-disk-4.5.0-10.el7_6.3.x86_64 from updates
libvirt-daemon-driver-storage-gluster-4.5.0-10.el7_6.3.x86_64 from upd
libvirt-daemon-driver-storage-iscsi-4.5.0-10.el7_6.3.x86_64 from upd
libvirt-daemon-driver-storage-logical-4.5.0-10.el7_6.3.x86_64 from upd
libvirt-daemon-driver-storage-mpath-4.5.0-10.el7_6.3.x86_64 from upd
libvirt-daemon-driver-storage-rbd-4.5.0-10.el7_6.3.x86_64 from updates
libvirt-daemon-driver-storage-scsi-4.5.0-10.el7_6.3.x86_64 from updates
libvirt-daemon-kvm-4.5.0-10.el7_6.3.x86_64 from updates
libvirt-devel-4.5.0-10.el7_6.3.x86_64 from updates
libvirt-libs-4.5.0-10.el7.x86_64 from base
libvirt-libs-4.5.0-10.el7_6.2.x86_64 from updates
libvirt-libs-4.5.0-10.el7_6.3.x86_64 from updates
libvirt-python-4.5.0-1.el7.x86_64 from base


Is there something I can do to finish this process or is this just
related to a repository problem.

-- 
Greg Ennis
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Problems compiling kernel module

2018-12-05 Thread Greg Bailey 

On 12/05/2018 07:46 AM, Klaus Kolle wrote:

Hi

I just upgraded a virtual Centos from 7.5 to 7.6 and now the VirtualBox
Extensions won't compile with the kernel.

I looked into the log file and found that I should try to execute:

make oldconfig && make prepare

but I get this result:
  scripts/kconfig/conf --oldconfig Kconfig
  #
  # configuration written to .config
  #
  scripts/kconfig/conf --silentoldconfig Kconfig
  make[1]: *** No rule to make target `arch/x86/syscalls/syscall_32.tbl',
  needed by
`arch/x86/syscalls/../include/generated/uapi/asm/unistd_32.h'.   Stop.
  make: *** [archheaders] Error 2


What could be wrong?




Are you using the 5.2.23 test version of VirtualBox?  5.2.22 won't work, 
as mentioned in the release notes at 
https://wiki.centos.org/Manuals/ReleaseNotes/CentOS7.1810


"If you use VirtualBox to run CentOS 7.6.1810 as a guest with a GUI, you 
need version 5.2.23 to build graphics drivers. See VBox ticket 18093 
. Also, the mouse may not work 
properly as reported in this VBox forum thread 
."


-Greg

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Problems compiling kernel module

2018-12-05 Thread Klaus Kolle 
Hi

I just upgraded a virtual Centos from 7.5 to 7.6 and now the VirtualBox
Extensions won't compile with the kernel.

I looked into the log file and found that I should try to execute:

make oldconfig && make prepare

but I get this result:
 scripts/kconfig/conf --oldconfig Kconfig
 #
 # configuration written to .config
 #
 scripts/kconfig/conf --silentoldconfig Kconfig
 make[1]: *** No rule to make target `arch/x86/syscalls/syscall_32.tbl',
 needed by
`arch/x86/syscalls/../include/generated/uapi/asm/unistd_32.h'.   Stop.
 make: *** [archheaders] Error 2


What could be wrong?

|<

-- 
Med venlig hilsen

Klaus Kolle

Teknikumingeniør, B.Sc.EE., e-mail: kl...@kolle.dk
Master of ITwww   : www.kolle.dk
Kollundvej 5Telephone : +4586829682 / +4522216044
DK-8600 Silkeborg, Denmark

"Man skal ikke tilskrive til sammensværgelser hvad der tilstrækkeligt
kan forklares af inkompetence"
Poul Henning Kamp

Planlægning er tanker om noget man agter at gøre en gang i fremtiden,
hvis omstændighederne tillader det.
Klaus Kolle 2006

Perfection is achieved not when nothing more to add, but when there is
nothing more left to take away.
Antoine de Saint-Exupery



signature.asc
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] KVM Bridge Problem

2018-12-05 Thread Günther J . Niederwimmer 
Hello List,

thanks for the answer


Am Dienstag, 4. Dezember 2018, 21:59:58 CET schrieb Alexander Dalloz:
> Am 04.12.2018 um 21:30 schrieb Günther J. Niederwimmer:
> > Hello,
> > is this only my mistake,or can help any from the list?
> > 
> > I have 3 host computer on different places, but all have the Problem when
> > starting a client "KVM" to connect to the bridge from the host.
> > 
> > It is near not possible to start a client, only after 10-20 reboot/restart
> > from the client's the network is starting correct?
> 
> Logs are the only source of truth. Without them everything is pure
> speculation.

this are the Error log
[ INFO ] Network Manager is not active.
[DEPEND] Dependency failed for Network Manager Wait Online.
 Starting LSB: Bring up/down networking...
[FAILED] Failed to start LSB: Bring up/down networking.
See 'systemctl status network.service' for details.

A "systemctl restart network" ends with a error

I mean without NetworkManager I have always this Error in KVM Clients now, 
with Update 1810 ?

I have found a workaround for me in the Momemt.
I enable NetworManager on boot and disable NetworkManager in the ifcfg-ethX 
files

Now the most time the clients are starting with a working Network ??

 
> > Is this  only on my computers or have other also this Problem?
> > 
> > Is the bridge software is broken ?
> 
> What does your system report in the relevant log files?
> 
> > Can I use openvswitch to replace bridge Software?
> 
> Sure you can. It takes a bit more effort to setup openvswitch. It can be
> worth it depending on your network design.
> 
> > Any help are welcome ;-)
> 
> First of all it would be necessary from your side to provide details
> about your setup. Running KVM with a bridge setup is not enough info.
> 
> Get your config sorted and the logs.
> 
> Alexander
> 
> 
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos


-- 
mit freundliche Grüßen / best regards,

  Günther J. Niederwimmer

signature.asc
Description: This is a digitally signed message part.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Weird problems with CentOS 7.6 1810 installer

2018-12-05 Thread Stephen John Smoogen 
On Wed, 5 Dec 2018 at 02:02, Nicolas Kovacs  wrote:
>
> Hi,
>
> I just updated my installation media for CentOS. I have a few sandbox
> PCs in my office, and I'm testing CentOS 7.6 1810 on them. There seem to
> be a few issues with the CentOS 7.6 1810 DVD.
>
> Checked DVD integrity on startup : OK.
>
> First attempt : installer froze on root password dialog.
>
> Second attempt : installer froze on dependency calculation.
>
> Third attempt : installer froze on network interface definition.
>
> Similar behavior on two different machines.
>
> On the same machine, the minimal DVD seems to work OK.
>
> I could manage to switch to another virtual console, and I have the
> following kernel log messages:
>
> WARNING: kernel:perf: interrupt took too long
>
> Any idea what's going on here?
>
> I should add that all the previous CentOS 7 installation DVDs worked
> perfectly on these PCs (Dell Optiplex 330).
>

Well the Captain Obvious answer is something hardware related is
taking too long while the system is working out sample loads.
https://bbs.archlinux.org/viewtopic.php?id=187636 It is supposedly an
informational versus the reason the system died.

How much memory do the systems have, what is its CPU, and how many
packages are you installing? [The Dell Optiplex 330 is from 2007 and
came with several different layouts so it might need info.] Finally
does the install work if you only choose what the minimal would
install?



> Cheers,
>
> Niki
> --
> Microlinux - Solutions informatiques durables
> 7, place de l'église - 30730 Montpezat
> Site : https://www.microlinux.fr
> Blog : https://blog.microlinux.fr
> Mail : i...@microlinux.fr
> Tél. : 04 66 63 10 32
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos



-- 
Stephen J Smoogen.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [SOLVED] C7 Bacula and Selinux

2018-12-05 Thread Alessandro Baggi 

Il 05/12/18 11:33, Alessandro Baggi ha scritto:

Hi list,
I'm trying to understand SELinux on C7.
I encountered problem running bacula when system is enforced.
The problem is when bacula try to run BeforeJobScript. In this script 
there is an occourrence to systemctl stop httpd and hostname command and 
I got error on permission on this 2 commands.


Reading RHEL 7 SELinux Guide seems that I need a domain transaction but 
I don't know how to solve this.


Can someone put me in the right direction?

Thanks in advance.


Hi list,
I solved my issue following centos selinux guide and creating a policy 
using audit2allow.


Thanks again
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] C7 Bacula and Selinux

2018-12-05 Thread Alessandro Baggi 

Hi list,
I'm trying to understand SELinux on C7.
I encountered problem running bacula when system is enforced.
The problem is when bacula try to run BeforeJobScript. In this script 
there is an occourrence to systemctl stop httpd and hostname command and 
I got error on permission on this 2 commands.


Reading RHEL 7 SELinux Guide seems that I need a domain transaction but 
I don't know how to solve this.


Can someone put me in the right direction?

Thanks in advance.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CR repo update disaster for my desktop.

2018-12-05 Thread Rob Kampen 

On 5/12/18 7:21 AM, Phil Perry wrote:

On 04/12/2018 09:54, Rob Kampen wrote:


So in an effort to narrow down the problem I also have an old Samsung 
laptop - i5 with an nvidia card - all up-to-date 7.5 - I thought I 
would try a more conservative upgrade approach.


first updated to the CR kernel with yum upgrade kernel*

then after successful reboot did an update to gdm* and gnome*

another reboot and all is well

then update of xorg* (only 20 files)

Now it will not boot - keyboard is non responsive so cannot even do a 
Ctrl Alt F2 to access a shell. Old kernel is also non boot. Left this 
machine for now and back to my main desktop workstation.




The only issue I've seen reported that sounds similar or possibly 
related is:


https://bugzilla.redhat.com/show_bug.cgi?id=1650634

Yes, seems this is the laptop issue, will prove tomorrow.


There is a patch in that bug you might like to try.
Not too keen on this, would need to find a detailed howto as I have not 
done any rebuilds for a number of years. I presume that RH will at some 
point release a fix for this?


No idea if this xorg problem relates to my original workstation - so 
on that machine I did a downgrade of xorg* - seemed to complete ok, 
but on reboot and login - still the same problem.


As the only clue in the logs is the libc segfault I did a downgrade 
of glibc - this too seemed to work but no change to the system - 
gnome crashes after 5 - 10 seconds.




I'm guessing that probably hasn't helped matters

Wasted far too much time on this, no idea what to do now so I have 
done a fresh 7.5 install and all works again - just need to install 
all the additional stuff I use each day, but at least I have a 
desktop that functions.



___
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

Re: [CentOS] CR repo update disaster for my desktop.

2018-12-05 Thread Rob Kampen 

On 5/12/18 5:30 AM, Jonathan Billings wrote:

On Tue, Dec 04, 2018 at 10:54:58PM +1300, Rob Kampen wrote:

So in an effort to narrow down the problem I also have an old Samsung laptop
- i5 with an nvidia card - all up-to-date 7.5 - I thought I would try a more
conservative upgrade approach.

first updated to the CR kernel with yum upgrade kernel*

then after successful reboot did an update to gdm* and gnome*

another reboot and all is well

then update of xorg* (only 20 files)

Now it will not boot - keyboard is non responsive so cannot even do a Ctrl
Alt F2 to access a shell. Old kernel is also non boot. Left this machine for
now and back to my main desktop workstation.

Where does it stop booting?  Can you remove 'rhgb quiet' from the
kernel command line and see how it is booting?  Also, are you using
UEFI boot or the old BIOS boot?


on the laptop it seems I have the Red Hat Bugzilla – Bug 1650634 
problem. It is bios boot.


My workstation has UEFI boot, but it has now been clean installed with 
7.5 and until there is a fix to the above bugzilla i'll hold off on 
doing much other than update the kernel.


Thanks for response, i will use the removal of rhgb quiet.






I will wait until 7.6 is officially released, watch the list for a week or
two and then with much fear and trepidation give it a go. 

7.6 has been released, so you should expect these packages to start
arriving on all your CentOS 7 systems.



___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CR repo update disaster for my desktop.

2018-12-05 Thread Rob Kampen 

On 5/12/18 4:17 AM, Simon Matter wrote:

On 4/12/18 9:06 AM, Rob Kampen wrote:

Sorry for top post, my android BlueMail will not let me insert at the
bottom.

I have found that tracker-extract seems to trigger a segfault. I note
this is not updated in CR, but comes from base. Removal of tracker seems
too harsh as it has dependant modules like brasero, evince, grilo,
nautilus and totem.
Maybe there is an obscure relationship in tracker that need attention.
Stumpped.

⁣Sent from BlueMail ​

On 03 Dec 2018, 11:28 PM, at 11:28 PM, Fabian Arrotin
 wrote:

On 03/12/2018 11:14, John Hodrien wrote:

On Mon, 3 Dec 2018, Simon Matter wrote:


Le 03/12/2018 à 06:25, Rob Kampen a écrit :

I enabled the CR repo and did the yum update. Some 800+ rpms were
offered and all seemed to resolve depenancies OK, so yes it was
started. The updates completed and all looked good, until the

reboot.

I got a similar disaster here. I guess the lesson to be learned is

that

CR is nice to have on servers, but don't use it on desktops.

My question is what will change with the final release of 7.6? I

thought

the CR repo usually holds all updates with the exception of
centos-release, or are there more updates to come? I had the

impression

that in the past, the final release brought only cosmetic changes

with

the
centos-release being updated.

I've seen zero problems on Desktops I've installed CR on.

If CR has issues, as you say you'd expect 7.6 to have problems.  If
things are
failing with CR updates, you really want to investigate what's going

on.

jh

+1 as 7.6.1810 is exactly 7.5.1804+updates+CR so only missing packages
are centos-release/anaconda and install tree/media ..

So if there are issues with CR, using the list and bugs.centos.org
would
be good.
BTW : the goal of CR is exactly to find those issues earlier and then
write Release Notes with workarounds/warnings

So in an effort to narrow down the problem I also have an old Samsung
laptop - i5 with an nvidia card - all up-to-date 7.5 - I thought I would
try a more conservative upgrade approach.

first updated to the CR kernel with yum upgrade kernel*

then after successful reboot did an update to gdm* and gnome*

another reboot and all is well

then update of xorg* (only 20 files)

Now it will not boot - keyboard is non responsive so cannot even do a
Ctrl Alt F2 to access a shell. Old kernel is also non boot. Left this
machine for now and back to my main desktop workstation.

No idea if this xorg problem relates to my original workstation - so on
that machine I did a downgrade of xorg* - seemed to complete ok, but on
reboot and login - still the same problem.

As the only clue in the logs is the libc segfault I did a downgrade of
glibc - this too seemed to work but no change to the system - gnome
crashes after 5 - 10 seconds.

Wasted far too much time on this, no idea what to do now so I have done
a fresh 7.5 install and all works again - just need to install all the
additional stuff I use each day, but at least I have a desktop that
functions.

I will wait until 7.6 is officially released, watch the list for a week
or two and then with much fear and trepidation give it a go. 

As a long time user of CentOS (well over a decade - I started with 5.x
workstations, then had a couple of 6.x, and used two 7.x machines, not
counting my servers), I must observe that the core server stuff "just
works" e.g. mail, mysql / mariadb, postfix, dovecot, apache, php. Even
the migration to libreoffice was okay.

The major version upgrades each gave an all over better desktop
experience. What has also happened however is that some of the 7.x
upgrades have been difficult to deal with - one of the recent firefox
updates lost all my local password databases which I do not back up to
the cloud for obvious reasons. Unable to resolve the instability after
many hours of testing and trialing combinations, I have left firefox and
moved to vivaldi - we'll see how that works. As upstream seems to
include more bleeding edge versions of major desktop utilities such as
firefox, stability has been compromised.

Now with this latest CR update, I have no idea if it is gnome, gdm, xorg
or some other component, but to have two quite differently configured
machines both loose their desktops, I am unhappy. The use of roll back
of over 800 files just didn't pass the transaction test thus that too
was futile.

I thought the approach I used with my laptop today was sufficiently
cautious, yet it caught me and I am still trying to work out what to do
next.

As always, happy to entertain ideas and suggestions. My main workstation
however is now safely working at a clean install of 7.5, thus cannot do
further tests there, life must go on, four days of down time is far too
much.

Also let me give a heartfelt thanks to the hard working CentOS team, I
see the more and more difficult task you need to navigate with each
major update, you do an outstanding task, and I am most grateful!

The big question remains, what