In the boot process. While I certainly know how things work, the RH7 boot process is a tad different with grub2 and systemd vs grub and init.
Startup process on 6 and earlier is pretty simple. After the BIOS or UEFI kicks the system and the MBR starts, you’re in the grub bootloader managed through /boot/grub/grub.conf (link to menu.lst). The lines are text editable so you can make changes, duplicate lines, etc. After the kernel loads, inittab is checked for the default run level and that directory is parsed starting with S00 and up through S99n. You can add scripts in /etc/init.d with links to the correct run level directory (/etc/rc3.d for example) and once it’s done, you’re up. You can use the standard init n command to change the init level.
Startup on 7 changes things up a touch. After the BIOS or UEFI kicks the system and the MBR starts, you’re still in the grub bootloader but it’s grub2 and the grub.conf file is actually a “compiled” collection of instructions. You don’t edit the file by hand but you use grub2-mkconfig to generate the file from a list of files in /etc/grub.d. These files begin with the order they’re added to the grub.conf file. To add a new stanza, create a new file. For example, I created 15_windows to let me boot to my Windows 7 installation. This puts the menu option after the 10_linux kernel script. The /etc/default/grub file is a configuration file that lets you set things like the default kernel to load. Once you select a kernel, systemd handles the rest of the startup process. See here:
You use systemctl similarly to using svcs and svcadm in Solaris.
In place of the /etc/inittab file, you use systemctl to set the default run level:
* Run Level 0 – poweroff.target
* Run Level 1 – rescue.target
* Run Level 2 – multi-user.target
* Run Level 3 – multi-user.target
* Run Level 4 – multi-user.target
* Run Level 5 – graphical.target
* Run Level 6 – reboot target
So you’d run systemctl set-default runlevel3.target because ‘multi-user.target’ is ambiguous. I don’t know what would happen if you tried to set it to ‘multi-user.target’.
It’s possible the commands we’re used to are still there although inittab is now just comments. I imagine we’ll need to deal with the changes rather than try to work around them.
Interesting set of links here. One note is that scripts in /etc/init.d will be linked to script.service to be managed by systemd.
Hmm, lots of reading there, on through XXI apparently along with other interesting bits. Time for more reading…