Por que preciso do initramfs?

14

Descobri que, se eu escolher jffs ou sd como sistema de arquivos (e não initramfs), o tamanho do kernel é muito pequeno (1,4 MB em comparação com o initramfs-3,4MB). Isso mostra que o initramfs ocupa um grande espaço concidiavelmente. Então id eu posso remover completamente vou ter kernel muito pequeno, que é o que eu quero.

Então, a pergunta básica em minha mente é: por que preciso do initramfs? pode um kernel Linux não inicializar apenas sem ter qualquer sistema de arquivos inicial?

Minha inscrição final só fará cálculo & comunicação - sem qualquer tipo de Portanto, um SO sem sistema de arquivos faz sentido - pelo menos para o meu aplicativo.

    
por gpuguy 29.03.2014 / 12:58

6 respostas

8

O aumento de tamanho de ter um initramfs não é devido ao driver de ramfs (é apenas alguns kB e necessário para outras coisas de qualquer maneira), mas para o próprio initramfs. O initramfs contém programas que são necessários para montar e montar o sistema de arquivos raiz real.

O Initramfs torna muito mais fácil e, em alguns casos, possível (por exemplo, criptografado / ), para inicializar o sistema. É altamente recomendável mantê-lo em hardware estilo PC com muitos periféricos hotpluggable. Por outro lado, faz muito sentido inicializar um dispositivo embutido sem qualquer initramfs, com um kernel que apenas suporta a configuração de hardware específica para a qual ele é construído.

O kernel, obviamente, precisa ser inicializado em um sistema de arquivos: deve haver alguma maneira de carregar qualquer aplicativo que você queira executar. Se você não for rodar nada, então você deve manter a máquina desligada.

Se você não quiser usar um initramfs, apenas diga ao seu bootloader para não passar um. Também não incluímos um na saída da compilação do kernel, é claro - como isso acontece se de alguma forma for dependente de arquitetura e de bootloader: por exemplo, vmlinux e bzImage não incluem o initramfs (eles são o kernel bruto e comprimido, respectivamente), mas o uImage (para o U-Boot) empacota tanto o kernel quanto o initramfs, se houver um.

(Tecnicamente, como mikeserv observa, sempre há um initramfs - mas, por padrão, ele é vazio, O que você está vendo, e querendo se livrar, é um initramfs “verdadeiro”, não vazio, criado pelo seu processo de compilação e contendo ferramentas que são usadas para montar o sistema de arquivos raiz.

Lembre-se, um initramfs pode ser uma maneira razoável de criar um sistema de aplicativo único sem dados persistentes: coloque todo o seu aplicativo no initramfs, inicialize-o e mantenha-o. Isso torna mais fácil organizar seu armazenamento persistente ou imagem de inicialização (tudo que você precisa é o kernel e o initramfs, que podem ser empacotados). Existem desvantagens nessa abordagem: todos os dados no initramfs serão armazenados permanentemente na RAM, e você não pode modificar facilmente os arquivos na imagem de inicialização, você deve reconstruir o arquivo.

    
por 30.03.2014 / 03:37
7

De LFS :

The only purpose of an initramfs is to mount the root filesystem. The initramfs is a complete set of directories that you would find on a normal root filesystem. It is bundled into a single cpio archive and compressed with one of several compression algorithms.

...

There are only four primary reasons to have an initramfs in the LFS environment: loading the rootfs from a network, loading it from an LVM logical volume, having an encrypted rootfs where a password is required, or for the convenience of specifying the rootfs as a LABEL or UUID. Anything else usually means that the kernel was not configured properly.

...

For most distributions, kernel modules are the biggest reason to have an initramfs. In a general distribution, there are many unknowns such as file system types and disk layouts. In a way, this is the opposite of LFS where the system capabilities and layout are known and a custom kernel is normally built. In this situation, an initramfs is rarely needed.

Outra fonte www.kernel.org

Além disso, há muitos sistemas Linux que gostam de roteadores que não usam initramfs.

    
por 29.03.2014 / 23:01
1

Você precisa de um initramfs para configurações mais complexas, como inicialização de rede ou lvm ou raid, pois eles exigem alguns utilitários de modo de usuário para configurar o acesso ao fs raiz. Para uma partição convencional e simples em um disco, contanto que você tenha os drivers de disco integrados ao kernel e especifique o argumento raiz por caminho de dispositivo em vez de UUID, você pode fazer isso sem um initramfs. É claro que o caminho do dispositivo está sujeito a alterações, dependendo de quais dispositivos plug and play (ou seja, usb) você conectou, ou simplesmente variações aleatórias de tempo, e é por isso que todo mundo usa uuids e initramfs para confiabilidade.

    
por 30.03.2014 / 03:36
0

Esta é uma pergunta antiga, mas ainda não parece ter uma resposta aceita, então eu vou jogar isso lá fora (não sou especialista aqui, estou tentando descobrir isso por mim mesmo.)

De link (todo o caminho na parte inferior que diz que não foi atualizado desde 2004.)

The kernel has currently 3 ways to mount the root filesystem:

a) all required device and filesystem drivers compiled into the kernel, no initrd. init/main.c:init() will call prepare_namespace() to mount the final root filesystem, based on the root= option and optional init= to run some other init binary than listed at the end of init/main.c:init().

