SIGRTMIN no plymouthd depois de mudar de upstart para systemd

3

Acabei de atualizar minha instalação do Kubuntu para animada (15.04). Após a atualização, a inicialização padrão com o systemd falha logo após mostrar a animação do kubuntu (plymouth). A última entrada do arquivo de log é um SIGRTMIN no plymouthd. Só consigo acessar a tela de login usando upstart (em vez de systemd) nas opções avançadas do GRUB.

    
por Stéphane Tréboux 27.04.2015 / 07:43

2 respostas

2

A causa raiz foi uma alteração que fiz no fstab com base nas recomendações para drives de estado sólido (SSD). Eu removi essas linhas e consegui acessar a tela de login com o systemd:

# ramdisks
tmpfs /tmp tmpfs defaults 0 0
tmpfs /var/lock tmpfs defaults 0 0
tmpfs /var/log tmpfs defaults 0 0
tmpfs /var/run tmpfs defaults 0 0
tmpfs /var/tmp tmpfs defaults 0 0

Minha opinião é que é desnecessário configurar discos RAM para pastas temporárias no fstab. O SSD pode manipular ciclos de exclusão suficientes para serem usados em pastas temporárias; onde faz sentido systemd irá configurar um disco RAM em si (veja link ) então não há necessidade de usuário para ajustar o fstab.

    
por Stéphane Tréboux 27.04.2015 / 13:09
2

tldr;

Se você estiver trabalhando em um sistema de inicialização dupla (Windows + Linux), uma partição montada automaticamente (no Linux) ainda pode ser bloqueada pelo Windows (mesmo que não seja a partição do sistema Windows!).

versão longa

Eu tive o mesmo problema com o meu xubuntu 16.04. Tenho o Windows 10 e o xubuntu instalados no meu laptop (dual boot) e dividi o disco rígido em três (+1) partições: windows, ubuntu (+ swap) e 'exchange'. 'Exchange' é pensado como uma partição para armazenar dados comuns entre o Windows e o Linux. Ele é montado automaticamente no Windows e no Linux.

Infelizmente, o encerramento "híbrido" do Windows não bloqueia apenas a partição do Windows, mas também a partição "exchange". Ao iniciar o xubuntu após um desligamento normal (= híbrido) do Windows, o xubuntu não pode montar automaticamente a partição 'exchange'.

Para descobrir se esse é o caso, deve-se usar o comando systemctl --failed . No meu caso, retornou a informação de que a montagem da 'troca' falhou.

    
por daniel.neumann 30.01.2017 / 00:13