[Dica/Tuto] Otimizando initramfs ( Debian) e adicionado Initramfs mínimo( menos 6s no boot em um Celeron®) - 03/09

Para Initramfs mínimo no Debian , Ubuntu e etc… vá para QUARTA mensagem deste tópico


Carregando apenas os módulos da saída do lsmod

A ideia é basicamente esta:
https://wiki.archlinux.org/index.php/Minimal_initramfs
http://blog.falconindy.com/articles/optmizing-bootup-with-mkinitcpio.html

Este procedimento deverá ser feito logo quando inicializa o computador
Vamos ver no debian, e etc…
Primeiro recomendo testar com otimização lzop
De acordo com este link

Para isso, abre o arquivo /etc/initramfs-tools/initramfs.conf

COMPRESS=gzip
e toque parta lzop ( atenção para funcionar ele terá que estar instalado - apt install lzop)
COMPRESS=lzop

Agora procure por

MODULES=most
e troque para
MODULES=list ( isso deverá só iniciar os módulos que serão adicionados na lista módulos)

salve e feche

Execute o comando para saber quais módulos foram carregados com o sistema
lsmod | awk ‘NF==3{print $1}’

copie a lista e adicone no arquivo /etc/initramfs-tools/modules

salve e feche

se vc só está rodando um kernel, execute
sudo update-initramfs -u ( este comando só irá executar o kernel carregado, sugiro este , e é recomendado ter outro kernel para caso de algum erro)
para todos
sudo update-initramfs -k all

4 curtidas

Fiz aqui e quase não deu diferença.

Acho que só vai dar resultado em quem tiver HD mecânico. A diferença de tempo da leitura do arquivo será sentida nesse caso. No SSD que é meu caso, a diferença de tempo é mínima. Veja os resultados

GZIP com todos os módulos

Startup finished in 13.173s (firmware) + 6.272s (loader) + 6.060s (kernel) + 2.120s (userspace) = 27.626s
graphical.target reached after 2.113s in userspace
811ms systemd-logind.service
795ms lightdm.service
794ms plymouth-quit-wait.service
462ms media-Expansion.mount
385ms upower.service
333ms dev-sda2.device
258ms udisks2.service

LZOP só com os módulos necessários

Startup finished in 12.994s (firmware) + 6.032s (loader) + 5.893s (kernel) + 2.360s (userspace) = 27.281s
graphical.target reached after 2.351s in userspace
902ms systemd-logind.service
893ms plymouth-quit-wait.service
893ms lightdm.service
542ms media-Expansion.mount
469ms dev-sda2.device
376ms upower.service
272ms udisks2.service

Mas gostaria de agradecer pelo comando para mostrar todos os módulos carregados, vai ajudar na customização do kernel!

Ah, no Arch não recomendo tirar o keyboard do HOOKS, senão quando tiver algum problema na inicialização vc vai ficar sem o teclado quando aparecer aquela mensaginha safada “Please enter root password for maintenance or press Ctrl+D continue”

4 curtidas

Não vai funcionar porque não tem udev.
Tem um tempo que não vejo isso. Mas vou ver depois coloco aqui, mas acho se for usb tem que colocar estes dois módulos
hid_generic
usbhid
Vou fazer um teste e amanha adiciono aqui.

no arch vc pode subir com o minimo veja em
http://blog.falconindy.com/articles/optmizing-bootup-with-mkinitcpio.html

já no debian

ainda não tentei só subir., por exemplo,
ahci
sd_mod
ext4
i915

vou tetar e depois falo o resultado

1 curtida

Initramfs mínimo

                     Procedimento no Debian, Ubuntu, Mint e etc... 

Na primeira mensagem vimos como otimizar adicionando todos os drivers em uso. Agora vamos fazer colocando só o que for necessário para carregar o boot. Depois de carregado o próprio udev do sistema carregará os drivers necessário para o funcionamento do sistema.

Com este procedimento em uma máquina com processador celeron, 2Gde ram com HDD tirou 6 segundos do boot, segue o resultado.
Para fazer o teste desligue a máquina, espere 5 segundos e ligue novamente. Não reinicie. Reiniciar a máquina é sempre mais lento.

