Start­ing up Linux

Want to know what hap­pens when you boot up your Linux PC? Neil Both­wick dis­sects the boot process, step by step…

Linux Format - - ESCAPE WINDOWS -

No, this isn’t another ar­ti­cle on get­ting going with Linux for new users. This is about how Linux starts it­self. Part of the joy of Linux is that as a user you re­tain full con­trol over the en­tire sys­tem, if you want it. To many users this is just some form of magic, ex­cept that in­stead of us­ing smoke and mir­rors, most of the ac­tiv­ity is hidden be­hind a fancy splash screen. We’re going to look at the whole process, from when you press the power but­ton to when the desk­top ap­pears. This can be bro­ken down into a num­ber of stages: POST, Boot­loader Ker­nel load­ing Ini­tial ram disk De­vice ini­tial­i­sa­tion Init Service startup and run­levels Dis­play Man­ager, Desk­top startup

We’ll look at each step in turn, ex­am­in­ing what hap­pens and the choices you can make. As with so many as­pects of Linux, there are al­ter­na­tive ways to han­dle each part of the process. Let’s start with an over­view of what each stage in­volves.

POST is Power On Self Test, a rou­tine run by the com­puter’s hard­ware, check­ing mem­ory, look­ing for con­nected drives and so on. It’s at this stage that you can hold down a key to ac­cess the firmware’s con­fig­u­ra­tion menus or pop up a menu to select which de­vice to boot from.

The boot­loader pro­vides a menu from which you choose your op­er­at­ing sys­tem on dual boot sys­tems as well as other boot op­tions. It’s some­times hidden, wait­ing a few sec­onds be­fore going with the de­fault. Press­ing the space bar at this point usu­ally shows it. The boot­loader then loads the ker­nel, pass­ing it some op­tions such as the lo­ca­tion of your sys­tem par­ti­tion and, usu­ally, also loads an ini­tial ramdisk. That’s a disk im­age loaded into mem­ory that con­tains the soft­ware needed to ini­tialise your hard­ware.

Once the ker­nel is loaded it runs a pro­gram called init, which con­trols ev­ery­thing from here on. Ser­vices are back­ground pro­grams, such as a cron dae­mon or a sys­tem log­ger, that are fired up at this stage. Most dis­tros de­fine var­i­ous run­levels, one of the op­tions se­lectable from a boot menu, that de­fine how the com­puter should boot up. For ex­am­ple, tra­di­tion­ally run­level 1 was sin­gle user mode, 3 was multi­user text mode and 5 gave the graph­i­cal desk­top. A dis­play man­ager is the pro­gram that asks for your lo­gin de­tails, and may let you select a desk­top en­vi­ron­ment, be­fore load­ing the graph­i­cal en­vi­ron­ment. Fi­nally, your desk­top loads, pos­si­bly start­ing some user-level pro­grams and en­abling you to use the com­puter.

Start­ing up

There’s not too much to say about POST. You’ll need to read your hard­ware’s man­ual to see what op­tions are avail­able to you. This loads the ba­sic firmware, what was called a BIOS on older sys­tems. You can do clever things like over­clock­ing your com­puter if you’re feel­ing brave, or re­set to de­faults if you’re not. It’s worth not­ing that moth­er­board man­u­fac­tur­ers pro­vide firmware up­dates to fix bugs, so up­dat­ing this is as im­por­tant as up­dat­ing any soft­ware in your op­er­at­ing sys­tem.

Now we get to one of those points where there are choices to be made. In older BIOS sys­tems, the hard­ware loaded soft­ware from the first 446 bytes of the hard disk to boot the com­puter. This tiny piece of code in the Master Boot Record (MBR) then has to find the rest of the boot­loader, usu­ally GRUB, on the hard disk. GRUB, the Grand Uni­fied Boot

