Capítulo 5. Problemas a serem considerados para o jessie

Índice

5.1. Limitações no suporte de segurança
5.1.1. Situação da segurança dos navegadores web
5.1.2. Falta de suporte de segurança para o ecossistema em torno da libv8 e Node.js
5.1.3. Término antecipado do suporte de segurança do MediaWiki
5.2. O servidor OpenSSH predefine "PermitRootLogin without-password"
5.3. Compatibilidade puppet 2.7 / 3.7
5.4. A atualização para PHP 5.6 tem mudanças de comportamento
5.5. Mudanças incompatíveis no Apache HTTPD 2.4
5.6. A atualização instala o novo sistema init padrão para Jessie
5.6.1. Tratamento mais rigoroso de falhas de montagem durante o boot sob systemd
5.6.2. Scripts init obsoletos devem ser expurgados
5.6.3. Scripts init modificados localmente podem precisar ser portados para o systemd
5.6.4. Necessidade do plymouth para o prompt de inicialização sob inicializações com systemd
5.6.5. Interação entre logind e acpid
5.6.6. Recursos do crypttab não suportados pelo systemd (por exemplo "keyscript=...")
5.6.7. systemd: envia SIGKILL muito cedo [corrigido em 8.1]
5.6.8. systemd: comportamento do comando halt
5.7. Required kernel config options for Jessie
5.8. Upgrade considerations for LXC hosts and containers
5.8.1. Upgrading LXC guests running on Wheezy hosts
5.8.2. Upgrading LXC guests running on Jessie hosts
5.8.3. Further information
5.9. Manual migration of disks encrypted with LUKS whirlpool (non-standard setups)
5.10. The GNOME desktop requires basic 3D graphics
5.11. The GNOME desktop does not work with the AMD proprietary FGLRX driver
5.12. Changes in the GNOME default keyboard shortcuts
5.13. Changes to default shell of system users provided by base-passwd
5.14. Migration to new KDE E-mail, Calendar, and Contacts (Kontact)
5.15. Missing virtual consoles ("getty"s) with multiple desktop environments
5.16. "VGA signal out of range" / blank screen during boot with grub-pc
5.17. Stricter validation of cron files in crontab
5.18. Change in handling of unreadable module paths by perl
5.19. Upgrade considerations for Ganeti clusters
5.19.1. Problem upgrading Ganeti clusters with DRBD-backed instances [fixed in 8.1]
5.19.2. General notes on upgrading Ganeti clusters
5.20. New requirements for file execution in Samba4
5.21. Cryptsetup can break boot with BUSYBOX=n

Algumas vezes, mudanças introduzidas em uma nova versão têm efeitos colaterais que não podem ser evitados ou que acabam expondo bugs em outros locais. Esta seção documenta problemas conhecidos. Por favor, também leia a errata, a documentação dos pacotes relevantes, relatórios de bugs e outras informações mencionadas na Seção 6.1, “Leitura complementar”.

5.1. Limitações no suporte de segurança

Existem alguns pacotes onde o Debian não pode prometer fornecer portes retroativos mínimos para problemas de segurança. Esses são abordados nas subseções a seguir.

Note que o pacote debian-security-support, introduzido no Jessie, ajuda a acompanhar a situação do suporte de segurança dos pacotes instalados.

5.1.1. Situação da segurança dos navegadores web

O Debian 8 inclui diversos motores de navegadores que são afetados por um fluxo constante de vulnerabilidades de segurança. A alta taxa de vulnerabilidades e a ausência parcial de suporte do upstream na forma de ramos de longo prazo tornam muito difícil o suporte a esses navegadores com correções de segurança portadas retroativamente. Além disso, as interdependências das bibliotecas tornam impossível atualizar para uma versão upstream mais nova. Por isso, navegadores feitos sobre os motores webkit, qtwebkit e khtml foram incluídos no Jessie, mas não estão cobertos pelo suporte de segurança. Esses navegadores não devem ser usados em sites web não confiáveis.

