Linux Mint MATE 20.2 do nada passou a ter boot muito lento [RESOLVIDO]

rommulo9
(usa Void Linux)

Enviado em 12/09/2021 - 12:30h

Olá amigos.

Instalei o Mint MATE 20.2 e tudo o mais que preciso, deixando ele redondo.
Bastou eu instalar em paralelo o KDE Neon 5.22.5, para o boot no Mint passar a demorar demais.

Ao teclar ESC, vi que é nisso que fica demorando:
"MATE: clean, 604516/2293760 files, 3588565/9175040 blocks"

O artigo em https://linuxdicasesuporte.blogspot.com/2017/10/mensagem-devsda1-clean-files-blocks-no.html informa que esse procedimento é bom para o usuário, alertando sobre possíveis perdas de dados, caso encontre bad blocks.
Mas meu sistema está num SSD 256 GB em perfeito estado, SanDisk model: SD8TB8U256G1001, size: 238.47 GiB

Então editei /etc/default/grub e deixei dessa forma:
GRUB_CMDLINE_LINUX_DEFAULT="fsck.mode=skip quiet splash"
Porém isso de nada adiantou!

O KDE Neon 5.22, Kubuntu 20.04, Mint Cinnamon 20.04, Fedora 34 e outras distros que já utilizei, nenhuma me fazia perder um tempo enorme de boot executando fsck... e adotei o MATE justamente por ser relativamente leve e rápido.

Segue alguns dados sobre meu boot:
$ systemd-analyze
Startup finished in 3.564s (kernel) + 2min 2.385s (userspace) = 2min 5.949s
graphical.target reached after 2min 2.371s in userspace

$ sudo dmesg| grep -i failed
[ 0.187932] acpi PNP0A08:00: _OSC failed (AE_ERROR); disabling ASPM
[ 4.762435] nvidia: module verification failed: signature and/or required key missing - tainting kernel

Não entendo esses "failed". Após iniciado o sistema, tudo pra mim roda 100% redondo, inclusive nvidia... (nvidia-driver-460.91.03, suficiente para minha NVIDIA GK107M [GeForce GT 640M])

$ systemd-analyze blame
31.877s vboxdrv.service
810ms dev-sda2.device
528ms upower.service
418ms systemd-logind.service
413ms udisks2.service
359ms lightdm.service
355ms plymouth-quit-wait.service
329ms networkd-dispatcher.service
273ms accounts-daemon.service
212ms ubuntu-system-adjustments.service
196ms user@1000.service
169ms bluetooth.service
162ms NetworkManager.service
162ms avahi-daemon.service
157ms systemd-backlight@leds:kbd_backlight.service
156ms polkit.service
147ms systemd-resolved.service
132ms networking.service
125ms geoclue.service
123ms ModemManager.service
122ms systemd-udev-trigger.service
118ms thermald.service
114ms wpa_supplicant.service
109ms gpu-manager.service
102ms systemd-journald.service
90ms swapfile.swap
84ms systemd-udevd.service
81ms hddtemp.service
78ms e2scrub_reap.service
77ms lvm2-monitor.service
76ms alsa-restore.service
75ms keyboard-setup.service
73ms grub-common.service
66ms lm-sensors.service
64ms apparmor.service
47ms ntp.service
45ms packagekit.service
43ms rsyslog.service
41ms systemd-tmpfiles-setup.service
39ms nvidia-persistenced.service
38ms systemd-modules-load.service
37ms systemd-tmpfiles-clean.service
35ms pppd-dns.service
32ms systemd-fsck@dev-disk-by\x2duuid-5ecb5696\x2d6795\x2d4365\x2db690\x2db4>
24ms systemd-rfkill.service
22ms grub-initrd-fallback.service
18ms proc-sys-fs-binfmt_misc.mount
16ms systemd-sysctl.service
16ms plymouth-read-write.service
15ms plymouth-start.service
15ms dev-hugepages.mount
15ms kerneloops.service
14ms dev-mqueue.mount
14ms systemd-sysusers.service
14ms user-runtime-dir@1000.service
14ms sys-kernel-debug.mount
14ms setvtrgb.service
13ms systemd-tmpfiles-setup-dev.service
13ms sys-kernel-tracing.mount
12ms systemd-random-seed.service
12ms blk-availability.service
12ms vboxautostart-service.service
11ms console-setup.service
11ms systemd-update-utmp-runlevel.service
10ms systemd-update-utmp.service
10ms kmod-static-nodes.service
10ms home.mount
10ms systemd-backlight@backlight:intel_backlight.service
10ms systemd-remount-fs.service
8ms vboxballoonctrl-service.service
8ms systemd-user-sessions.service
7ms vboxweb-service.service
6ms systemd-journal-flush.service
6ms rtkit-daemon.service
5ms ufw.service
4ms finalrd.service
4ms ifupdown-pre.service
4ms openvpn.service
4ms sys-kernel-config.mount
3ms sys-fs-fuse-connections.mount

