Início / user-173916

Jaroslav Kucera's questions

Martin Hope
Jaroslav Kucera
Asked: 2023-11-30 03:04:25 +0800 CST
  • 5

No RHEL 9.3 renomeei o volume lógico (LV) /dev/lvm01/rootpara /dev/lvm01/root.vol. Fiz de tudo para que o novo nome fosse reconhecido corretamente:

  • /etc/fstabentrada alterada
  • configuração do systemd recarregada
  • remontado /

E também modifiquei a /etc/default/grubentrada:

GRUB_CMDLINE_LINUX="root=/dev/mapper/lvm01-root.vol ro crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M resume=/dev/mapper/lvm01-swap.vol rd.lvm.lv=lvm01/root.vol rd.lvm.lv=lvm01/swap.vol"

Então eu esperava que ele grub2-mkconfig -o /boot/grub2/grub.cfgfizesse o resto do trabalho e reiniciei. Mas o sistema acabou com uma mensagem dracut informando que a partição raiz não foi encontrada (ou algo parecido).

Após uma breve investigação, percebi que os parâmetros do kernel não foram modificados conforme esperado. A mudança manual ajudou a inicializar o sistema operacional. Interessante que o /boot/grub2/grub.cfgfoi atualizado. Mas o que não foi atualizado foram os /boot/loader/entries/*arquivos. E esse era o problema.

rhel
Martin Hope
Jaroslav Kucera
Asked: 2019-06-04 03:53:54 +0800 CST
  • 1

Em nosso ambiente de teste, identificamos um comportamento estranho do HAProxy. Estamos usando o haproxy-1.5.18-8.el7.x86_64RPM padrão fornecido pelo RHEL 7.

De acordo com nosso entendimento, o número total de conexões paralelas aceitas é definido a partir maxconn*nbprocda globalseção do arquivo haproxy.cfg.

No entanto, se definirmos:

maxconn   5
nbproc    2

esperaríamos que o número total de conexões paralelas fosse 10. Mas não podemos superar maxconn5 definidos.

Por que o nbproc está sendo ignorado?

Aqui está o haproxy.cfg completo:

# Global settings
global
    log         127.0.0.1 local2 warning
    log         10.229.253.86 local2 warning

    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     5
    user        haproxy
    group       haproxy
    daemon
    nbproc      2

# turn on stats unix socket
    stats socket /var/lib/haproxy/stats
    stats socket /var/run/haproxy.sock mode 600 level admin
    stats socket /var/run/haproxy_hamonit.sock uid 2033 gid 2033 mode 600 level admin
    stats timeout 2m

defaults
    mode                    tcp
    log                     global
    option                  tcplog
    option                  dontlognull
    option                  redispatch

    retries                 3
    timeout http-request    10s
    timeout queue           1m
    timeout connect         10s
    timeout client          30s
    timeout server          30s
    timeout http-keep-alive 10s
    timeout check           10s

    bind-process            all

frontend ha01
    bind 10.229.253.89:80
    mode                        http
    option                      httplog
    option                      http-server-close
    option forwardfor           except 127.0.0.0/8

    default_backend             ha01

backend ha01
    balance roundrobin
    mode                        http
    option                      httplog
    option                      http-server-close
    option forwardfor           except 127.0.0.0/8
    server  server1 10.230.11.252:4240 check
    server  server2 10.230.11.252:4242 check

listen stats 10.229.253.89:1936
    mode http
    stats enable
    stats hide-version
    stats realm Haproxy\ Statistics
    stats uri /
    stats auth admin:foo
rhel load-balancing
Martin Hope
Jaroslav Kucera
Asked: 2018-08-02 03:58:19 +0800 CST
  • 2

Após a recente atualização do Fedora 27, meu convidado KVM VM acabou no kernel panic durante o processo de inicialização.

O sistema foi atualizado para libvirt-3.7.0-4.fc27.x86_64 (e muitos outros pacotes durante esta atualização) e reiniciado. Antes, o convidado da VM executando o Kubuntu 16.04 não tinha problemas. O kernel anterior no hipervisor não ajuda.

A CPU do host é AMD Athlon(tm) X4 750.

Qual é a causa desse problema repentino?

kvm fedora
Martin Hope
Jaroslav Kucera
Asked: 2018-07-25 04:06:32 +0800 CST
  • 1

No RHEL 7 ao atualizar com YUM depois de algum tempo a transação YUM não foi concluída corretamente pois a conexão com o servidor foi interrompida e a sessão YUM não foi executada na tela.

--> Processing Conflict: firewalld-0.4.4.4-6.el7.noarch conflicts selinux-policy < 3.13.1-118.el7
--> Finished Dependency Resolution
You could try using --skip-broken to work around the problem
** Found 157 pre-existing rpmdb problem(s), 'yum check' output follows:
audit-2.7.6-3.el7.x86_64 is a duplicate with audit-2.6.5-3.el7_3.1.x86_64
audit-libs-2.7.6-3.el7.x86_64 is a duplicate with audit-libs-2.6.5-3.el7_3.1.x86_64
audit-libs-python-2.7.6-3.el7.x86_64 is a duplicate with audit-libs-python-2.6.5-3.el7_3.1.x86_64
bash-4.2.46-29.el7_4.x86_64 is a duplicate with bash-4.2.46-21.el7_3.x86_64
32:bind-libs-9.9.4-51.el7_4.2.x86_64 is a duplicate with 32:bind-libs-9.9.4-50.el7_3.1.x86_64
32:bind-libs-lite-9.9.4-51.el7_4.2.x86_64 is a duplicate with 32:bind-libs-lite-9.9.4-50.el7_3.1.x86_64
32:bind-license-9.9.4-51.el7_4.2.noarch is a duplicate with 32:bind-license-9.9.4-50.el7_3.1.noarch
...

Portanto, a transação não foi concluída e alguns pacotes estão listados em 2 versões.

Neste estado os yum updaterelatórios:

# yum update
Loaded plugins: product-id, search-disabled-repos
Resolving Dependencies
There are unfinished transactions remaining. You might consider running yum-complete-transaction, or "yum-complete-transaction --cleanup-only" and "yum history redo last", first to finish them. If those don't work you'll have to try removing/installing packages by hand (maybe package-cleanup can help).

E a transação falha.

Veja a solução como foi possível corrigir esse problema.

rhel centos