Para uso geral de navegador web recomendamos Iceweasel ou Chromium.

Chromium - enquanto construído sobre a base de código Webkit - é um pacote sem dependência, que será mantido atualizado através da reconstrução das versões atuais do Chromium para a estável. O Iceweasel e o Icedove também serão mantidos atualizados através da reconstrução das versões ESR atuais para a estável.

5.1.2. Falta de suporte de segurança para o ecossistema em torno da libv8 e Node.js

A plataforma Node.js é construída em cima da libv8-3.14, que vivencia um alto volume de problemas de segurança, mas atualmente não há voluntários no projeto ou na equipe de segurança suficientemente interessados e dispostos a gastar a grande quantidade de tempo necessária para conter esses problemas encontrados.

Infelizmente, isso significa que a libv8-3.14, o nodejs e o ecossistema de pacotes node-* associados não devem ser atualmente utilizados com conteúdo não confiável, tais como dados não avaliados oriundos da Internet.

Além disso, esses pacotes não receberão quaisquer atualizações de segurança durante o tempo de vida da versão Jessie.

5.1.3. Término antecipado do suporte de segurança do MediaWiki

O suporte do upstream para a série 1.19 do mediawiki termina durante o ciclo de vida esperado da Jessie. O pacote mediawiki está incluído na Jessie para satisfazer dependências em outros pacotes.

O suporte de segurança para o mediawiki terminará juntamente com o suporte para o Wheezy em abril de 2016.

5.2. O servidor OpenSSH predefine "PermitRootLogin without-password"

Em uma tentativa de fortalecer a configuração padrão, a configuração do openssh-server agora predefinirá "PermitRootLogin without-password". Caso você confie na autenticação por senha para o usuário root, você pode ser afetado por essa mudança.

O openssh-server tentará detectar esses casos e aumentar a prioridade dos seus avisos do debconf.

Caso você queira manter a autenticação por senha para o usuário root, você também pode predefinir esta pergunta usando:

$ echo 'openssh-server openssh-server/permit-root-login boolean true' | debconf-set-selections

5.3. Compatibilidade puppet 2.7 / 3.7

Caso você esteja usando Puppet, por favor, esteja ciente de que o Puppet 3.7 não é compatível com o anterior Puppet 2.7. Além de outras coisas, as regras de escopo mudaram e muitas estruturas de controle (constructs) obsoletas foram removidas. Veja as notas de lançamento do Puppet 3.x para algumas das mudanças, apesar de estar ciente de que há mudanças adicionais no 3.7.

Verificar os arquivos de log do seu puppetmaster em busca de advertências de depreciação e resolver todas essas advertências antes de proceder com a atualização fará com que seja mais fácil completar a atualização. Alternativamente, ou adicionalmente, testar os manifestos com uma ferramenta como o teste de catálogo Puppet também pode encontrar possíveis problemas antes da atualização.

Quando atualizar um sistema gerenciado pelo Puppet de Wheezy para Jessie, você deve garantir que o puppetmaster correspondente execute, pelo menos, a versão 3.7 do Puppet. Caso o mestre esteja executando o puppetmaster do Wheezy, o sistema Jessie gerenciado não será capaz de conectar ao mesmo.

Para mais informações sobre as alterações incompatíveis, por favor, dê uma olhada em problemas de atualização Telly e "The Angry Guide to Puppet 3".

5.4. A atualização para PHP 5.6 tem mudanças de comportamento