Isso mostra que de fato o vilão era o fsck.

Meu fstab:
# /etc/fstab: static file system information.
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda2 during installation
UUID=f7b0f800-80e5-4158-b87f-62ce5943ddfe / ext4 errors=remount-ro 0 1
# /boot/efi was on /dev/sda1 during installation
UUID=3E75-B02D /boot/efi vfat umask=0077 0 1
# /home was on /dev/sda5 during installation
UUID=5ecb5696-6795-4365-b690-b46294ad6a87 /home ext4 defaults 0 2
/swapfile none swap sw 0 0

Já alterei para:
"UUID=f7b0f800-80e5-4158-b87f-62ce5943ddfe / ext4 errors=remount-ro 0 0" (zero e zero no final) mas não resolveu.

$ sudo blkid
/dev/sda2: LABEL="MATE" UUID="f7b0f800-80e5-4158-b87f-62ce5943ddfe" TYPE="ext4" PARTLABEL="MATE" PARTUUID="960eb8d0-0e7d-4f30-9038-444124d195c4"
/dev/sda3: UUID="20339a48-24ec-45b9-963b-cd1dc14fc061" TYPE="ext4" PARTLABEL="root" PARTUUID="be7ea91e-7b2b-2947-a046-72533bdaf265"
/dev/sda4: LABEL="LXQt" UUID="4fa87b59-b0b8-45cf-a135-81dfaa7b649f" TYPE="ext4" PARTLABEL="LXQt" PARTUUID="6d6cd3a1-4d89-4230-92bd-e3c1f65e4270"
/dev/sda5: LABEL="rp" UUID="5ecb5696-6795-4365-b690-b46294ad6a87" TYPE="ext4" PARTLABEL="rp" PARTUUID="1b669787-d703-4161-82b1-42cafd27d3f2"
/dev/sdb1: LABEL="Samsung_M3" UUID="353D8367389DFA89" TYPE="ntfs" PTTYPE="dos" PARTLABEL="Samsung_M3" PARTUUID="8408ca76-0deb-4dc4-8cab-a82020e0dae0"
/dev/sda1: PARTLABEL="EFI System Partition" PARTUUID="b0527f63-960f-49a3-8797-f11c1d1c68fc"



Lanço então três questões:

Como é que o MATE do nada, por conta própria, passou a executar o fsck sem eu ter mexido nada no GRUB? Ou as atualizações mais recentes ativaram o fsck?

Já que o parâmetro GRUB_CMDLINE_LINUX_DEFAULT="fsck.mode=skip quiet splash" não funcionou, o que de fato preciso mexer para cancelar de vez o fsck durante o boot, ou fazê-lo rodar só 1 vez por mês?