Loader, presents a menu from which you can choose boot op­tions. There’s gen­er­ally a de­fault op­tion that’s ac­ti­vated if you don’t make a se­lec­tion within a cer­tain time. There are other boot­load­ers, such as lilo, but GRUB has be­come the stan­dard be­cause it han­dles a range of hard­ware and is able to gen­er­ate its menus au­to­mat­i­cally, which is im­por­tant when in­stalling a new dis­tro, par­tic­u­larly for dual boot. GRUB’s menu file is lo­cated at /boot/grub/grub.cfg . While you can edit this by hand, the rec­om­mended route is to change set­tings in /etc/de­fault/grub and then run $ sudo grub-mk­con­fig -o /boot/grub/grub.cfg to gen­er­ate a new menu file. Some dis­tros hide the menu, only show­ing it if you press a key. You can change this, as well as the time­out, by edit­ing /etc/de­fault/grub as above.

GRUB is sim­ply a boot­loader, and so it then loads which­ever op­er­at­ing sys­tem ker­nel you tell it to. How­ever, this is no longer nec­es­sary with mod­ern UEFI hard­ware, which can load a ker­nel di­rectly if it’s been set up to do so. UEFI ex­pects the first par­ti­tion of your disk to con­tain a FAT filesys­tem and it looks there for any load­able ker­nels. It will load the de­fault one, which is set in the firmware, or you can press a key for a menu list­ing all your op­tions.