A atualização para Jessie inclui uma atualização do PHP de 5.4 para 5.6. Isso pode afetar quaisquer scripts PHP e você é aconselhado a verificar esses scripts antes de atualizar. Abaixo está um subconjunto selecionado desses problemas:

  • Para prevenir ataques do tipo man-in-the-middle contra transferências criptografadas, os streams de clientes agora verificam os certificados dos pares por padrão.

    Como resultado dessa mudança, um código existente usando wrappers de strem ssl:// ou tls:// (por exemplo, file_get_contents(), fsockopen(), stream_socket_client()) pode não conectar-se mais com sucesso sem desabilitar manualmente a verificação de pares através do ajuste "verify_peer" no contexto do stream.

    Para mais informações sobre esse problema particular, por favor, leia este documento.

  • PHP muda o tratamento de insensibilidade a maiúsculas e minúsculas em muitos casos:

    • Todo tratamento interno de insensibilidade a maiúsculas e minúsculas para nomes de classes, funções e constantes é feito de acordo com as regras ASCII. As regras do locale atual são ignoradas.

    • As chaves "self", "parent" e "static" agora são sempre insensíveis a maiúsculas e minúsculas.

    • A função json_decode() não aceita mais variantes não minúsculas dos valores "boolean".

  • As funções de GUID logo (por exemplo, php_logo_guid()) foram removidas.

  • Não é mais possível sobrescrever chaves em matrizes escalares estáticas. Por favor, veja o bug 66015 do PHP para um exemplo e mais informações sobre esse problema particular.

  • As funções mcrypt_encrypt(), mcrypt_decrypt() e mcrypt_{MODE}() não aceitam mais VIs com tamanhos incorretos. Além disso, um VI agora é necessário caso o modo de codificação de bloco utilizado o requeira.

  • Por razões legais, a implementação do JSON distribuída com o PHP foi substituída pela versão fornecida pelo módulo PECL "jsonc". O código que faz suposições sobre os detalhes de implementação mais finos do parser JSON PHP pode precisar de ser revisado.

  • O ajuste "short_open_tag" agora está desabilitado por padrão. As tags curtas ("<?" and "?>") estão planejadas para remoção no PHP7.

Para mais informações ou a lista completa de possíveis problemas, por favor, dê uma olhada na lista do upstream de mudanças incompatíveis com versões anteriores para ao PHP 5.5 e 5.6.

5.5. Mudanças incompatíveis no Apache HTTPD 2.4

[Nota]Nota

Esta seção se aplica apenas a sistemas que tenham um servidor Apache HTTPD instalado e configurado manualmente.

Houve uma série de mudanças na configuração do servidor HTTPD Apache na versão 2.4. No lado do upstream, a sintaxe mudou. Notavelmente, as diretivas de controle de acesso mudaram consideravelmente e precisarão de configuração manual para as novas diretivas.

O módulo mod_access_compat é mencionado no guia de atualização do upstream como uma alternativa possível para migração imediata. Porém, os relatos sugerem que ele pode nem sempre funcionar.

O gerenciamento dos arquivos de configuração também mudou no empacotamento do Debian. Em particular, todos os arquivos de configuração e sites agora devem terminar com ".conf" para serem analisados por padrão. Essa mudança também substitui o uso já existente do /etc/apache2/conf.d/.

[Nota]Nota

Durante a atualização, você também pode ver avisos sobre arquivos de configuração colocados em /etc/apache2/conf.d/, que são fornecidos por pacotes do Debian. Este aviso é inevitável, mas inofensivo, pois os pacotes afetados moverão suas configurações uma vez que suas atualizações sejam concluídas (o que geralmente acontecerá depois que o HTTPD Apache emitir o seu alerta).

Para mais informações e a lista completa das mudanças, por favor, consulte:

5.6. A atualização instala o novo sistema init padrão para Jessie

A Jessie vem com o systemd-sysv como sistema init padrão. Esse pacote é instalado automaticamente nas atualizações.

Caso você tenha uma preferência por outro init, tal como sysvinit-core ou upstart, é recomendado configurar o pinning do APT antes da atualização. Isso também pode ser necessário se você estiver atualizando contêineres do LXC antes do host. Nesse caso, por favor, consulte Seção 5.8.1, “Upgrading LXC guests running on Wheezy hosts”.

Como um exemplo, para evitar que o systemd-sysv seja instalado durante a atualização, você pode criar um arquivo chamado /etc/apt/preferences.d/local-pin-init com os seguintes conteúdos:

