Caixa Seca

O Hyper-V tem um recurso interessante no comutador "Default Switch" que automaticamente adiciona um registro DNS no hospedeiro com o nome de máquina do convidado quando este obtém IPv4 via DHCP. É salvo em %SystemRoot%\System32\drivers\etc\hosts.ics e usa o domínio mshome.net . Meu convidado Fedora 40 não estava aparecendo lá. NetworkManager envia o nome de máquina na requisição DHCP: $ nmcli connection show eth0 | grep hostname ipv4.dhcp-send-hostname: sim [...] Descrição da propriedade no manual nm-settings : If TRUE, a hostname is sent to the DHCP server when acquiring a lease. Some DHCP servers use this hostname to update DNS databases, essentially providing a static hostname for the computer. If the "dhcp-hostname" property is NULL and this property is TRUE, the current persistent hostname of the computer is sent. Depois de quebrar um pouco a cabeça, lembrei que a instalação do Fedora por padrão não configura um nome ...

Desde o kernel 5.14, lançado em 29 de agosto de 2021, existe o driver Direct Rendering Manager (DRM) genérico simpledrm , que usa o framebuffer fornecido pelo VBIOS/UEFI. Em distribuições que ativem-no ( CONFIG_DRM_SIMPLEDRM=y e CONFIG_SYSFB_SIMPLEFB=y ), adicionar nomodeset nas opções de inicialização passa a ser verdadeiramente um modo de segurança gráfico, que funciona com o Wayland: driver DRM nativo da GPU — como i915 , amdgpu , etc. — não é carregado e o simpledrm fornece um dispositivo DRM funcional [1] . LLVMpipe (Mesa) completa o time fornecendo OpenGL via software. Acaba beneficiando também o Xorg, pois seus drivers do espaço de usuário vesa e fbdev (há muito tempo com manutenção precária) não são mais requeridos. [ 0.599209] [drm] Initialized simpledrm 1.0.0 20200625 for simple-framebuffer.0 on minor 0 [ 0.600186] simple-framebuffer simple-framebuffer.0: [drm] fb0: simpledrmdrmfb frame buffer device https://fedorapro...

Este MacBookPro7,1 (MC374BZ/A, ~2010) estava com o macOS 10.10 imprestável de tão lento. Consegui carregar o ZeroNG simplesmente pressionando option logo que inicia. Apple adotou UEFI por volta de 2006. Que vergonha para o ecossistema dos PCs. Disco zerado e variáveis do firmware apagadas; estranho quando funciona de primeira assim. Pesquisando sobre criação da mídia de instalação do macOS 10.13 — último suportado neste hardware —, achei a coisa confusa. Resumo para os preguiçosos como eu: melhor ter um Mac funcionando à mão para a tarefa . Como não tenho e o 10.13 já foi descontinuado, desisti (ver Mídia de instalação USB do macOS High Sierra (10.13.6) pelo Linux ). Windows 10 21H2 (x64) instala, porém não fica bom. Lá no fundo, o hardware desta máquina tem carinho por Unix-likes, né? Fedora Workstation 36 instalou, não sem tropeçar no particionamento "Personalizado Avançado". Bug menor , que, para quem não gosta do esquema ...

No Fedora 21, Debian 8, o desligamento é extremamente rápido. Poderia parecer um recurso, mas na verdade é um bug introduzido na versão 209 do systemd: https://bugzilla.redhat.com/show_bug.cgi?id=1141137 https://bugzilla.redhat.com/show_bug.cgi?id=1170765 https://bugs.launchpad.net/bugs/1446982 https://bugs.launchpad.net/bugs/1448259 Nenhum sistema de arquivos corre risco. São todos desmontados corretamente. O bug consiste na sessão do usuário receber SIGKILL imediatamente após SIGTERM. Como o primeiro sinal vem praticamente ao mesmo tempo, os aplicativos não têm tempo de fazerem suas rotinas de desligamento. É por isso que, se você deixar o Firefox aberto e desligar ou reiniciar o sistema, na próxima inicialização, existe uma boa chance do navegador exibir aquela mensagem dizendo "isto é constrangedor" ou então restaurar automaticamente as abas anteriormente abertas: não teve tempo de processar SIGTERM. Enquanto escrevia o post sobre o Squid , achei estranho, mesmo...

