Como posso utilizar a porta RS485 do controlador de carga solar da série Epever XTRA (e possivelmente também Tracer)? Gostaria de usá-la para monitoramento e também para fácil modificação de parâmetros. O sistema instalado no meu notebook é o Fedora 39 no momento.
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.
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
Eu atualizei do Fedora 27 para 29. A atualização em si passou bem, logo após a reinicialização final, a tela gráfica de login (sddm) apenas piscou na tela padrão com os usuários e, em seguida, exibe o teclado virtual em fundo preto. Semelhante a esta imagem:
O que posso fazer para evitar esse comportamento?
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?
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.