Package: systemd-sysv
Pin: release o=Debian
Pin-Priority: -1
[Cuidado]Cuidado

Esteja ciente de que alguns pacotes podem ter um comportamento degradado ou podem faltar recursos sob um sistema init não padrão.

Por favor, note que a atualização pode instalar pacotes contendo "systemd" em seu nome, mesmo com o pinning do APT. Esses sozinhos não alteram o seu sistema init. Para usar o systemd como o seu sistema init, o pacote systemd-sysv deve ser instalado primeiro.

Caso o APT ou aptitude tenham problemas para calcular um caminho de atualização com o pinning no local, é possível que você seja capaz de ajudá-lo instalando manualmente tanto o sysvinit-core quanto o systemd-shim.

5.6.1. Tratamento mais rigoroso de falhas de montagem durante o boot sob systemd

O novo sistema init padrão, systemd-sysv, tem um tratamento mais rigoroso das falhas de montagem do tipo "auto" durante a inicialização, comparado ao sysvinit. Caso ele falhe ao montar uma montagem do tipo "auto" (sem a opção "nofail"), o systemd cairá em um shell de emergência ao invés de continuar inicialização.

Recomendamos que todos os pontos de montagem removíveis ou "óticos" (por exemplo, unidades de rede não críticas) listados em /etc/fstab tenham tanto a opção "noauto" quanto a "nofail".

5.6.2. Scripts init obsoletos devem ser expurgados

Caso você esteja atualizando a partir de uma versão anterior, o seu sistema pode conter scripts init obsoletos fornecidos por pacotes (agora) removidos. Esses scripts podem ter metadados imprecisos ou sem dependência, que podem levar a ciclos de dependência na sua configuração de init.

Para evitar isso, recomendamos que você reveja a lista de pacotes que estão em estado "rc" ("Removed, but Config-files remain"), e expurgue pelo menos todos aqueles que contenham scripts init.

Por favor, veja Seção 4.8.1, “Expurgando pacotes removidos” para detalhes sobre como encontrar em expurgar pacotes removidos.

5.6.3. Scripts init modificados localmente podem precisar ser portados para o systemd

[Nota]Nota

Esta seção se aplica apenas aos sistemas onde os scripts init fornecidos no Debian foram modificados localmente.

Caso você tenha modificado alguns dos scripts init fornecidos pelo Debian, por favor, esteja ciente que esses podem agora ter sido substituídos por um arquivo de unidade systemd ou pelo próprio systemd. Caso você tenha o debsums instalado, você pode verificar scripts init modificados localmente usando o seguinte comando shell.

debsums -c -e | grep ^/etc/init.d

Alternativamente, pode ser usado o seguinte na ausência do debsums.

dpkg-query --show -f'${Conffiles}' | sed 's, /,\n/,g' | \
  grep /etc/init.d | awk 'NF,OFS="  " {print $2, $1}' | \
  md5sum --quiet -c

Caso um dos comandos sinalize quaisquer arquivos e seus pacotes correspondentes ou o systemd agora forneça um arquivo de unidade systemd para esse serviço, o arquivo de unidade systemd prevalecerá sobre o seu script init modificado localmente. Dependendo da natureza da mudança, há formas diferentes de realizar a migração.

Caso necessário, é possível substituir o arquivo de unidade systemd para que inicie o script sysvinit. Para mais informações sobre arquivos de unidade systemd, por favor, dê uma olhada nos seguintes recursos.

5.6.4. Necessidade do plymouth para o prompt de inicialização sob inicializações com systemd

If your boot is interactive (e.g. needs a password for an encrypted disk), please ensure that you have plymouth installed and configured. Please refer to /usr/share/doc/plymouth/README.Debian for information on how to configure plymouth.

Sem o plymouth, você pode achar que o prompt de inicialização desaparece. Relatos sugerem que o prompt do cryptsetup ainda aceita entrada apesar de não estar visível. Se você enfrentar esse problema, digitando a senha correta pode ainda funcionar.

