*** Error in `/usr/sbin/smbios-sys-info-lite': free(): invalid pointer: 0x0000000000634460 *** (OMSA installation in XenServer 7.0)

Bom dia, gurizada.

Se você está com o seguinte erro ao instalar (e depois ao tentar iniciar) o OMSA em um XenServer 7.0, eis como resolvi.

A princípio ignorei o que diz em https://linux.dell.com/repo/hardware/dsu/ (alguma versão antiga, quem sabe) quanto ao comando para instalação do OMSA:

Em vez de:
# yum --enablerepo=base install srvadmin-all


Eu executei (conforme a nova recomendação):
# yum install srvadmin-all

Tudo porque se habilitar o repositório base, o XenServer (CentOS) vai instalar versões mais novas de smbios, libsmbios que parecem ser incompatíveis.

Notei que em vez de pouco mais de 60 pacotes, o segundo comando instala em torno de 40, mas parece ter funcionado.

Enjoy yourself.

Criando image de Debian Stretch com suporte a ZFS para live USB

Buenas,

Seguindo basicamente o que está em https://janvrany.github.io/2018/01/fun-with-zfs-part-2-creating-debian-zfs-rescue-usb-image.html e https://ubuntuforums.org/showthread.php?t=2267762 (configuração de proxy http):

sudo su

zfs create pool00/live_debian_with_zfs

cd /pool00/live_debian_with_zfs

apt install live-build

lb config --distribution=stretch --architecture=amd64 --binary-images=iso-hybrid --iso-volume="Debian Stretch ZFS Rescue Live" --archive-areas="main contrib" --linux-packages="linux-image linux-headers" --apt-http-proxy http://...:3128

echo "
> zfs-dkms
> less
> curl
> wget
> openssh-client
> openssh-server
> openssh-sftp-server
> " >> config/package-lists/my.list.chroot

lb bootstrap

lb chroot

lb binary

Pronto. Bora testar!!!

Upgrading proxmox from 5.1 to 5.2

Amigos, após futricar um pouco, consegui descobrir o mecanismo para fazer upgrade da versão 5.1 para versão 5.2 do proxmox.

Não é apenas "apt update && apt dis-upgrade" na CLI como diz em vários lugares, mesmo na documentação oficial.

Para poder fazer o upgrade, alterei o arquivo /etc/apt/sources.d/pve-enterprise.list:
#deb https://enterprise.proxmox.com/debian/pve stretch pve-enterprise
deb http://download.proxmox.com/debian stretch pve-no-subscription


Por fim, aí sim, "apt update && apt dis-upgrade".

CUIDADO: Este repositório não deve ser usado para servidores em produção.

Envoy yourself!

PS: Achei informações na documentação oficial (https://pve.proxmox.com/wiki/Package_Repositories)

OMSA: Firmware/Driver Information for Controller PERC 6/i Integrated

Minimum Required Driver Version2.24.00.32

Windows 2008 x86

http://www.dell.com/support/home/br/pt/brbsdt1/Drivers/DriversDetails?driverId=CW1N9

http://downloads.dell.com/FOLDER00353674M/1/SAS-RAID_Driver_CW1N9_WN32_2.24.0.32_A03.EXE

ZFS sobre volume iscsi (initiator com open-iscsi). ZVOL entregue sob iscsi (target com iscsitarget). Isto no novíssimo Debian Jessie.

Temos um storage que pensei em dar uma incrementada e prover uma solução de backup e preservação de dados utilizando ZFS. A ideia foi "por que não criar um pool ZFS em um volume do storage e entregar um ZVOL através de iscsi para uso, seja pelo servidor de arquivos ou XenServer?"

Como não posso atualizar o sistema operacional do storage, para isto precisaria de um host intermediário com duas interfaces de rede, uma ligada ao storage, outra para o initiator.

Neste host intermediário instalei o novíssimo Debian Jessie (https://www.debian.org/CD/http-ftp/#stable) e ZoL (http://zfsonlinux.org/debian.html).

Instalei os pacotes open-iscsi e iscsitarget. Depois disto foi só alterar alguns arquivos de configuração.

Logo depois de instalado o open-iscsi e antes dos comandos iscsiadm para descoberta de luns, alterei o arquivo /etc/iscsi/iscsid.conf, substituindo a linha "node.startup = manual" por "node.startup = automatic".

Com o advento do systemd, tive que fazer muita experimentação até conseguir fazer com que a ordem de execução dos daemons open-iscsi, zfs e iscsitarget ocorressem exatamente nesta ordem:

1º open-iscsi para conexão à lun do storage;
2º zfs para importação do pool criado e descrito em /etc/zfs/zpool.cache;
3º iscsitarget para disponibilizar volumes iscsi para outros initiators a partir de dispositivos ZFS, os ZVOLs.

Eis as alterações necessárias nos daemons para que se cumpra esta ordem:
1º open-scsi:
não exige alteração alguma;
2º zfs:
alteração do arquivo /lib/systemd/system/zfs-mount.service:
adicionar comentário na linha "#Before=local-fs.target";
adicionar a linha "After=open-iscsi.service"
3º iscsitarget:
adicionar "zfs-mount nas linhas
# Required-Start:    $remote_fs $syslog $network $time procps zfs-mount
# Required-Stop:     $remote_fs $syslog $network $time procps zfs-mount

Finalizando, já havia tido alguma experiência com falta de memória para o sistema operacional, devido ao cache do ZFS (provavelmente), que consegui contornar com a seguinte linha em /etc/sysctl.conf:
"vm.min_free_kbytes=1048576 "

Pronto! Reiniciando e tudo estando disponível automaticamente logo após o boot, basta fazer uso da lun pelos initiators. Depois basta criar snapshots e exportá-los, para preservação de dados e criação de backups.

Debian: xHCI xhci_drop_endpoint called with disabled ep

Passei a utilizar um computador Positivo com usb3.0 que estava me deixando maluco com as mensagem "xHCI xhci_drop_endpoint called with disabled ep" no log... muitas mensagens. Acredito até que eu estava tendo lentidão no acesso a dispositivos usb devido a isto.

Como atualmente não utilizo nenhum dispositivo usb3.0 acabei por tentar desabilitar o uso do módulo xhci com os seguintes arquivos em /etc/modprobe.d

Arquivo xhci com o conteúdo:
options xhci enable=0

e o arquivo xhci_hcd com o conteúdo:
options xhci_hcd enable=0

Provavelmente funcione com somente o segundo arquivo, mas como testei assim e já funcionou, fica a dica.

rsync "cannot delete non-empty directory"

Se a execução do rsync está lhe causando arrepios com a mensagem "cannot delete non-empty directory" quando se está utilizando --delete para que o que é excluído na origem seja refletido no destino, pode ser que esteja acontecendo o mesmo que mim.

Inicialmente meu rsync era assim:


rsync -avh --delete

E então alterei para isto:

rsync -avh --exclude=Thumbs.db --delete

Acabou acontecendo de muitos arquivos Thumbs.db continuarem no destino e o --delete não observa que eles foram excluídos na origem, porque eles continuam lá. Então o que temos a fazer é --delete-excluded, para que estes arquivos que estão na origem, mas foram filtrados, e não queremos que eles continuem no destino, porque ficaram lá por uma alteração de política de rsync:

rsync -avh --delete-excluded --exclude=Thumbs.db --delete