Foi aprovado para o Fedora 22 isto: FESCO Decision on COPR/Playground in GNOME Software Cuja implementação está em: Disabled Repositories Support Finding hidden applications with GNOME Software É a infraestrutura que permite repositórios desabilitados terem seu conteúdo indexado pelas ferramentas de instalação de pacotes baseadas no PackageKit (GNOME Software é o foco) e, ao mesmo tempo, com o consentimento do usuário, provê meio de habilitá-los automaticamente. É possível fazê-lo pela linha de comando (especialmente com o dnf , o sucessor do yum ). A diferença é que tudo é gráfico e bonitinho. Por enquanto, pacotes oficiais poderão apenas referenciarem repositórios Copr (equivalentes aos PPAs). Software não livre (como o repositório do Google Chrome ou RPM Fusion ), pela rígida política da distribuição, não. No ciclo do F22, nenhum virá instalado. Entretanto, já é um bom passo com futuro impacto positivo: facilitar a busca de programas! (Copr do Chromium seria um forte can...

Acostumando com o Fedora/CentOS onde o processo de remoção de símbolos de depuração é realizado pelo script /usr/lib/rpm/brp-strip , pertencente ao pacote rpm-build , nem notei que no openSUSE existe um SUSEismo que separa essa tarefa em outro pacote: brp-check-suse . Depois de instalado, vejo, como deve ser, o tamanho dos binários e bibliotecas dinâmicas dos pacotes construídos com o rpmbuild despencar.

O UPower pode ser útil em servidores que tenham UPS com comunicação USB (e serial talvez). Os modelos da APC costumam funcionar sem briga. Assim, você consegue desligar a máquina antes das baterias esgotarem-se. No Fedora 21, instale o pacote upower . O serviço é ativado por D-Bus e é iniciado sempre que algum outro programa requisitar suas interfaces . O pacote do Fedora não espera, contudo, e inicia-o incondicionalmente via graphical.target . Isso funciona quando existe a pilha gráfica. Não quando você está numa instalação mínima em modo texto, cujo target padrão é multi-user.target . Podemos adotar três caminhos: - Executar durante o boot algum programa que ative o daemon ( upowerd ), como uma invocação do binário upower . Gambiarra que descarto. - Alterar o target com systemctl set-default graphical.target . Essa é uma solução decente, mas não me agrada muito pois, se formos analisar minuciosamente, o único serviço pertencente ao graphical.target será upower.service . - Al...

Se os comandos a serem executados pelos scripts estiverem nos locais convencionais, os caminhos absolutos são desnecessários. O RPM configura o seguinte como $PATH antes de executá-los. PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin ( versão 4.12.x ) Referências: Fedora , openSUSE .

[Atualização - 30/01/2017] Nada mais disso é necessário hoje em dia. A partir do Fedora 19, existe um lugar unificado para instalar certificados adicionais. https://fedoraproject.org/wiki/Features/SharedSystemCertificates (tudo como root) wget http://certificadodigital.caixa.gov.br/cer/ICP-Brasil%20v2.cer -O /etc/pki/ca-trust/source/anchors/ICP-Brasil\ v2.cer wget http://certificadodigital.caixa.gov.br/cer/AC%20CAIXA%20v2.cer -O /etc/pki/ca-trust/source/anchors/AC\ CAIXA\ v2.cer wget http://certificadodigital.caixa.gov.br/cer/AC%20CAIXA%20PF%20v2.cer -O /etc/pki/ca-trust/source/anchors/AC\ CAIXA\ PF\ v2.cer wget http://certificadodigital.caixa.gov.br/cer/AC%20CAIXA%20PJ%20v2.cer -O /etc/pki/ca-trust/source/anchors/AC\ CAIXA\ PJ\ v2.cer wget http://certificadodigital.caixa.gov.br/cer/AC%20CAIXA-JUS%20v2.cer -O /etc/pki/ca-trust/source/anchors/AC\ CAIXA-JUS\ v2.cer update-ca-trust extract O Firefox, bem como o OpenJDK, usa a loja de certificados do sistema. Infelizmente, os s...

https://bugzilla.redhat.com/show_bug.cgi?id=1043212 O Phoronix deu destaque ao bug 1043212 do Fedora. Sem investigar nada para variar. Vamos entender o que houve. Para tentar consertar o bug RHBZ#1026860 , Zbigniew, um dos principais desenvolvedores do systemd, criou e775289d , que se mostrou errado e revertido posteriormente por ecad10fe . A solução para o bug do LVM2 estava nas suas próprias regras do udev ( 4c267c72 ). Infelizmente, o commit quebrado acabou sendo backportado para o pacote systemd-208-9 do Fedora 20, a versão presente nas mídias de instalação. No pacote 208-11, foi revertido, porém a atualização foi em seguida retirada de circulação por outros bugs sem relação com este — RHBZ#1023820 e RHBZ#1053315 . (veja o histórico postado por Adam Williamson) Incluídos no pacote 208-11, os seguintes commits devem consertar o problema em definitivo e são backports recomendados pelo upstream até a versão 209 ser lançada: c4708f13 e 81815651 . Colin Guthrie (Mageia)...

Idem ao openSUSE . Só que no Fedora é necessário instalar o pacote libva-intel-driver do repositório RPM Fusion. O resto é igual. Ainda sobre vídeo, estava tendo tearing miserável aqui no F19 + GNOME. A opção " TearFree " do driver intel resolveu. /etc/X11/xorg.conf.d/10-tearfree.conf Section "Device" Identifier "Intel Graphics" Driver "intel" Option "AccelMethod" "sna" Option "TearFree" "true" EndSection

Em volumes criptografados com LUKS, você precisa dizer para o subsistema dm-crypt do kernel (a partir do 3.1 ) para deixar passar os comandos TRIM para o dispositivo. Senão, terá: # fstrim / fstrim: /: FITRIM ioctl failed: Operação não suportada Adicione a opção allow-discards (na quarta coluna) na linha referente ao volume em /etc/crypttab ( man crypttab ) . luks-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX none allow-discards (a partir do systemd 207, a opção discard passou a ser suportada como sinônimo de allow-discards ) Depois, é necessário reconstruir o initramfs. No Fedora, rode: # dracut -f Quem usa LVM/RAID, não precisa fazer nada. Os dispositivos virtuais /dev/mapper/<nome> e /dev/md/<nome> , desde os kernels 2.6.36 e 3.7 , respectivamente, repassam o comando TRIM para o disco. Com LVM, existe a opção issue_discards=0/1 em /etc/lvm/lvm.conf (padrão é 0 ) que habilita ou não se as ferramentas lvremove , lvresiz...

Em /etc/NetworkManager/NetworkManager.conf , seção [main] , a opção plugins define onde o NM armazenará as configurações das interfaces de rede. Podem ser listados múltiplos plugin separados por vírgulas (dentre os habilitados durante a compilação): ele escreverá a configuração no local do primeiro plugin e interpretará a configuração dos demais, caso exista alguma. O Fedora, desde a versão 17 , usa o NM por padrão em todas as instalações, inclusive em modo texto. O único plugin configurado é o ifcfg-rh , que entende os velhos arquivos /etc/sysconfig/network-scripts/ifcfg-* . A configuração é por interface, sendo que cada arquivo é amarrado a um endereço MAC. Você pode sem problema remover todos os arquivos ifcfg se quiser. A interface loopback é configurada pelo systemd e o arquivo ifcfg-lo é desnecessário . No próximo boot, se, em /etc/NetworkManager/NetworkManager.conf , não existir uma linha no-auto-default=<MAC> , o NM automaticamente criará uma nova configuração tem...

Desde a versão 2.6.38 o kernel suporta initramfs (bem como sua própria imagem) comprimido com XZ. Para configurar o Dracut (≥ 009) para comprimir com o formato: # echo 'compress="xz"' >/etc/dracut.conf.d/compressao.conf Nas próximas atualizações do kernel, as imagens dos initramfs estarão comprimidas com XZ. Para refazer todos os initramfs dos kernels instalados: # dracut -f --regenerate-all Relacionado: initramfs "HostOnly" no Fedora 19

O Fedora habilita por padrão uma penca de daemons inúteis, que servem apenas para atrasar pacas o boot. Desde muito tempo é assim. Uma pena, porque faz, em instalações sem ajuste manual posterior, a distribuição jogar fora uma das grandes virtudes do systemd. Para o Fedora 20, havia uma esperança que o pior de todos pudesse sair da instalação padrão, continuando obviamente no repositório: sendmail. Havia, pois, por um voto , a proposta foi rejeitada. Ainda pior: o voto derradeiro (ou melhor, a falta de) foi de um dos propositores da mudança , Matthew Miller, que roeu a corda no último minuto se abstendo de votar! Continue lutando Lennart, por favor! https://plus.google.com/115547683951727699051/posts/dToG1PGNc1Q

No Fedora 19, foi implementado o modo "HostOnly" no Dracut, o gerador de initramfs: http://fedoraproject.org/wiki/Features/DracutHostOnly Até o Fedora 18, os initramfs (arquivos *.img em /boot ) criados eram genéricos, contendo módulos para hardware variado. Com "HostOnly", passam a ser criados especificamente para o hardware em uso, tornado-se bem menores (ex. de 17 MiB para 7 MiB). Ao mesmo tempo, um initramfs genérico "Rescue" é criado uma vez durante a instalação, para casos de emergência, como troca de hardware. O novo recurso é problemático, contudo, para o cenário de aplicar uma mesma imagem em várias máquinas com hardware diferente. Para voltar para um initramfs genérico, fazemos o seguinte antes da criação da imagem: # yum -y install dracut-nohostonly dracut-norescue # rm -f /boot/*rescue* # dracut -f --regenerate-all # grub2-mkconfig -o /boot/grub2/grub.cfg A partir do Fedora 20, os pacotes mudaram: # yum -y remove dracut-config-re...

Em Miúdos de clonagens manuais de partições (II) , sugeri, para regerar o machine-id, deletar /etc/machine-id e reiniciar. O systemd recriaria-o com o conteúdo de /var/lib/dbus/machine-id . Este método funciona no openSUSE 12.3, mas não no Fedora 18. Nele, existem alguns problemas. 1) /var/lib/dbus/machine-id não existe mais. D-Bus e demais códigos que dependem do machine-id foram atualizados para usarem o arquivo presente em /etc . 2) /etc é somente leitura quando o código que regera-o durante o boot é executado ( machine_id_setup() ), ou seja, a criação automática não funcionará. 3) Ao deletar /etc/machine-id e recriá-lo no ambiente do SystemRescueCd, o label do SELinux ficará errado e o arquivo ficará inacessível para os daemons quando o sistema for carregado. O sintoma de /etc/machine-id inacessível se manifestará (dentre outras formas) assim: # systemctl status systemd-journald.service systemd-journald.service - Journal Service Loaded: loaded (/usr/lib/systemd/sy...

