Para ver a diferença entre essas duas unidades (ou, melhor, modelos de unidade), basta olhar a diferença entre os arquivos getty @ .service e serial-getty @ .service , que você pode encontrar em /lib/systemd/system em seu sistema.
(Os arquivos apontados aqui apontam para os do systemd v239, versão mais recente até o momento desta publicação. Os arquivos têm macros m4 neles, então são processados antes da instalação, mas é uma pequena alteração introduzida pelo processamento m4, portanto eles estão perto o suficiente.)
Existem algumas diferenças, mas a principal é o comando ExecStart= chamado por cada unidade.
A unidade getty @ .service chama este comando:
ExecStart=-/sbin/agetty -o '-p -- \u' --noclear %I $TERM
Enquanto o serial-getty @ .service invoca este comando:
ExecStart=-/sbin/agetty -o '-p -- \u' --keep-baud 115200,38400,9600 %I $TERM
O comando usado em serial-getty @ .service passa o argumento agetty the --keep-baud , para configurar a velocidade da porta serial. De certa forma, getty @ .service funcionará em uma porta serial, mas pode não configurar a porta serial corretamente, o que pode acabar não funcionando tão bem quanto poderia ou talvez ser mais lento do que poderia ser se configurado adequadamente.
Por outro lado, getty @ .service passa agetty o argumento --noclear , portanto a tela do console não é limpa depois que um usuário efetua logout (isso era tradicionalmente configurado em pelo menos tty0.)
Outras diferenças em relação aos arquivos da unidade:
- serial-getty @ .service liga-se ao dispositivo udev para a porta serial (
BindsTo=dev-%i.device), portanto, se for um dispositivo removível (como USB), o systemd interromperá o getty se o dispositivo for removido ou desconectado. / li> - getty @ .service verifica se tty0 existe (
ConditionPathExists=/dev/tty0), portanto, ele não gera consoles locais se o suporte a eles estiver desativado no kernel. - getty @ .service não configura as variáveis de localidade (
UnsetEnvironment=LANG LANGUAGE LC_...) porque a localização normalmente não é suportada ou é mal suportada no console local.
Em relação ao seu caso particular em que você está mascarando ttyAMA0 e habilitando ttyUSB1, ttyUSB1 é uma porta serial (pelo menos, emula uma), então usar serial-getty @ .service seria mais apropriado.
No entanto, , ativar um getty @ ou [email protected] e mascarar o @ ttyAMA0 não é a melhor maneira de fazer isso.
O systemd pega sua configuração de console do kernel, tipicamente do argumento console= na linha de comando do kernel (isso é implementado por systemd-getty-generator , então veja sua documentação para mais detalhes.) Então tudo que você precisa fazer é configurar o console na linha de comando do kernel (com um argumento como console=ttyUSB1 , embora você queira incluir um console local como tty0 também) e o systemd fará a coisa certa.
Dê uma olhada em esta postagem do blog no suporte ao console serial no systemd para obter mais detalhes.