This re­moves the need for a boot­loader, but most peo­ple still pre­fer to have a boot man­ager – some­thing that gives them a choice of op­er­at­ing sys­tems or ker­nels at boot time. You can still use GRUB for this, but it’s overkill. Sys­temd’s boot ctl pro­gram uses a sim­ple con­fig­u­ra­tion file to cre­ate menu op­tions, that ap­pear in a sim­ple text menu. Al­ter­na­tively, you can use rEFInd ( www.rods­ which uses a nice graph­i­cal menu, and is usu­ally able to cre­ate that au­to­mat­i­cally based on what’s on your hard disk.

Ker­nels and ramdisks

One of the rea­sons for us­ing a boot man­ager, even if you have a UEFI sys­tem that can boot a ker­nel di­rectly, is to pass pa­ram­e­ters to the ker­nel. You can usu­ally view the pa­ram­e­ters used to boot the ker­nel on your run­ning sys­tem with the fol­low­ing: $ cat /proc/cmd­line Some of th­ese op­tions are cos­metic, such as the ones that load a splash screen, but some are crit­i­cal. For ex­am­ple, the root= pa­ram­e­ter tells the ker­nel which par­ti­tion holds the op­er­at­ing sys­tem, a ker­nel with­out the rest of the OS has rather lim­ited use­ful­ness. The ker­nel op­tions may also spec­ify the init sys­tem to use, which we’ll come to shortly or spec­ify a path to an ini­trd.

Linux has a mono­lithic ker­nel of sorts. A mono­lithic ker­nel con­tains all the code and drivers needed to load an OS, as op­posed to a mi­cro-ker­nel that con­tains only the core code and loads the rest on de­mand. Ar­gu­ments on which is bet­ter have lasted years, but Linux has ended up be­ing a bit of both.

In the days when you com­piled your own ker­nels, you in­cluded the parts needed to boot your sys­tem: drivers for your hard disk con­trollers, the filesys­tem you used, your net­work card and so on. That gave you a ker­nel with ev­ery­thing you needed, but it wouldn’t nec­es­sar­ily work any­where else. Dis­tros need to cover all bases, but in­clud­ing drivers for every de­vice in the ker­nel would make it bloated, so load­able mod­ules were added. Th­ese are ex­tra parts of

driver code that are loaded on de­mand; your com­puter would load the driver for your net­work card and leave the oth­ers un­touched, tak­ing up only a lit­tle disk space.

That leaves the ques­tion of how to mount your hard disk if the drivers are stored as mod­ules on that disk? And so the ini­tial ram disk was born. This is a file con­tain­ing a disk im­age with all the essentials in­cluded. It’s stored in the same di­rec­tory as the ker­nel and so, like the ker­nel, it’s loaded by the boot­loader. The ker­nel mounts this disk at a tem­po­rary lo­ca­tion, loads the mod­ules it needs and then un­mounts the disk and switches the root di­rec­tory to the correct lo­ca­tion. It doesn’t mat­ter how large this ramdisk is, within rea­son, be­cause it’s only loaded into mem­ory for a few sec­onds, be­fore be­ing dis­carded. The ramdisk takes care of ev­ery­thing that needs to be done to get at the rest of the OS, even if that’s on a strange format medium or else­where on the net­work.

It’s pos­si­ble to build the ramdisk im­age into the ker­nel file, but the stan­dard sys­tems used by dis­tros all use a sep­a­rate file for it. Look in your /boot di­rec­tory and you’ll see a cor­re­spond­ing initramfs or ini­trd file for each ker­nel. Strictly speak­ing, the ker­nel uses an initramfs th­ese days, but the ini­trd ter­mi­nol­ogy re­fuses to die. The dif­fer­ence is in the un­der­ly­ing struc­ture, to a user they work in the same way.

One of the first things the ker­nel does is scan the avail­able hard­ware and loads drivers for it. Un­like with other op­er­at­ing sys­tems where driver in­stal­la­tion is a sep­a­rate process, Linux in­cludes drivers for the vast ma­jor­ity of hard­ware by de­fault. You can see this in the ker­nel mes­sages, shown by run­ning $ dmesg | less You’ll see that the ker­nel iden­ti­fies the CPU, moth­er­board and mem­ory early on and then goes on to find all your other hard­ware. By the time the op­er­at­ing sys­tem starts to load, all your hard­ware should be avail­able to it.

Service startup

If you want a bet­ter idea of what is hap­pen­ing when your com­puter boots, get rid of the splash screen that hides the real work. You can usu­ally do this by press­ing Esc as soon as it ap­pears, or you can use your boot menu’s edi­tor to re­move any ref­er­ences to splash and quiet from the ker­nel op­tions. When you boot you’ll see lines of text scrolling by, most or all of them re­port­ing OK. Th­ese are ser­vices be­ing started.

Ser­vices, also known as dae­mons, are pro­grams that run in the back­ground, each one per­form­ing a spe­cific task. Th­ese can be ser­vices like NTP (Net­work Time Pro­to­col) that keeps your com­puter’s clock run­ning ac­cu­rately, or cron, a service that runs com­mands at reg­u­lar in­ter­vals or a sys­tem log­ger that pro­vides a means or recording sta­tus mes­sages from the other pro­grams on your com­puter. Th­ese are ser­vices that run on most com­put­ers, then there are the server dae­mons, web server, mail servers and so on that are used to pro­vide ser­vices to other com­put­ers, that you may not be run­ning on a desk­top sys­tem.

“One of the first things the ker­nel does is scan the avail­able hard­ware and load drivers for it.”

Run­ning th­ese ser­vices is taken care of by a service man­ager. This is a com­plex task: ser­vices need to be started when the com­puter boots and cleanly stopped when the com­puter shuts down or re­boots, but there’s more to it than that. Some ser­vices de­pend on oth­ers, the or­der is im­por­tant. There’s also a need to make sure that ser­vices con­tinue to run and that some ac­tion be taken if a service fails.

The tra­di­tional service man­ager for Unix and Linux is based on SysVInit, from the Unix days. This uses a set of run­levels, each one rep­re­sent­ing a par­tic­u­lar state of the sys­tem. The stan­dard run­levels are: Halt Sin­gle-user mode Multi-user mode Multi-user mode with net­work­ing Not used As run­level 3 plus dis­play man­ager Re­boot Ser­vices are started and stopped by scripts that are stored in /etc/init.d . There’s also a di­rec­tory for each of the run­levels, /etc/rc0.d to /etc/rc6.d . Th­ese con­tain sym­links to the scripts in /etc/init.d . So when you boot the com­puter in run­level 3, all the scripts from /etc/rc3.d are run. On startup, they’re run in or­der and passed with the ar­gu­ment “start”. On shut­down or re­boot they’re run in re­verse or­der with the ar­gu­ment “stop”.

How does the sys­tem know the correct or­der to start ser­vices? That’s done on the names of the scripts, so they all start with num­bers, mak­ing it easy to spec­ify an or­der. So: S01sys­log-ng S02cron S03­fire­walld

This means the sys­tem log­ger starts first, then the cron dae­mon and then the fire­wall. The init scripts are run in se­rial, so one has to fin­ish start­ing be­fore the next one is run. It’s a fairly crude sys­tem and can slow down the boot process if one service takes a while to fire up, but it has been used since Li­nus Tor­valds was a lad and is re­li­able. Note that the de­tails of how each dis­tro im­ple­ments

SysVInit and its run­levels can vary, both in terms of the lo­ca­tion of the scripts and the def­i­ni­tions of the run­levels.

The new kid

There are a num­ber of al­ter­na­tive service man­agers, such as Up­start (now dead) and Gen­too’s rather pleas­ing openrc, but none of them have gained much main­stream ac­cep­tance, with one no­table ex­cep­tion. The muchdis­cussed (where dis­cussed also in­cludes ar­gued over, flamed about and even re­viled) sys­temd at­tempts to rem­edy some of the lim­i­ta­tions of SysVInit.

One of the core dif­fer­ences is that SysVInit uses shell scripts to start and stop ser­vices. Each service has a com­plete script to han­dle this, with sev­eral con­se­quences. A lot of work is du­pli­cated, even with some sys­tems pro­vid­ing helper func­tions, read­ing the scripts to see ex­actly what is done when a service is restarted isn’t a sim­ple task and there’s frag­men­ta­tion be­tween dis­tros as each one uses its own scripts to tie in with their way of do­ing things.

By con­trast, sys­temd uses service files that sim­ply tell

sys­temd what to do, rather than do­ing ev­ery­thing. Most service files are only a few lines and a quick glance is all that’s needed to see what will be done. As all the real work is done by sys­temd it­self, it also means that th­ese service files are stan­dard­ised, and the same file usu­ally works across most dis­tros. More im­por­tantly, the service files in­clude de­pen­den­cies, so a file for a web server will state that net­work­ing needs to be started first, while the one for the fire­wall can spec­ify that it needs to be started be­fore the net­work comes up.

So th­ese three will be started se­quen­tially, each wait­ing for its pre­de­ces­sor, but other ser­vices are free to start when they want. There’s no rea­son to de­lay start­ing cron while the net­work gets an ad­dress from DHCP just be­cause it has a higher num­ber in front of its name. And there’s another ben­e­fit to hav­ing sys­temd start the pro­grams it­self: it can mon­i­tor them if re­quested. A service file can tell the sys­tem what to do in the event of a pro­gram fail­ing, from restart­ing it (use with cau­tion) to no­ti­fy­ing you.

Of course, sys­temd does a lot more, but those are sep­a­rate com­po­nents of the over­all sys­temd in­fra­struc­ture and noth­ing to do with service start­ing in the main.

Net­work­ing startup

We’ve looked at start­ing ser­vices in gen­eral, whether by SysVInit or sys­temd, but there’s one group of ser­vices that de­serve spe­cial at­ten­tion, those re­lat­ing to net­work­ing. We are not talk­ing about ser­vices that use the net­work but those that are needed to make it work in the first place. Linux re­lies on net­work­ing, as do most peo­ple th­ese days, even if it’s on a stand­alone ma­chine. There are three points at which net­work­ing is ini­ti­ated dur­ing the startup process. The lo­cal­host in­ter­face (lo) is brought up early on. This en­ables net­work-aware pro­grams to com­mu­ni­cate on the lo­cal com­puter and re­quires lit­tle else.

Ex­ter­nal net­work in­ter­faces are brought up soon af­ter that. Re­mem­ber what we said about the or­der of service startup? Some ser­vices de­pend on a net­work in­ter­face, so it has to be avail­able be­fore they start and is usu­ally brought up quite early. If you have a sin­gle, wired in­ter­face this is very sim­ple. Dis­tros gen­er­ally use Dy­namic Host Con­fig Pro­to­col to ob­tain an ad­dress and the other rout­ing in­for­ma­tion it needs from a DHCP server on the net­work (usu­ally your mo­dem/router) and then sets up the net­work for you.

If you need a static ad­dress, you’ll have to do some set­ting up your­self. You can still use the DHCP server to give a static ad­dress: most routers will en­able you to al­lo­cate spe­cific ad­dresses to in­di­vid­ual MAC ad­dresses (the MAC ad­dress is the unique hard­ware ad­dress of a net­work in­ter­face). Do it this way and you still use DHCP, but get the same ad­dress every time. Al­ter­na­tively, use your dis­tro’s net­work con­fig­u­ra­tion tool to set up a static ad­dress, which must be on the same range (sub­net) as the rest of your net­work. In ad­di­tion to the com­puter’s ad­dress, you’ll need to give it a gate­way ad­dress (usu­ally that of your router) and one or more DNS servers. You can use your ISP’s DNS, a public one like those pro­vided by Google, or use the ad­dress of your router, which will for­ward re­quests to an ex­ter­nal server.

Wire­less net­work­ing is another mat­ter as multiple net­works and au­then­ti­ca­tion cre­den­tials may be in­volved. It’s usu­ally han­dled by a pro­gram like Net­workMan­ager. De­pend­ing how you have Net­workMan­ager con­fig­ured, it may search for and con­nect to a known net­work when the

com­puter is boot­ing, or it may not do so un­til you log into the desk­top. The lat­ter ap­proach is the de­fault. It’s slower, be­cause the con­nec­tion ne­go­ti­a­tion doesn’t start un­til af­ter the desk­top loads, but it’s more se­cure. There’s usu­ally an op­tion to en­able a net­work set­ting glob­ally if you want

Net­workMan­ager to start it dur­ing service startup. We say “usu­ally” be­cause there are dif­fer­ent user in­ter­faces used on var­i­ous desk­tops.

What’s a Dis­play Man­ager?

In the “good” old days, when all CPUs were 32-bit and all dis­tros fit­ted on a sin­gle CD, you would boot to a text con­sole, and log in as your user. Then, if you wanted one of those new­fan­gled GUI things, you would type startx . Some peo­ple still work that way, but the nor­mal ap­proach is to use a dis­play man­ager. This is run as a service, just like any other, but only from the GUI run­level.

The dis­play man­ager is the pro­gram that opens the graph­i­cal lo­gin screen, al­though it keeps run­ning as a service af­ter you’ve logged in, ready to han­dle the next lo­gin re­quest. The are a num­ber of dis­play man­agers in com­mon use, in­clud­ing gdm, lightdm and sddm. Most en­able some con­fig­u­ra­tion, such as changing the ap­pear­ance of the lo­gin screen, but since all you nor­mally want to do is type in your lo­gin de­tails, time spent on this could prob­a­bly be used more ef­fec­tively else­where. If you’re the only user of a com­puter, you can con­fig­ure most dis­play man­agers to au­to­mat­i­cally lo­gin a spec­i­fied user when they start. But think about the se­cu­rity im­pli­ca­tions when you do this. Un­less you have an en­crypted hard drive that re­quires a pass­word, any­one turn­ing on the com­puter will be logged in as you with no au­then­ti­ca­tion.

Desk­top startup

We’re nearly there. The boot­loader has loaded the ker­nel, the ker­nel has run init and the service man­ager has all your back­ground ser­vices run­ning. You have logged it as the dis­play man­ager screen, so what else is there to do? The dis­play man­ager now starts an X ses­sion and loads the Desk­top En­vi­ron­ment. You may think this is the sim­ple part, but it can get quite com­pli­cated here as each desk­top en­vi­ron­ment has its own way of do­ing this. The DE will load the wall­pa­per, usu­ally a panel and a menu or two and of­ten some wid­gets. What it loads and how you con­fig­ure it de­pends en­tirely on the desk­top you use. There are some stan­dard mech­a­nisms spec­i­fied by www.freedesk­, but the var­i­ous desk­tops are more in­clined to treat th­ese as gen­tle hints rather than ac­tual stan­dards.

Your desk­top en­vi­ron­ment’s doc­u­men­ta­tion will have more in­for­ma­tion on this, or you could rum­mage through the set­tings pro­grams to find what you want. As well as the ob­vi­ous things like desk­top wall­pa­per and win­dow dec­o­ra­tion styles, you can usu­ally set up cus­tom key­board short­cuts, add wid­gets or icons to the desk­top and have spe­cific pro­grams start up au­to­mat­i­cally when the desk­top loads. There may also be ex­tra ser­vices started with the desk­top. The ser­vices we looked at ear­lier on are started by root and avail­able to the whole sys­tem, but there may also be ser­vices started for a user. A good ex­am­ple of this is pulseau­dio, which is gen­er­ally not run as root and there­fore starts up with the desk­top, run by the logged in user.

That’s it! You’re logged in and ready to use your com­puter. More im­por­tantly, we hope you now have a bet­ter un­der­stand­ing of what just hap­pened.

Shut­ting down

We’ve looked at the boot process in some de­tail, but what hap­pens when you shut­down or re­boot the com­puter? Ba­si­cally, the OS re­traces it steps. First thing is no new lo­gins are al­lowed, then the desk­top closes open ap­pli­ca­tions and shuts down and user ser­vices be­fore ex­it­ing. Then the service man­ager stops the var­i­ous run­ning ser­vices, largely in the re­verse or­der, so shut­ting down the dis­play man­ager first to un­mount­ing filesys­tems last.

Some ini­tial ramdisks keep their scripts run­ning in the back­ground so when init ex­its, they can undo what­ever they started, then the ker­nel un­loads and the screen goes blank. As with the boot process, do­ing this with­out a splash screen will let you see the progress of the shut­down, which can be use­ful if it seems to take longer than it should. If you can see what is caus­ing the de­lay, you may be able to fix it, but at least you’ll know why it’s hap­pen­ing – splash screens and progress indicators are only user friendly when there’s progress.

That was com­pli­cated, right? Linux is about learn­ing and em­pow­er­ing the user, mod­ern dis­tros are su­per-easy to use but ev­ery­thing is laid bare for you to play with and ex­per­i­ment with. So have fun, en­joy Linux and keep learn­ing!

A GRUB boot menu, this one is themed but many are just plain white text on black. A boot­loader is nec­es­sary on older, pre-UEFI, sys­tems

Here’s tThe rEFInd boot man­ager screen for UEFI sys­tems. In many cases this will de­tect your OSes with no con­fig­u­ra­tion at all.

The /etc/fstab file de­fines the filesys­tems to be mounted and where. This one is overkill, but it does make for a bet­ter screen­shot than the de­fault fstab.

This is what you get when you dis­able the splash screen. The green OKs scrolling rapidly by are a com­fort­ing sight.

The dis­play man­ager is your gate­way to the desk­top. This one has a nice theme, but all you need is some­where to type your pass­word, then it’s gone!

Com­par­ing a tra­di­tion init script (left) with a sys­temd unit file. The win­dow con­tains about half of the init script.

The dmesg com­mand shows the mes­sages fro the ker­nel’s early startup. Here the hard disks, net­work card and USB ports have been set up.

At last! The boot process is al­most com­plete and we’re pre­sented with a graph­i­cal desk­top.

Newspapers in English

Newspapers from Australia

© PressReader. All rights reserved.