~$ systemd-analyze 
Startup finished in 7.568s (kernel) + 41.636s (userspace) = 49.205s
graphical.target reached after 41.602s in userspace

~$ systemd-analyze 
Startup finished in 6.222s (kernel) + 36.791s (userspace) = 43.013s
graphical.target reached after 36.769s in userspace

Para fazer no Linux Mint Mate tive que ler no manual sobre initramfs-tools, pois não conhecia. Diferente do Arch ele por padrão já carrega alguns HOOKS, como teclado, e a maioria não pode ser removida, que são scripts na pasta /usr/share/initramfs-tools/hooks/.
Para entender vamos ver o arquivo /etc/initramfs-tools/initramfs.conf.
Por exemplo o tipo de MODULES

#
# MODULES: [ most | netboot | dep | list ]
#
# most - Add most filesystem and all harddrive drivers.
#
# dep - Try and guess which modules to load.
#
# netboot - Add the base modules, network modules, but skip block devices.
#
# list - Only include modules from the 'additional modules' list
#

MODULES=list

Por padrão ele vem com o most, que adiciona a maioria dos sistemas de arquivos e todos os drivers de disco rígido.
Isso quer dizer que ele utiliza vários módulos desnecessários no carregamento. Iremos trocar para list , que irá incluir apenas os módulos que forem citados no arquivo /etc/initramfs-tools/modules.

Um outro item importante é o BUSYBOX.

#
# BUSYBOX: [ y | n | auto ]
#
# Use busybox shell and utilities.  If set to n, klibc utilities will be used.
# If set to auto (or unset), busybox will be used if installed and klibc will
# be used otherwise.
#

BUSYBOX=n

Por padrão é auto. Está opção carrega alguns HOOKS que veremos a seguir. Se não vai utilizar deixar como n. Aqui deixei como n.
Os arquivos de HOOKS são:

/usr/share/initramfs-tools/hooks/klibc-utils
/usr/share/initramfs-tools/hooks/zz-busybox-initramfs
/usr/share/initramfs-tools/hooks/cryptroot
/usr/share/initramfs-tools/hooks/dmraid

Para ver se existe mais algum além destes, execute o comando:
grep -ri BUSYBOX /usr/share/initramfs-tools/hooks/

E por fim, vamos ver a opção COMPRESS

#
# COMPRESS: [ gzip | bzip2 | lzma | lzop | xz ]
#

COMPRESS=lzop

Por padrão usa o gzip, mas vamos trocar para lzop, pois é mais rápido para extrair. Contudo o arquivo fica maior, não muito, pouca coisa.

Agora vamos ver quais módulos temos que realmente usar para carregar.
Como veremos na página falconindy : Optimizing Bootup With mkinitcpio [Dave Reisner]
Lembrando da opção most em MODULES. Adicione a maioria dos sistemas de arquivos e todos os drivers de disco rígido.
Então só precisamos do módulos de sistema de arquivo e disco rígido.
Para fazer isso executamos o comando abaixo:

$ udevadm info --attribute-walk -n /dev/sda1 | grep 'DRIVERS=="[^"]'
    DRIVERS=="sd"
    DRIVERS=="ahci"

Veja que só precisamos dos módulos sd_mod e ahci

Ok. Estamos quse terminando.
Escolhema opção list em modules (MODULES=list)
Lembra?
Que irá incluir apenas os módulos que forem citados no arquivo /etc/initramfs-tools/modules.

Vamos ver o arquivo agora.

# List of modules that you want to include in your initramfs.
# They will be loaded at boot time in the order below.
#
# Syntax:  module_name [args ...]
#
# You must run update-initramfs(8) to effect this change.
#
# Examples:
#
# raid1
# sd_mod

Adicionamos os dois módulos necessários.

# List of modules that you want to include in your initramfs.
# They will be loaded at boot time in the order below.
#
# Syntax:  module_name [args ...]
#
# You must run update-initramfs(8) to effect this change.
#
# Examples:
#
# raid1
# sd_mod
ahci
sd_mod