E já que uso Virtual Box, vai dar problema se eu executar "systemctl disable vboxdrv.service" pra ganhar mais 32s de boot?
Ao pesquisar, vi a seguinte resposta: "vboxdrv.service recompila os drivers do kernel apenas quando você atualiza seu kernel, o que tenho certeza de que você não faz diariamente. Ainda assim, você pode desativá-lo."

Gratidão a todos!

leandropscardua
(usa Ubuntu)

Enviado em 12/09/2021 - 14:15h

Dá uma olhada em /var/log/Xorg.0.log e procure por erro ou por delay de tempo entre uma linha e outra. No meu notebook cce (doado kkk) eu tenho um problema de autodetecção do monitor secundário(usando dois monitores). A saída (se tudo o mais estiver correto) é personalizar o arquivo /etc/x11/xorg.conf

Buckminster
(usa Debian)

Enviado em 12/09/2021 - 16:50h

/dev/sdb1: LABEL="Samsung_M3" UUID="353D8367389DFA89" TYPE="ntfs" PTTYPE="dos" PARTLABEL="Samsung_M3" PARTUUID="8408ca76-0deb-4dc4-8cab-a82020e0dae0"

Tu tem outro HD na máquina com Windows?
Tu usa o VB, tem algum sistema desses virtualizado nele?

Os sistemas de arquivos dentro de uma mesma unidade (HD) serão verificados sequencialmente, mas os sistemas de arquivos em unidades diferentes serão verificados ao mesmo tempo para utilizar o paralelismo disponível no hardware.

https://www.blogporta80.com.br/2013/04/26/artigos-desativando-e-reativando-o-fsck/


________________________________________________
Always listen the Buck!
Sanou tua dúvida, resolveu teu problema?
Então marque como Resolvido e escolha a Melhor Resposta.
Ou então execute:

# chown -R root:root /

# mount -o remount,rw /

# reboot

e veja o sistema derreter aos poucos. 

rommulo9
(usa Void Linux)

Enviado em 13/09/2021 - 13:29h

Oi Leandro,
Para mim apareceram apenas essas linhas com falha:
[ 95.468] (WW) Falling back to old probe method for modesetting
[ 95.472] (WW) Falling back to old probe method for fbdev
[ 98.641] randr: falling back to unsynchronized pixmap sharing

Será que é isso que está fazendo o boot demorar no meu caso?
Vou alterar a cfg da nvidia para "Sob demanda", que era como estava antes do boot se tornar lento.
Daí vou reniciar e ver no que dá.
Se a demora persistir, vou desativar o fsck e ver no que dá.

rommulo9
(usa Void Linux)

Enviado em 13/09/2021 - 13:38h

[quote]Buckminster escreveu:

/dev/sdb1: LABEL="Samsung_M3" UUID="353D8367389DFA89" TYPE="ntfs" PTTYPE="dos" PARTLABEL="Samsung_M3" PARTUUID="8408ca76-0deb-4dc4-8cab-a82020e0dae0"

Tu tem outro HD na máquina com Windows?
Tu usa o VB, tem algum sistema desses virtualizado nele?


Opa... esqueci que estava com meu HD externo Samsung_M3 plugado na USB. É meu backup em NTFS. Desconsidere-o...
Estou com Virtual Box instalado, e uma unidade VDI de 31,9 GB com Windows 8.1, em "/home/rommulo/VirtualBox VMs"
Uso Windows exclusivamente para rodar a ferramenta M3U8 e o sequenciador MIDI Cakewalk, só pq não rodam de jeito nenhum no Wine e Crossover.

Alterei a cfg nvidia para o modo "on demand". Agora, ao abrir aplic. básicos aparece o logo da "Intel", mostrando que o on-demand funciona 100%. Fiz essa alteração pra ver no que daria, pois estava "on-demand" antes do boot passar a demorar.

Desativei o fsck seguindo o link que vc me informou:

$ sudo tune2fs -c 0 /dev/sda2
tune2fs 1.45.5 (07-Jan-2020)
Definindo contagem máxima de montagens como -1