b) some device and filesystem drivers built as modules and stored in an initrd. The initrd must contain a binary '/linuxrc' which is supposed to load these driver modules. It is also possible to mount the final root filesystem via linuxrc and use the pivot_root syscall. The initrd is mounted and executed via prepare_namespace().

c) using initramfs. The call to prepare_namespace() must be skipped. This means that a binary must do all the work. Said binary can be stored into initramfs either via modifying usr/gen_init_cpio.c or via the new initrd format, an cpio archive. It must be called "/init". This binary is responsible to do all the things prepare_namespace() would do.

To maintain backwards compatibility, the /init binary will only run if it comes via an initramfs cpio archive. If this is not the case, init/main.c:init() will run prepare_namespace() to mount the final root and exec one of the predefined init binaries.

Por que vale a pena, acredito que dispositivos / distros como Raspberry Pi, etc. não usam initramfs; em alguns casos, o kernel está na partição raiz (montada pelo bootloader que possui módulos fs requisitados). Em outros casos, onde o kernel é, e. em uma partição /boot , o initramfs na mesma partição pode ser acessado diretamente antes de montar os rootfs como outros afirmaram.

Em alguns casos, o initramfs pode ser construído no mesmo arquivo que o kernel, mas nem sempre é esse o caso. (a) parece afirmar claramente que em alguns casos o initramfs não é necessário.

    
por 14.10.2017 / 02:29
0

Eu acho a explicação a seguir mais clara,

initramfs is a root filesystem that is embedded into the kernel and loaded at an early stage of the boot process. It is the successor of initrd. It provides early userspace which can do things the kernel can't easily do by itself during the boot process.

Using initramfs is optional. By default, the kernel initializes hardware using built-in drivers, mounts the specified root partition, loads the init system of the installed Linux distribution. The init system then loads additional modules and starts services until it eventually allows you to log in. This is a good default behavior and sufficient for many users. initramfs is for users with advanced requirements; for users who need to do things as early as possible, even before the root partition is mounted.

Here are some examples of what you can do with initramfs:

  • Mount the root partition (for encrypted, logical, and otherwise special partitions);
  • Provide a minimalistic rescue shell (if something goes wrong);
  • Customize the boot process (e.g. print a welcome message, boot splash, etc.);
  • Load modules (e.g. third party drivers);
  • Anything the kernel can't do (as long as you can do it in user space, e.g. by executing commands). If you don't have advanced requirements, you don't need initramfs.
    
por 10.10.2018 / 11:04
-1

Não importa o que você faça, você tem initramfs . Não há como fazê-lo - é o único sistema de arquivos imposto a você. De kernel.org :

O que é o rootfs?

Rootfs é uma instância especial de ramfs (ou tmpfs , se estiver ativada), que é sempre presente em sistemas 2.6. Você não pode desmontar rootfs por aproximadamente mesmo motivo, você não pode matar o processo init; em vez de ter um código especial para verificar e manipular uma lista vazia, é menor e mais simples para o kernel para garantir que determinadas listas não fiquem vazias.

A maioria dos sistemas simplesmente monta outro sistema de arquivos sobre rootfs e o ignora. A quantidade de espaço ocupada por uma instância vazia de ramfs é minúsculo.

Se * CONFIG_TMPFS * estiver ativado, rootfs usará tmpfs em vez de ramfs por padrão. Para forçar ramfs , adicione "rootfstype=ramfs" à linha de comando do kernel.

O que é o initramfs?

