Basicamente o que está acontecendo é o seguinte:
ao linux
comando grub, adicionei debug --verbose
e consegui isso!
depois dos 60 anos de espera:
systemd-udevd 'SomeDevicePartition' is taking a long time
depois de mais 120s:
systemd-udevd 'SomeDevicePartition' killed
eles acontecem em +-: 60s, 180s, 240s, 365s,
então um total de 6 minutos!!!
Gostaria de saber se o tempo limite de morte do udevd pode ser reduzido para 10s e não tentar novamente? (usando alguma configuração na entrada do grub)
se você precisar de mais informações, todos os detalhes do problema estão aqui (acima é apenas a parte essencial): https://askubuntu.com/questions/1196874/18-04-grub-takes-about-6-minutes-to-boot -problem-systemd-udevd-somedevice
Eu tenho uma dica para contornar isso:
udevadm --timeout=10
mas posso precisar desfazê-lo usando uma imagem iso do LiveCD para:
Onde udevadm
armazena sua configuração? tentei cat ./udev/rules.d/* |grep timeout -i
e nao achei nada...
Também é para eventos genéricos, então, como bônus: existe algum tempo limite específico que eu possa configurar para lidar com a detecção de partição?
aqui está o que está no grub cfg:
linux /vmlinuz-4.15.0-72-generic \
root=/dev/mapper/MyLvmGroupName ro \
nosplash $vt_handoff debug --verbose
como uma dica de https://unix.stackexchange.com/a/559979/30352 (aqui), tentei:
linux /vmlinuz-4.15.0-72-generic \
root=/dev/mapper/MyLvmGroupName ro \
rd.udev.event-timeout=10 \
nosplash $vt_handoff debug --verbose
mas parece ser ignorado por algum motivo :( pois ainda tenho tempos limite muito longos (o mesmo, nada mudou)
Estou com esse problema desde +- 12/10/2019 :/ (A última vez que fiz uma atualização completa no Ubuntu18)
Parece que seu sistema usa o udev do systemd.
Então, vamos começar com esta página de manual de serviço (systemd-udevd.service(8)):
E mais:
Então, talvez você possa tentar adicionar
udev.event-timeout=10
(ou o mesmo prefixado comrd.
se o problema estiver na fase initrd) à linha de comando do kernel.