Ao reiniciar o sistema, a coisa ficou foi pior, pois agora ao teclar ESC durante o boot, só aparece um cursor piscando no canto da dela, e isso dura uns 2 minutos. Conforme a nova checagem abaixo, nada justifica tal demora:

$ systemd-analyze blame
677ms dev-sda2.device
416ms upower.service
391ms udisks2.service
351ms systemd-logind.service
326ms networkd-dispatcher.service
299ms lightdm.service
295ms plymouth-quit-wait.service
252ms accounts-daemon.service
180ms ubuntu-system-adjustments.service
178ms avahi-daemon.service
174ms bluetooth.service
172ms NetworkManager.service
(etc...)

$ systemd-analyze
Startup finished in 3.804s (kernel) + 1min 31.087s (userspace) = 1min 34.891s
graphical.target reached after 1min 31.076s in userspace

rommulo9
(usa Void Linux)

Enviado em 13/09/2021 - 14:25h

Amigos,

Teclar ESC durante o boot passou a mostrar apenas uma tela em branco, com cursor piscando no canto.
Após quase 2 minutos, aí sim aparece a listagem de processos, mas tão rápido como um relâmpago... tive então que filmar para conseguir capturar a imagem conforme abaixo.
Mas continuo sem saber o que fazer com as mensagens de erro que apareceram.

[ TIME ] Timed out waiting for device /dev/disk/by-uuid/3E75-B02D.
[DEPEND] Dependency failed for File System Check on /dev/disk/by-uuid/3E75-B02D.
[DEPEND] Dependency failed for /boot/efi.
[DEPEND] Dependency failed for Local File Systems.
[DEPEND] Dependency failed for Clean up any mess left by Odns-up.
finalrd.service
console-setup.service
(...)

É minha partição /boot/efi (vfat com 256 MB) que tem UUID=3E75-B02D.
Que há de errado? Que mistério é esse? Tô quase contratando o Sherlock Holmes :D

Buckminster
(usa Debian)

Enviado em 13/09/2021 - 15:28h

Reative o fsck.
Desative o secure boot na placa-mãe, se tiver.


________________________________________________
Always listen the Buck!
Sanou tua dúvida, resolveu teu problema?
Então marque como Resolvido e escolha a Melhor Resposta.
Ou então execute:

# chown -R root:root /

# mount -o remount,rw /

# reboot

e veja o sistema derreter aos poucos. 

rommulo9
(usa Void Linux)

Enviado em 13/09/2021 - 17:41h

[quote]Buckminster escreveu:

Reative o fsck.
Desative o secure boot na placa-mãe, se tiver.


Olá Buckminster.
Reativei o fsck e mexi na BIOS, não tinha security Boot, mas desabilitei o fast boot e outros detalhes. Porém não resolveram nada.
A sequência exibida na imagem anexo carrega instantaneamente, depois fica parada por quase 2 min e daí seguem-se os erros ligados a /boot/efi conforme listado anteriormente. O ambiente carrega e fica 100% utilizável, mas essa demora no boot não faz sentido se tratando do Mint MATE mais recente que instalei.

Aliás, mesmo antes de mexer na BIOS, meu Lubuntu 21.04 e KDE Neon 5.22 instalados paralelamente, davam boot normalmente e assim permanecem.
Ano passado tive problema de boot lento no Lubuntu 20.04 e não no Mint. Agora inverteu a situação.

rommulo9
(usa Void Linux)

Enviado em 14/09/2021 - 13:55h

Fala pessoal.

Vou atualizar o que ocorreu hoje:

- Rodei o boot repair, e por algum descuido meu, ele deletou o GRUB de minha partição EFI e não reinstalou. Fiquei sem boot algum.

- Rodando Linux em pendrive, restaurei uma imagem que tinha da minha partição EFI (/dev/sda1), e o boot passou a parar no cursor piscante do GRUB...