Parece que notaram (com um considerável atraso) que algo não está certo: http://thread.gmane.org/gmane.linux.redhat.fedora.devel/179598 http://thread.gmane.org/gmane.linux.redhat.fedora.devel/179615 Entre isso e uma solução (faxinão!), entretanto, tem muito chão pela frente... :( [Atualização - 18/05/2013] Talvez não demore tanto: https://bugzilla.redhat.com/show_bug.cgi?id=963210

Sem LVM/RAID por software, um initramfs não tem muito propósito. Podemos pulá-lo e dizer para o kernel montar diretamente o sistema de arquivos de uma partição e executar /sbin/init . Daí para frente, o systemd assume o comando. Para isso, alguns requerimentos: - O kernel precisa ter o suporte ao controlador de disco e ao sistema de arquivos usado na partição compilados como bulit-in , ou seja, não podem ser módulos. - O sistema de arquivos raiz não pode ter o diretório /usr separado. - O bootloader não deve carregar o initramfs. Infelizmente o kernel do Arch não tem o primeiro item nem pretende ter. No Fedora, sim; contudo, apenas o driver ext4 (que serve para EXT2/3 também) e os drivers ahci e ata_piix são built-in . Para pular o initramfs, remova a linha "initrd" do bootloader e passe para o kernel as opções: root=/dev/sdxy rootfstype=xyz O sistema de arquivos precisa ser especificado (usar o mesmo nome do módulo), pois, lembre, o kernel está sozinho. Nã...

Bug 872826 - f18 beta tc7 anaconda - no option to install bootloader to a partition (considere GRUB = GRUB2) Instalar o GRUB na partição nunca foi um procedimento robusto. Se for chamado com --force, grub2-install usará lista de blocos para carregar o core.img do sistema de arquivos. O código no início da partição terá sua localização hardcoded . Se por acado o arquivo for movido, recriado, não será mais achado. Será preciso rodar novamente o grub2-install para a referência ao core.img ser refeita. Esse problema não acontece quando o GRUB é instalado no MBR, pois ali existe o intervalo não usado entre o setor 1 e 62 (particionamento antigo) ou setor 1 e 2047 (particionamento pós-Windows Vista), ou seja, 31KiB ou ~1MiB. Nesse espaço, o core.img pode linkar seus módulos que dão suporte ao sistema de arquivos em questão e não dependerá mais de listas de blocos hardcoded . Assim, ele passa a entender o sistema de arquivos e achará sem problemas seus arquivos dentro da partição mesm...