5.6.5. Interação entre logind e acpid

Eventos ACPI podem ser tratados pelo logind ou acpid. No caso de ambos os serviços estarem configurados para tratarem os eventos de maneiras diferentes, isso pode levar a resultados indesejáveis.

Recomendamos migrar todas as configurações não padrão para logind e desinstalar o acpid. Alternativamente, também é possível configurar o logind para ignorar eventos ACPI adicionando:

HandlePowerKey=ignore
HandleSuspendKey=ignore
HandleHibernateKey=ignore
HandleLidSwitch=ignore

ao /etc/systemd/logind.conf. Note que isso pode mudar o comportamento dos ambientes de área de trabalho que dependem do logind.

5.6.6. Recursos do crypttab não suportados pelo systemd (por exemplo "keyscript=...")

Há alguns recursos do cryptsetup que infelizmente não são suportados quando se está usando o systemd como sistema init. Esse são:

  • precheck

  • check

  • checkargs

  • noearly

  • loud

  • keyscript

Caso o seu sistema dependa de qualquer um desses para inicializar com sucesso, você terá que usar o sysvinit (sysvinit-core) como sistema init. Por favor, consulte Seção 5.6, “A atualização instala o novo sistema init padrão para Jessie” para saber como evitar um sistema init em particular.

Você pode verificar se alguma dessas opções está em uso em seu sistema, executando o seguinte comando:

grep -e precheck -e check -e checkargs -e noearly -e loud -e keyscript /etc/crypttab

Se não houver saída no comando acima, o seu sistema não utiliza nenhuma das opções afetadas.

5.6.7. systemd: envia SIGKILL muito cedo [corrigido em 8.1]

[Nota]Nota

Esse problema foi corrigido no lançamento pontual Jessie 8.1.

Uma regressão foi relatada no systemd após o lançamento da Jessie. A falha ocorre durante o desligamento ou reinicialização, onde o systemd não dá nenhum atraso razoável antes de enviar SIGKILL aos processos.

Esse problema é monitorado no bug #784720 do Debian

5.6.8. systemd: comportamento do comando halt

The sysvinit implementation of the halt command powered off the machine as well. The systemd-sysv implementation halts the system, but does not power off the machine. To halt the machine and turn it off, use the poweroff command.

See also Debian bug #760923

5.7. Required kernel config options for Jessie

[Nota]Nota

This section is only for people who compile their own kernel. If you use the kernels compiled by Debian, you can disregard this section.

The following kernel configuration options are now either required or recommended for Jessie (in addition to existing ones from previous releases):

# Required for udev
CONFIG_DEVTMPFS=y
# Required for *some* systemd services
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
# Required by "bluez" (GNOME)
CONFIG_BT=y
# Required for cups + systemd.
CONFIG_PPDEV=y

The systemd services which require CONFIG_DEVPTS_MULTIPLE_INSTANCES=y will typically contain at least one of the following directives:

PrivateTmp=yes
PrivateDevices=yes
PrivateNetwork=yes
ProtectSystem=yes

If you do not use systemd, or can assert that none of the systemd services will use the above directives, the config option might not be required for your particular system.

For more information about the requirements, please refer to the section called "REQUIREMENTS" in the README file for the package systemd.

5.8. Upgrade considerations for LXC hosts and containers

[Nota]Nota

This section only applies to systems that have LXC containers and hosts. Normal end user systems usually do not have these.

The upgrade from Wheezy to Jessie will migrate your system to the systemd init system by default (see Seção 5.6, “A atualização instala o novo sistema init padrão para Jessie”).

When upgrading an LXC container or an LXC virtual machine, this will have different consequences depending on whether the host system has already been upgraded to Jessie or not.

5.8.1. Upgrading LXC guests running on Wheezy hosts

If you are upgrading an LXC guest container that is running on a Wheezy host system, then you will need to prevent the guest from being automatically migrated to systemd. You prevent the migration via pinning, as described in Seção 5.6, “A atualização instala o novo sistema init padrão para Jessie”.

