Na jakim poziomie szczegółowości Cię to interesuje?

Generalnie, to na początku startuje bios. Albo UEFI albo coś w tym stylu co "inicjuje" sprzęt, udostępnia określony zestaw operacji (przerwań w przypadku x86) i na koniec ładuje "coś" z dysku twardego, cdromu, sieci itepe.

W przypadku Linuksa tym czym jest bootloader - dla x86 zazwyczaj grub albo lilo, czasami spotyka się jeszcze syslinuxa lub którąś z jego form (isolinux dla płyt cd, pxelinux dla bootowania z sieci). Dla innych architektur istnieją odpowiedniki - dla sparc jest to np silo.

Bootloader następnie w "jakiś" sposób ładuje do pamięci initrd (jeżeli jest używane i obsługiwane przez bootloader) i jądro. Jakiś sposób - jest zależny od rodzaju bootloadera - czasami ma on po prostu zapisany adres plików (jak np lilo, syslinux...), czasami zaś "umie" obsłużyć system plików, więc wczytuje z poziomu systemu plików pliki initrd i jądra. initrd i jądro są rozpakowywane w pamięci i sterowanie jest przekazywane do jądra. 

Jądro wykonuje skrypt/program z initrd, który zazwyczaj inicjalizuje sprzęt, "składa" raidy, lvmy, ładuje do pamięci potrzebne moduły itepe i na koniec zazwyczaj montuje właściwy rootfs, przez pivot_root ustawia go jako /root i uruchamia init. Init - przeprowadza dalszy proces bootowania się systemu - zależny już od dystrybucji, skryptów startowych itepe. Inaczej będzie tutaj w przypadku skryptów w stylu sys v, inaczej przy skryptach w stylu bsd, inaczej przy systemd.

Na temat każdego z etapów można dużo opowiedzieć. :)

Jak masz jakieś bardziej szczegółowe pytania, to pytaj.

Zacznijmy od tego że grub uruchamia się dwuetapowo. W pierwszym etapie bios albo coś takiego ładuje jego "stage1". W drugim etapie - stage1 gruba ładuje moduły do obsługi systemu plików/raid/lvm itepe (stage2) - i od tego momentu grub jest w stanie załadować plik konfiguracyjny, jądro i initrd.

Po wybraniu przez użytkownika odpowiedniej opcji - zazwyczaj do pamięci ładowany jest initrd i jądro. initrd jest albo bezpośrednio systemem plików (squashfs np.), który zostaje załadowany do ramdysku, albo też spakowanym archiwum systemu plików, który zostaje załadowany do ramdysku (initramfs).

Dla Ubuntu initrd jest w formie spakowanego przez gzip archiwum w postaci cpio:

undefine@uml:~$ file /boot/initrd.img-4.4.0-71-generic 
/boot/initrd.img-4.4.0-71-generic: gzip compressed data, last modified: Sun Apr  2 22:19:18 2017, from Unix
undefine@uml:~$ gzip -d < /boot/initrd.img-4.4.0-71-generic  |file -
/dev/stdin: ASCII cpio archive (SVR4 with no CRC)

Zobaczmy co w nim jest:

undefine@uml:~/altkom$ gzip -d < /boot/initrd.img-4.4.0-71-generic  |cpio -i
216729 bloków
undefine@uml:~/altkom$ ls
bin  conf  etc  init  lib  lib64  run  sbin  scripts  usr  var

Grub po załadowaniu initrd i jądra do pamięci - uruchamia z niego skrypt /init.

Co robi skrypt init - jest to już zależne od dystrybucji. W przypadku Ubuntu jest to zwykły skrypt, który po kolei ładuje potrzebne moduły, potem np. odszyfrowuje urządzenia blokowe (./scripts/local-block/cryptroot), składa raid (./scripts/local-block/mdadm), podnosi lvma (./scripts/local-block/lvm2). Ogólnie - wykonuje wszelkie operacje niezbędne, by w systemie pojawił się zamontowany przyszły /root (może go np. montować przez sieć z nfs-a, może go składać z lvma będącego na raidzie na szyfrowanych urządzeniach blokowych itepe). Na samym końcu, gdy już przyszły root (/) jest dostępny, skrypt init wykonuje przemontowanie /sys i /proc z swojego systemu plików do przyszłego roota i zmienia roota:

# Move virtual filesystems over to the real filesystem
mount -n -o move /sys ${rootmnt}/sys
mount -n -o move /proc ${rootmnt}/proc

# Chain to real filesystem
exec run-init ${drop_caps} ${rootmnt} ${init} "$@" ${recovery:+--startup-event=recovery} <${rootmnt}/dev/console >${rootmnt}/dev/console 2>&1

W tym momencie powinien się już wykonywać init z właściwego systemu plików, domyślnie jeżeli nie podano inaczej  /sbin/init, który w Ubuntu jest linkiem do systemd:

undefine@uml:~$ file /sbin/init
/sbin/init: symbolic link to /lib/systemd/systemd

W tym momencie uruchamia się systemd i zabawa się toczy dalej. :) Ale systemd to już kolejna historia. ;)