Antes havia algo como initrd, você tinha que passar o nome do dispositivo da partição que você queria usar como root fs na linha de comando do kernel. O kernel tinha um código especial para analisar esse nome e reconhecer um punhado de strings comuns, e traduzi-las para o seu bem conhecido dev_t number. Ou seja, internamente, o kernel conhece os dispositivos simplesmente como um índice numérico em uma matriz e, para montar um, você precisa saber seu número.
Nos dias anteriores ao plug and play e hot plug, quando os sistemas tinham apenas um ou dois discos que estavam sempre presentes, isso funcionava bem. Se o seu sistema de arquivos raiz era /dev/hda1 , então sempre foi assim. O advento do plug and play explodiu isso fora da água embora. Nos dias de hoje, você pode ter uma dúzia de unidades de disco internas, usb, iscsi ou o que quiser, e no interesse de diminuir os tempos de inicialização, elas são testadas em paralelo, portanto o nome do dispositivo pode mudar dependendo de qual em qualquer inicialização, ou na ordem em que você os conectou. Isso significa que o nome do dispositivo especificado da linha de comando do kernel pode facilmente ficar incorreto e você não inicializa.
Para contornar isso, o UUID foi introduzido. Especificando dispositivos pelo UUID, não importa se é sda ou sde, a unidade certa pode sempre ser encontrada. Isso, no entanto, requer realmente olhar para as unidades e é um pouco mais complexo que o nome simples e estático - > dev_t mapeamento que o código de inicialização do kernel pode fazer. Foi decidido que o kernel não é lugar para tal complexidade e assim o initrd nasceu. Ele pode ter os utilitários necessários para identificar o dispositivo raiz correto e montá-lo. Ele também pode fazer coisas arbitrariamente complexas, como abrir a rede e obter uma concessão de DHCP para acessar uma raiz nfs ou iscsi. Outras coisas que você precisa de um initrd incluem a configuração de raid e lvm ou crypto para acesso ao disco.