- Novamente rodei Linux em pendrive para usar o Gparted, então alterei os flags das partições de sistema (sda2 a 4) para "boot,esp" e a EFI (sda1) para "bios_grub".

Em seguida reiniciei e... VOILÀ !!! Tudo voltou ao normal... Problema resolvido, e com o fsck ativo!

Talvez a instalação do Lubuntu 21.04 por último, deve ter bagunçado as flags, pois ele acusava não ter encontrado a partição EFI, então optei pelo método "Substituir uma partição existente" (sda4). Mas fiz o mesmo procedimento com o KDE Neon (penúltima instalação na sda3) e esse não prejudicou em nada o boot do MATE.

Não me recordo com clareza como estavam as flags das partições anteriormente ao boot lento. Mas se não me falha a memória, eu tinha deixado sem nenhuma flag as partições de sistema (sda2 a 4), e a part. EFI (sda1) defini como "boot" mas o problema persistiu. Depois alterei para "bios_grub" e nada de novidade.

Mas enfim, agora o boot do meu Mint MATE 20.2 voltou ao normal: carrega em cerca de 17s, e o KDE Neon e Lubuntu que tenho em paralelo permanecem como antes (boot rápido).

Configuração:
BIOS com boot em Dual Mode, fast boot

Conforme fdisk -l:
Tipo de rótulo do disco: gpt
/dev/sda1 256M BIOS inicialização (bios_grub)
/dev/sda2 35G Sistema EFI (boot, esp) --> Mint MATE 20.2 (o boot voltou a ser rápido)
/dev/sda3 30G Sistema EFI (boot, esp) --> KDE Neon 5.22.5
/dev/sda4 30G Sistema EFI (boot, esp) --> Lubuntu 21.04
/dev/sda5 143,2G Linux sistema de arquivos --> /home do MATE

ricardogroetaers
(usa Linux Mint)

Enviado em 16/09/2021 - 03:55h

Fsck não é o vilão da história.
Recomendável habilitar a checagem dos sistemas de arquivos (suportados) pelo fsck na inicialização do sistema.
Fsck não suporta swap nem ntfs; exfat apenas checagem, não faz correção.

Habilitação é feita na última coluna de fstab <pass> da seguinte maneira:
0 -> não verifica
1 -> verifica em paralelo (vários volumes simultaneamente).
2 -> verifica serialmente, um volume de cada vez.

Sugestão:
- Volume raiz "/" -> 1
São em pastas "pontos de montagem" na partição raiz que os outros volumes serão montados.
Se o sistema de arquivos na partição raiz estiver com erros, vai complicar.
- Volumes no mesmo disco físico -> 2
- Volumes em discos físicos diferentes -> 1
Mint, por padrão, verifica tudo em paralelo.

Voce desabilitou a checagem do sistema de arquivos raiz:
Já alterei para:
"UUID=f7b0f800-80e5-4158-b87f-62ce5943ddfe / ext4 errors=remount-ro 0 0" (zero e zero no final) mas não resolveu.
Não é recomendável.

rommulo9
(usa Void Linux)

Enviado em 16/09/2021 - 11:36h

E ai Ricardo, blz

Foram ótimas a sua explicação e recomendação.

Na verdade, quando vi que não tinha resolvido, retornei ao 0 e 1:
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda2 during installation
UUID=f7b0f800-80e5-4158-b87f-62ce5943ddfe / ext4 errors=remount-ro 0 1
# /boot/efi was on /dev/sda1 during installation
#UUID=3E75-B02D /boot/efi vfat umask=0077 0 1
# /home was on /dev/sda5 during installation
UUID=5ecb5696-6795-4365-b690-b46294ad6a87 /home ext4 defaults 0 2
/swapfile none swap sw 0 0

Então pergunto, se deixar 0 e 1 pra raiz, e nesse caso o sistema checar todos os volumes, posso então deixar /boot/efi e /home com 0 e 0, já que estão no mesmo disco físico?