This is required as the Wheezy host lacks functionality to boot a system running systemd.

You should be able to switch over to systemd inside the LXC guest once you have upgraded the host system to Jessie. See the next paragraph for things that need to be adapted on Jessie hosts.

5.8.2. Upgrading LXC guests running on Jessie hosts

In order to be able to boot LXC guests with systemd, you need to adapt your LXC container configuration. The container configuration can usually be found in /var/lib/lxc/CONTAINER_NAME/config You need to add the following two settings to the configuration:

lxc.autodev = 1
lxc.kmsg = 0

5.8.3. Further information

You can find further information on LXC in Debian in the Debian wiki.

5.9. Manual migration of disks encrypted with LUKS whirlpool (non-standard setups)

[Nota]Nota

This section is only for people who have set up LUKS encrypted disks themselves using the whirlpool hash. The debian-installer has never supported creating such disks.

If you have manually set up an encrypted disk with LUKS whirlpool, you will need to migrate it manually to a stronger hash. You can check if your disk is using whirlpool by using the following command:

# /sbin/cryptsetup luksDump <disk-device> | grep -i whirlpool

For more information on migrating, please see item "8.3 Gcrypt 1.6.x and later break Whirlpool" of the cryptsetup FAQ.

[Cuidado]Cuidado

If you have such a disk, cryptsetup will refuse to decrypt it by default. If your rootdisk or other system disks (e.g. /usr) are encrypted with whirlpool, you should migrate them prior to the first reboot after upgrading cryptsetup.

5.10. The GNOME desktop requires basic 3D graphics

The GNOME 3.14 desktop in Jessie no longer has fallback support for machines without basic 3D graphics. To run properly, it needs either a recent enough PC (any PC built in the last 10 years should have the required SSE2 support) or, for architectures other than i386 and amd64, a 3D-accelerated graphics adapter with EGL drivers.

5.11. The GNOME desktop does not work with the AMD proprietary FGLRX driver

Unlike other OpenGL drivers, the AMD FGLRX driver for Radeon adapters does not support the EGL interface. As such, several GNOME applications, including the core of the GNOME desktop, will not start at all when this driver is in use.

It is recommended to use the free radeon driver, which is the default in jessie, instead.

5.12. Changes in the GNOME default keyboard shortcuts

The default keyboard shortcuts in the GNOME desktop have changed in order to match more closely those of some other operating systems.

Shortcut settings previously modified by the user will be preserved upon upgrade. These settings can still be configured from the GNOME control center, accessible from the top right menu by clicking on the "settings" icon.

5.13. Changes to default shell of system users provided by base-passwd

The upgrade of the base-passwd package will reset the shell of some system users to the "nologin" shell. This includes the following users:

  • daemon

  • bin

  • sys

  • sync

  • games

  • man

  • lp

  • mail

  • news

  • uucp

  • proxy

  • www-data

  • backup

  • list

  • irc

  • gnats

  • nobody

If your local setup requires that any of these users have a shell, you should say no to migrating, or migrate and then change the shell of the corresponding users. Notable examples include local backups done via the "backup" user with "ssh-key" authentication.

[Cuidado]Cuidado

The migration will happen automatically if your debconf question priority is "high" or above.

If you know you want to keep the current shell of a given user, you can preseed the questions by using the following:

echo 'base-passwd base-passwd/system/username/shell/current-shell-mangled/_usr_sbin_nologin boolean false' | debconf-set-selections

Where username is the name of the user in question and current-shell-mangled is the mangled name of the shell. The mangling is done by replacing all characters other than alphanumerics, dashes, and underscores with underscores. E.g. /bin/bash becomes _bin_bash.

5.14. Migration to new KDE E-mail, Calendar, and Contacts (Kontact)

The Kontact Personal Information Management system has received a major upgrade. The new version makes much greater use of metadata indexing and each user's data must be migrated into these new indices.