O ext4 não precisa adicionar, pois já é carregado por padrão no initramfs, veja com o comando:

lsinitramfs /boot/initrd.img-4.15.0-60-generic | grep -i ext4
Caso utilize outro recomendo verificar com este comando acima. Se não existi adicione.
Outro exemplo, i915, que também vem adicionado por padrão.
Um método para saber o que vem adicionado por padrão, é deixar o MODULES como list e não adicionar nada em /etc/initramfs-tools/modules. Atualize e o kernel e rode o comando. Atenção, não reinicie a máquina, pois terá problema. Faça isso, e execute lsinitramfs para saber se tem o módulo. Recomendo só fazer isso, se tiver interesse em saber o que é carregado por padrão.
O mais recomendado é fazer todo procedimento adicionando em /etc/initramfs-tools/modules, e depois executar lsinitramfs /boot/initrd.img-4.15.0-60-generic | grep -i "o que procura" para saber se tem o drive. Caso não tenha, adicione no /etc/initramfs-tools/modules e execute update-initramfs -u novamente para atualizar o initramfs.

OK . Quase pronto.

Agora vams atualizar initramfs. Nesta parte recomendo você fazer um backup do initramfs atual caso aparece alguns problema.
Exemplo:
$ sudo mv initrd.img-4.15.0-60-generic initrd.img-4.15.0-60-generic-backup

Vamos atualizar.
Para atualizar apenas o kernel que está rodando
sudo update-initramfs -u
Para atualizr todos os kernels ( como só tinha um kernel, não testei este comando)
sudo update-initramfs -u -k all

Caso tenha problema ao iniciar
Espere iniciar o menu do grub, escolha a imagem e tecle a tecla e, depois procure por initrd e mude para o nome do backup, por exemplo, initrd.img-4.15.0-60-generic-backup.

Pronto. Reinicie e veja se diminui o tempo com:
$ systemd-analyze

Vou adicionar amanhã o procedimento no Arch

3 curtidas

Só para enriquecer o tópico, já experimentou só utilizar o dracut antes de fazer esse procedimento? A imagem gerada com o dracut no fedora é quase 3 vezes menor que a imagem padrão, cerca de 28MB, se eu não me engano por padrão ele utiliza lz4 para gerar a imagem.

https://mirrors.edge.kernel.org/pub/linux/utils/boot/dracut/dracut.html#_mount_preparations

1 curtida

Não conhecia. Vou fazer o teste aqui.
Vou ler sobre o procedimento da instalação.
Se não me engano o lz4 deixa o arquivo maior

1 curtida

Parece muito bom, mas muito complexo também :no_mouth:
Poderia ter um vídeo disso

1 curtida

Com vídeo acho que fica mais complicado…
Fala com o @Dio. Talvez ele possa fazer um vídeo sobre este assunto.

2 curtidas

Acho que é algo muito específico para ser super interessante, relação custo benefício para vídeo talvez não justifique, mas um artigo pro blog pode ser legal :slight_smile:

2 curtidas

O dracut aceita diversos formatos, chamando o --help ele mostra diversas opções.

Captura%20de%20tela%20de%202019-09-04%2023-53-30

1 curtida

