Olá! Como falado, aqui é um ex-usuário do Windows chegando no Linux.
Com relação ao primeiro problema, o boot está bem lento, li que desabilitando algumas rotinas na sessão “Aplicação da Inicialização”, o problema poderia ser resolvido. Fiz e nada mudou.
O segundo problema foi TENSO!! Deixei o PC hibernado (24h no máximo), ao retornar, apertei o ENTER e nada; movi o mouse e nada. Apertei o POWER e nada! Tive que reiniciar a máquina, achei que resolveria a questão. Só que não! Após o boot, que ficou muito mais lento do que antes, a tela ficava oscilando entre um fundo preto (logo Linux Mint) e o fundo do fabricante (Easy PC), solicitava a senha do usuário, mas ao digitá-la, nada acontecia. Quando conseguia sair desse problema, os ícones da tela de trabalho apareciam com uma tela preta de fundo, mas não conseguia iniciar qualquer atividade. No desespero, tentei formatar, voltar para o Windows, mas também não deu certo! Não sei o porquê, mas depois de alguns boots, e foram vários, consegui acessar minha área de trabalho.
Que dor de cabeça!! Grato pela atenção. Abraços.
Máquina: I5; 8Gb; Gnome 3.28.2; Kernel 5.3.0-59 generic
Que esquisito. Você pode nos dizer como baixou o arquivo .iso do S.O. (se foi via mirror normal ou torrent) e qual programa foi utilizado para gravá-la no pendrive?
Gabriel, eu comprei a máquina já formatada (Easy PC).
Para tentar agilizar o boot, vi alguns vídeo, digitei uma linha de comando no terminal (é isso, né?) e obtive esta resposta:
GRUB_DEFAULT=0 GRUB_TIMEOUT_STYLE=hidden GRUB_TIMEOUT=1 GRUB_DISTRIBUTOR= ‘lsb_release -i -s 2> /dev/null || echo Debian’ #GRUB_CMDLINE_LINUX_DEFAULT= “quiet splash video=eDP-1;d reboot= force amp=power off” GRUB_CMDLINE_LINUX_DEFAULT= “video=eDP-1:d quiet splash pci=noaer apci=force noapic nolapic reboot=b” GRUB_CMDLINE_LINUX= " "
Evite fazer alterações no timing do grub para zero, deixe pelo menos 1 segundo, vai afetar muito pouco o tempo de boot. Se algum desastre acontecer na sua máquina, vai ser mais uma dor de cabeça não poder acessar o grub para editar manualmente as opções de boot do kernel.
Você está conseguindo rebootar no momento e entrar no sistema? se possível postar o resultado dos comandos no terminal:
systemd-analyze
systemd-analyze blame
systemd-analyze critical-chain
para vermos se aparece algum culpado segurando seu boot
Quanto a tela piscando na inicialização durante o boot loading, ainda ocorre, talvez tentar reiniciar com o argumento nomodset (reinicie para entrar no menu do grub, aperte E para editar, e na linha de opções do boot, onde você vê quiet splash, no final dela, adicione nomodeset, aperte ctrl+X para iniciar) Talvez você precise remover quiet splash.
De resto vai ser difícil saber ao certo o que pode ser que esteja causando tudo isso, pode ser alguma mudança que você fez antes de hibernar. Seria preciso investigar mais a fundo os logs do journald/sistema.
Olá, Romulo! Tudo bem? Sei que já faz alguns meses mas eu também estou tendo um problema no boot do sistema (está incrivelmente lento, nunca vi isso antes). Estou com o Ubuntu 20.04 LTS recém instalado (ontem pra ser mais exato) numa máquina de 8gb RAM, processador i5-7200U, 2gb VRAM.
Rodei os comandos que você falou e apareceu a seguinte informação:
almi@almijr:~$ systemd-analyze
Startup finished in 3.968s (firmware) + 15.359s (loader) + 11.399s (kernel) + 8min 2.071s (userspace) = 8min 32.798s
graphical.target reached after 8min 1.741s in userspace
almi@almijr:~$ systemd-analyze blame
4min 37.605s plymouth-quit-wait.service >
2min 5.526s dev-sda3.device >
1min 29.932s networkd-dispatcher.service >
1min 24.265s systemd-journal-flush.service >
1min 22.234s accounts-daemon.service >
1min 17.108s NetworkManager.service >
1min 11.130s dev-loop0.device >
1min 9.898s polkit.service >
57.450s dev-loop1.device >
55.537s avahi-daemon.service >
55.536s bluetooth.service >
54.142s switcheroo-control.service >
54.133s thermald.service >
54.130s wpa_supplicant.service >
54.129s systemd-logind.service >
51.647s dev-loop2.device >
51.646s dev-loop3.device >
50.884s dev-loop4.device >
31.026s gpu-manager.service >
30.423s NetworkManager-wait-online.service >
28.510s snapd.seeded.service >
28.258s grub-common.service >
27.226s rsyslog.service >
24.665s apport.service >
24.158s ModemManager.service >
22.432s secureboot-db.service >
19.057s e2scrub_reap.service >
14.953s apparmor.service >
14.740s grub-initrd-fallback.service >
14.568s fwupd.service >
13.835s systemd-backlight@backlight:intel_backlight.service >
13.114s systemd-resolved.service >
10.778s systemd-tmpfiles-setup.service >
8.451s gdm.service >
7.564s systemd-modules-load.service >
7.378s systemd-rfkill.service >
6.527s bolt.service >
5.849s snapd.service >
5.661s user@125.service >
5.644s modprobe@drm.service >
4.831s apt-daily-upgrade.service >
4.533s systemd-sysusers.service >
4.496s systemd-random-seed.service >
4.461s systemd-udevd.service >
4.309s systemd-timesyncd.service >
3.884s udisks2.service >
3.768s systemd-fsck@dev-disk-by\x2duuid-cd1ae0e8\x2d481c\x2d4fd2\x2daa26>
3.698s nvidia-persistenced.service >
3.597s keyboard-setup.service >
3.490s systemd-journald.service >
3.103s systemd-udev-trigger.service >
2.535s colord.service >
2.418s ufw.service >
2.046s systemd-tmpfiles-setup-dev.service >
1.998s swapfile.swap >
1.893s snapd.apparmor.service >
1.751s plymouth-start.service >
1.626s openvpn.service >
1.612s upower.service >
1.557s plymouth-read-write.service >
1.315s kmod-static-nodes.service >
1.305s console-setup.service >
1.123s systemd-sysctl.service >
1.099s systemd-remount-fs.service >
1.091s dev-hugepages.mount >
1.091s dev-mqueue.mount >
1.090s sys-kernel-debug.mount >
1.089s sys-kernel-tracing.mount >
1.006s systemd-tmpfiles-clean.service >
976ms snap-core18-1880.mount >
874ms snap-gnome\x2d3\x2d34\x2d1804-36.mount >
847ms home.mount >
767ms snap-snapd-8542.mount >
754ms snap-gtk\x2dcommon\x2dthemes-1506.mount >
663ms kerneloops.service >
577ms snap-snap\x2dstore-467.mount >
535ms systemd-user-sessions.service >
515ms systemd-update-utmp.service >
345ms pppd-dns.service >
315ms setvtrgb.service >
256ms user-runtime-dir@125.service >
186ms rtkit-daemon.service >
101ms user@1000.service >
44ms snap-snapd-8790.mount >
35ms systemd-update-utmp-runlevel.service >
27ms snap-core18-1885.mount >
26ms user-runtime-dir@1000.service >
12ms dev-loop6.device >
9ms alsa-restore.service >
7ms dev-loop5.device >
3ms sys-fs-fuse-connections.mount >
2ms sys-kernel-config.mount >
2ms snapd.socket
log file: ystemd-analyze critical-chain
almi@almijr:~$ systemd-analyze critical-chain
The time when unit became active or started is printed after the “@” character.
The time the unit took to start is printed after the “+” character.
graphical.target @8min 1.741s
└─multi-user.target @8min 1.741s
└─snap-core18-1885.mount @7min 4.550s +27ms
└─dev-loop5.device @7min 4.574s +7ms
Eu não entendo absolutamente nada do que está aí kkkkk Pode me ajudar?
Tudo @almijr! Da para ver apenas que os Snaps são responsáveis por 27 segundos, ainda restou a plotagem que você não fez:
systemd-analyze plot > plt.svg
Você vai ter que postar online (não converte que vai ficar ruim de ler) em outra plataforma como o google drive.
O culpado mais típico em tempos esquisitos de boot são partições demorando para montar ou que não estão disponíveis mas são exigidas em automontagens (HDs externos, etc).
Eu vi que uma partição sua demora ~2 minutos para ser montada, partições atreladas ao /etc/fstab são entendidas como obrigatórias para o boot correto, o que leva o sistema a esperar por estas partições até que sejam montadas, para montar HDs externos automaticamente seria melhor usar outra técnica, como autofs ou systemd automount.