E-mail, calendar events, and addressbook contacts are automatically migrated when the user logs in and the relevant component is started. Some advanced settings such as e-mail filters and custom templates require manual intervention. Further details and troubleshooting suggestions are collected on the Debian Wiki.

5.15. Missing virtual consoles ("getty"s) with multiple desktop environments

[Nota]Nota

This issue is currently reported as fixed in Jessie. Should you still be able to reproduce it, then please follow up to Debian Bug#766462. Note that you may have to unarchive the issue first (please refer to the Debian BTS control server documentation on how to unarchive bugs).

If you have multiple desktop environments installed, you may experience that none of the "virtual consoles" show a login prompt.

This issue seems to occur when plymouth, systemd, and GNOME are all installed. This issue is reported as Debian Bug#766462.

It has been reported that removing the "splash" argument from the kernel command-line may work around the issue. Please see /etc/default/grub and remember to run update-grub after updating the file.

5.16. "VGA signal out of range" / blank screen during boot with grub-pc

There is a compatibility issue in grub-pc with older graphics cards (e.g. the "ATI Rage 128 Pro Ultra TR") that can cause it to show a blank screen during boot. The display may issue a "VGA signal out of range" message (or something similar).

A simple work around is to set GRUB_TERMINAL=console in /etc/default/grub.

5.17. Stricter validation of cron files in crontab

The crontab program is now more strict and may refuse to save a changed cron file if it is invalid. If you experience issues with crontab -e, please review your crontab for existing mistakes.

5.18. Change in handling of unreadable module paths by perl

From version 5.18 (and 5.20, which is included in Jessie), Perl will exit with a fatal error if it encounters unreadable module paths in @INC. The previous behavior was to skip such entries. It is recommended to check the contents of @INC in your environment for directories which are not world-readable, and take appropriate action.

You can see the default @INC for Perl by running perl -V.

5.19. Upgrade considerations for Ganeti clusters

5.19.1. Problem upgrading Ganeti clusters with DRBD-backed instances [fixed in 8.1]

[Nota]Nota

Esse problema foi corrigido no lançamento pontual Jessie 8.1.

The version of ganeti (2.12.0-3) released with Jessie does not support migrations from installations running 2.5 or earlier (including Wheezy) in cases where there are instances with DRBD disks. It is hoped that this issue will be fixed in a point release, and recommended that you do not upgrade affected Ganeti clusters in the meantime. You can find more information about this issue at Debian Bug#783186.

5.19.2. General notes on upgrading Ganeti clusters

The recommended procedure to upgrade a Ganeti cluster from Wheezy's ganeti version (2.5.2-1) to Jessie's (2.12.0-3) is to stop all instances and then upgrade and reboot all nodes at once. This will ensure that all instances run with Jessie's hypervisor version and that all nodes run the same versions of Ganeti and DRBD.

Note that running a cluster with mixed 2.5 and 2.12 nodes is not supported. Also note that, depending on the hypervisor, instance live migrations may not work between Wheezy and Jessie hypervisor versions.

5.20. New requirements for file execution in Samba4

If a client requests that a file should be "opened for execution", Samba4 will require the executable bit to be set on the file in addition to the regular read permissions. This also causes "netlogon" scripts to be silently ignored if they lack this executable bit.

5.21. Cryptsetup can break boot with BUSYBOX=n

[Nota]Nota

This section only applies to people that have manually changed their /etc/initramfs-tools/initramfs.conf to not use busybox.

If you have both busybox and cryptsetup installed plus configured initramfs to not use busybox, then it may render your system unbootable.

Please check the value of your BUSYBOX setting in /etc/initramfs-tools/initramfs.conf if you have both of these packages installed. At this time, known work arounds are uninstalling busybox or setting BUSYBOX=y in /etc/initramfs-tools/initramfs.conf.

[Atenção]Atenção

If you had to make any changes, please remember to run update-initramfs -u to update your initramfs. Otherwise, you may still end up with a broken boot.

Please see Debian Bug#783297 for more information.