Desculpe por retomar uma discussão de doutores que mais parece reunião de cientistas loucos, mas tenho o que acrescentar. É uma pena, mas não funciona em Linux Mint, pelo menos, não no 20 Ullyana ( que já foi substituído há 2 meses atrás pelo 20.1 Ullyssa, mas este último ainda é instável ). O problema e o meu interesse aqui não é conseguir um boot para competir com o Usain Bolt e a Ferrari, mas é o mais grave problema recente do Ubuntu e do Mint: O Initramfs super-lento – 15 minutos ! – e ele continua lento mesmo em sistema recém-instalado, com espaço sobrando ( 61 Gigabertos de partição de sistema ). Agora que reinstalei, ontem mesmo, aproveitei o novo Initramfs fresquinho para tirar uma prova: Com todas as aplicações de Shell desligadas, só interface gráfica rodando, o meu update-initramfs demorou a bagatela de 30 segundinhos, o que parece muito bom, mas é só abrir o Nemo ou um tocador de música, que ele volta à demorar na casa das dezenas de minutos e algo mais. Com o chrome aberto então, meia hora. Conclusão: O problema é de prioridade de processo. Tirando um pente de memória da máquina, muda pouco, então não é falta de recurso disponível, é prioridade de processo mesmo. Isso não vai ser resolvido com nenhum Vudu. E avisando: No Mint, a linha MODULES do /etc/initramfs-tools/initramfs.conf citado acima no tuto, tem que continuar =most mesmo, foi assim que tive que reinstalar o sistema todo – meu kernell ficou imprestável, e o de reserva estava bugado e eu já devia ter substituído o sacana, só não o tinha feito por causa da correria e pq eu não queria reinstalar kernell correndo; aí no fim, aprendi que é melhor fazer kernell correndo mesmo do que não fazer. Seja lá como for, o que for, e por que for, algum módulo essencial deve ter ficado fora da lista porque não não apareceu nem no comando postado no tutorial nem no lsmod, e aí parece que o Mint não procura os módulos faltantes como o previsto. Ou talvez não seja algo do Mint, mas do kernell atual ( 5.8.0-45 ). Provavelmente, só customizar kernell à mão deve fazer alguma diferença no Mint, mas se o problema é de falta de prioridade de processo pro initramfs, seria apenas mais perda de tempo, pois nada resolverá, se muito, ganharei 3 segundos numa demora de meia hora. E o sistema quebrou, e aproveitando o tempo perdido no perrengue, eu tinha ontem pensado em fazer algo que eu vi sobre kernell em Documentação da SUSE sobre “Carregando os módulos do kernel automaticamente na inicialização” ( na seção 21.2.1 ) e achei interessante, mas não deve resolver o problema do initramfs lento se a causa do problema for de falta de prioridade. Na instalação anterior, os logs e os arquivos temporários devoraram todo o espaço de disco, então, é claro, o initramfs congelou. Mas em todas as instalações que fiz desde o Mint Rosa ( aka Ubuntu 17, só que melhor ) o problema reaparecia logo depois de fazer as instalações de aplicativos, na primeira reinicialização e ía ficando cada vez à cada mudança no sistema. Então, testar com instalação fresca era prioridade. E isso é tudo que tenho para dizer.

E acrescentando, só para confirmar que é mesmo problema de falta de prioridade de processo: Não havia falta de recursos no sistema, o monitor de sistema indicava capacidade ociosa para o processador ( i5 ) e memória ( 16Gb ), e a experiência tirando 8Gb da memória confirma isso. Mesmo com menos já era suficiente. Então dizer que esta lento ( meia hora de update-initramfs num dos testes ) porque havia Cinnamon, Nemo ( 2 janelas ), Clementine Player, e Chrome ( 10 abas ) rodando, não é desculpa, mesmo sendo um nível de uso assustador ! Mas, todo o sistema tem gargalos nos dispositivos ( como o HD, e i/o ) que sempre são mais lentos, então, no HD pelo menos, sempre vai ter algum processo ocupando ele, e uma fila de espera se houverem outras aplicações rodando; então se uma operação não tiver prioridade vai ficar para trás na espera mesmo ( também corrigi os badblocks com o fschek recentemente no HD velho e o outro HD é novinho. São 8 partições, o que torna o boot lento mesmo, mas não deveria interferir no tempo de Initramfs ( e os 2 HDs são Seagate Barracuda ! o que diminui a desculpa de gargalo no HD ). Havie então recursos disponíveis que não foram requisitados para completar operação pendente, porque certamente algum gargalo era o reesponsável pelo atraso. Por outro lado, nada melhor que um tocador de música mandando clássicos do rock ligado para testar prioridade de processos – para a música executar sem falhas, um alto nível de prioridade é exigido, competindo com outras operações, mesmo de root. Provavelmente só um kernell lowlatency resolveria, mas isso só é seguro numa placa ASUS ou Gigabyte, numa mobo Positivo ( a única que encontrei na pandemia, para um reparo ) usar um lowlatency é quase burrice. A placa vai ferver mesmo não fazendo nada.