Todos os kernels 2.6 do Linux contêm um arquivo em formato gzipped "cpio" , que é extraído em rootfs Quando o kernel inicializa. Após a extração, o kernel verifica se rootfs contém um arquivo "init" , e se for o caso ele é executado como PID 1. Se encontrado, esse processo init é responsável por levar o sistema até o fim, incluindo localizar e montar o dispositivo raiz real (se houver). Se rootfs não contiver um programa init após o incorporado > cpio arquivo é extraído para ele, o kernel vai cair para o código mais antigo para localizar e montar uma partição raiz e, em seguida, executar alguma variante de /sbin/init com isso.

Tudo isso difere do antigo initrd de várias maneiras:

  • The old initrd was always a separate file, while the initramfs archive is linked into the linux kernel image. (The directory linux-*/usr is devoted to generating this archive during the build.)

  • The old initrd file was a gzipped filesystem image (in some file format, such as ext2, that needed a driver built into the kernel), while the new initramfs archive is a gzipped cpio archive (like tar only simpler, see cpio(1) and Documentation/early-userspace/buffer-format.txt). The kernel's cpio extraction code is not only extremely small, it's also __init text and data that can be discarded during the boot process.

  • The program run by the old initrd (which was called /initrd, not /init) did some setup and then returned to the kernel, while the init program from initramfs is not expected to return to the kernel. (If /init needs to hand off control it can overmount / with a new root device and exec another init program. See the switch_root utility, below.)

  • When switching another root device, initrd would pivot_root and then umount the ramdisk. But initramfs is rootfs: you can neither pivot_root rootfs, nor unmount it. Instead delete everything out of rootfs to free up the space (find -xdev / -exec rm '{}' ';'), overmount rootfs with the new root (cd /newmount; mount --move . /; chroot .), attach stdin/stdout/stderr to the new /dev/console, and exec the new init.

Como este é um processo notavelmente persuasivo (e envolve a exclusão de comandos antes que você possa executá-los), o pacote klibc introduziu um programa auxiliar (utils / run_init.c) para fazer tudo isso por você. A maioria dos outros pacotes (como o busybox) nomeou este comando como "switch_root".

Preenchendo o initramfs:

O processo de compilação do kernel 2.6 sempre cria um arquivo initramfs no formato cpio compactado e o vincula ao binário resultante do kernel. Por padrão, este arquivo está vazio (consumindo 134 bytes no x86).

A opção de configuração CONFIG_INITRAMFS_SOURCE (na Configuração Geral em menuconfig, e vivendo em usr / Kconfig) pode ser usada para especificar uma fonte para o Arquivo initramfs, que será automaticamente incorporado ao binário resultante. Esta opção pode apontar para um cpio gzipado existente archive, um diretório contendo arquivos a serem arquivados ou uma especificação de arquivo de texto, como o exemplo a seguir:

  dir /dev 755 0 0
  nod /dev/console 644 0 0 c 5 1
  nod /dev/loop0 644 0 0 b 7 0
  dir /bin 755 1000 1000
  slink /bin/sh busybox 777 0 0
  file /bin/busybox initramfs/busybox 755 0 0
  dir /proc 755 0 0
  dir /sys 755 0 0
  dir /mnt 755 0 0
  file /init initramfs/init.sh 755 0 0

Execute "usr / gen_init_cpio" (após a compilação do kernel) para obter uma mensagem de uso documentando o formato de arquivo acima.

Uma vantagem do arquivo de configuração é que o acesso root não é necessário para definir permissões ou criar nós de dispositivo no novo arquivo. (Note que aqueles duas entradas de "arquivo" de exemplo esperam encontrar arquivos chamados "init.sh" e "busybox" em um diretório chamado "initramfs", sob o diretório linux-2.6. *. Veja Documentation / early-userspace / README para mais detalhes.)

O kernel não depende de ferramentas externas do cpio. Se você especificar um diretório em vez de um arquivo de configuração, a infraestrutura de construção do kernel cria um arquivo de configuração desse diretório (usr / Makefile chama scripts / gen_initramfs_list.sh) e prossegue para empacotar esse diretório usando o arquivo de configuração (alimentando-o para usr / gen_init_cpio, que é criado de usr / gen_init_cpio.c). O código de criação de cpio de tempo de construção do kernel é inteiramente independente, e o extrator de tempo de inicialização do kernel também é (obviamente) auto-suficiente.

    
por 30.03.2014 / 01:02