All right, So our next part of module 101 is booting the system.
So we'll look at some of the options that you have for telling the system how to boot and how you which currently would like to use and things of that nature.
You also wouldn't be expected to know what the boot sequence entails.
There will definitely be questions on the exam asking about this.
commands, which are more the legacy
way of doing things compared to system D, which is the new way of doing things
also touch on the upstart utility.
Well, look at boot events and various log files and we see it. We've got some commands here
and some files and things that will be touching on as we get through this chapter.
Now Lennox supports grub, which is the grand unified
and it's kind of a nice little acronym. And what this means is that we've got the ability to have multiple curdles
available for booting on a particular system.
This is very useful because sometimes
as administrator, you're going to need to make changes to the colonel,
and usually when that happens, what we want to do is
and also retained the current colonel
this way if we if we boot up in the new colonel and there's a problem, something's not right.
We could always reboot from the previous Colonel and go back and make some changes and try again.
So this grub make unfit command is just a sample here showing. Once I make some changes to the
the default settings,
I can generate a new CONFIG file
and have that new colonel show up in my boot menu, which will see here in just a little bit.
Now, when Santos gets gets installed
first, the system will do the
inspection of the BIOS.
We'll talk a little bit about the power on self test,
and if you were unsure about the compatibility of your system, you can always go to the sent US hardware compatibility site.
and this is very handy to be able thio
to determine if I want to use something like a graphics card. Well, which ones can I use?
That's not showing much detail there,
but it's trying to tell me of all the different versions of devices.
How do I determine which ones are compatible with my intended?
And I can also specify how I want the colonel to be accessible. If you remember, when we ran the
one of the other commands, we saw some of the Colonel parameters,
like specifying where the route.
Oops, sorry about that, where the route
partition is located, or even specifying that it's read only.
So if my boot partition is read only that's a good thing, because I blew the operating system from Avery. The only data
I don't have a chance to write to that partition. So it's less chance of any security problems or any data corruption.
And I have various parameters, which I can specify for the colonel
to suit my various needs. That the quiet option is nice because, as it says,
I won't see any messages that are not considered critical, which
minimizes the amount of
information I see on the screen or in my log files.
I can also define the buffer size for the log the colonel log.
This might be important as far as limiting the buffer size in order to prevent a system from running out of space if it was built with without a lot of consideration for growth.
In the last section. We also saw Mod probe
being able to see which kernel modules are currently loaded and being able to
add and remove those as needed.
And if I system crashes
and the colonel dumps its contents to contents of memory to disk, I want to be able to specify where that crash colonel data should be located.
So if I go back to my
when the first things that want to do is go to the etc default directory,
you'll notice I have a file here for grub.
Now that's a default is a, um,
just what it sounds like. The etc. Directory in general is for configuration files,
but I can define a default
config file for various different commands
like the grub configuration are adding a user as we see.
But let's look at some of these parameters really quick. First, we have our time out.
This is the amount of time in seconds that
the boot menu will give you to make a choice. Either you wait the five seconds in the boots automatically, or within five seconds. You interrupt the boot
by clicking on the screen and moving one of the arrow keys to move the cursor up and down. We'll see that here in a little bit.
I can also define where my output of my
terminal goes to the consoles and default settings. That's pretty typical.
So I can tell it that underneath my
my route volume, I'm gonna configure
an area for saving the memory when the system crashes.
So a couple settings there to look at
now what I just did here was a cat command on Prak. Prak slashed me in line.
This shows me what the command line looks like
to generate this. This colonel, I can see that my my route partition is attached to slash dev slash mapper Santos route.
and I can see that my crash colonel will automatically be generated. That's what the auto setting means in this case
tells me that it's it's a quiet setting, has been able to, so I don't see anything from the Colonel that's that's non critical,
and it's a little bit hard to tell because the year make the monitor full screen
and also specifies my language variable showing me that I'm using English language
in the U. T. Have eight character of coding format.
So these are nice little details about my
curls that are only visible once I've booted up.
And usually when you're in my experience, when I'm changing the colonel's because you're trying to do something to
modify the way the system allocates resources, maybe you're tweaking memory settings or tweaking some of your storage settings, trying to get better performance. Overall,
relate to how memory is used,
so a RAM desk is just what it sounds like. It's a portion of disk
which can be used like memory when the system boots
gets loaded by the grand unified boot loader grub,
and it runs has been in it.
And the scripts that are in this directory
we'll look for very service is that that are required to start up the system, start of the various components
and each each script in this in this directory will have some purpose with assistant things like starting networking, starting the the connection of the drivers to my hardware devices and so on.
All this is done in order to get ready to mount the root file system, which is known as slash
again. These things in blue are usually
config files or paths or commands.
Now the the root file system has to be monitoring boot because this is where
all of my subsequent file systems will use as a reference point for their mount points.
And, of course, we have thio get our operating system files from from this area,
the drivers that the operating system needs to talk to the hardware things such as *** controllers, host bus adapters, HBs scuzzy devices.
The operating system can't talk to those device to those hardware devices until the driver's loaded.
The driver is an intermediary software that
that allows the opera system to send commands
to a hard disk or to a video display adapter or network hard
and tell it to do something or ask it for information.
So when the system goes through its boot process,
one of the first things that happens is the power on self test.
We're all familiar with this when you turn out a computer, especially
PC based systems you hear. Beep typically,
and you get a bunch of diagnostic information on the screen.
And what this is intended to do is to do a quick check of all the different required hardware components to make sure that they're all working.
I need to display on the keyboard and probably need a mouse.
I need storage. I need to have access to Maya bios,
and that's what the power on self test does. It doesn't quick check of all those things.
Initialize is all the hardware to get ready for the first stage of the boot.
So the first age for grub is loaded from the master boot record. That's what the M B. R stands for.
This will get all the drivers for the file system
loaded into memory so that that
they could be ready for the Mount Point to actually take place.
the first I first stage of grub also gets ready to load the second stage.
Now the second stage of grub.
Well, actually, look at the config file
and that that command line that we saw that that's what actually gets inspected to determine
which colonel is going to be loaded and some of the parameters, like read only or the quiet parameter to limit non critical messages.
The Ram disk. It's loaded. Then what this means is that
it has to be still loaded from the disk. So we need to ram. Just have some temporary storage in the physical memory of the system in order to get ready for the actual colonel to be initialized
When the colonel's brought from the disc. It's in a compressed format, so it has to be decompressed.
And then whatever command line arguments we saw that
previous example would now be,
applied to that colonel being loaded into memory. The read only feature the quiet feature and so on.
But the colonel loads the operating system takes the device drivers,
and we'll initialize them so that they can run
and go talk to all the bits of hardware, your video display adapter, network, hard storage adapter and so on.
So in it ram a fast. This is initializing the Ram file system.
This this portion that's loaded from the disc will now
take care of the subsequent tasks of getting kernel modules that we saw when we did that mind probe Command.
All those will now be loaded. All the ones that are configured to be loaded anyway
will be loaded into memory. And then finally, the root file system gets mounted.
system will continue its boot process.
So let's have a quick look.
Well, look in the s band director. There's quite a few things here we'll talk about
with these files are
what some of these files are later.
But we noticed that the unit
program actually has a link
to system deep, which will also compare to
the previous version of more the legacy way of doing things
for for Linux systems, her UNIX systems.
So, in it again, uh,
if you were running system five
that a nicked process will now go load all the other,
components of the operating system. So it really is the first main
process or program that runs when the system goes to the boot process.
If we compare the system five way of doing things with
system D, which is the newer way we've got some nice comparisons to see how these things translate back and forth.
So if you're more familiar with more legacy unit systems Olynyk systems, you might recognize a service command.
I can start, stop and restart and reload a service.
Or, if I'm running in a more modern system, which is System D based
I run system control system. C T l.
Very similarly just I can start, stop and reload same way
so I could run a status command in both cases, See if the service is running
underneath the RC dot de anata D folder on wreath, etc.
We can see it all. The system five
system D environment like like Santos is
I can run this system control with student files and say, Show me all of the service's that are available on this system, which I can start and stop with,
uh, the script commands.
So I could reference
service underneath this folder and tell it to start and stop. Very similar to what? Using the service command of the System Control Command.
service is going to be started and stopped automatically when the system Boots
stopping on a Mac was coming up and under understood. No brainer kind of default, sonny,
but only certain service's are going to be started automatically. I want to be very selective about that, so I don't start more service is that I need, and we'll talk about that a little bit more detail when we get him to the security considerations and other sections.
I can also determine which run levels the service will be operational.
Certain service's might only be needed at one level three, for instance, and I don't need the run level four
so you can configure that in order to
Evan. Ah, more customized
approach to how your system is configured and what it does when it boots
As it says here, this is a replacement for in it, and it was considered a little bit too inflexible. Another reason why System D was
and so the etc innit Tab and the Nick directory underneath at sea probably doesn't have much information in it for a modern system that we can go take a quick look.
So there's my new tab,
and as it says, this is no longer used when you're have system be available.
But some of these legacy files still exist,
and you should know a little bit about it in case you're in a situation where,
in case you're in a situation where you're working on older system and you want to be able to
now when the system boots.
One of the things that we probably would be considering is,
where can we find different details about what happened during that boot?
We've already looked at a D message.
This is the things that would go to the console. These air current related messages,
and we'll also look at the slash bar slash long boot log and our long messages
generally for Linux systems. Most of your logs are contained under slash bar slash Log,
and that's that's a pretty typical convention
a little bit of ease for finding an information that your event that you're interested.
So if I go too far a log,
do a long listing here, we can see there's quite a few items.
This is where all the logs are contained for various things they're going out of the system.
but I will also want to look at the boot log
so boot Long doesn't have anything in it. That's okay
if I look at messages, which is kind of a general purpose. Catchall
messages has quite a bit of data,
so I'm going through several screens here. You can see there's all kinds of details about boot information
and maybe I'm interested in.
Maybe I'm interested in
trying to find something
specific so I can count the messages file. And I can pipe that to grab Dash I and look for the word error.
Clear the screen, Run that again.
So I got a few lines with some errors. Not true, buddy. Uh,
look for the word fail
Quite a few of those
Arabia. I'm interested in something more specific, like a
events that happened in a particular time, like 14. 39.
So you can see how easy it is to use the grub command.
All the items that get matched return and they show up in red.
Now, these messages that we see related to boot they don't look like much at this point because we're not troubleshooting. We're not looking for anything in particular. We're just trying to find where we were. We might look.
And as I've written here,
generally speaking, things that indicate failure are often more interesting than things that indicate success.
So these are some of the commands that we've investigated for this section.
Make sure you do spend a little bit of time practicing with these
as the end of the boudin system. Modules are the section with this module.
And then for our last bit, we're going to
who targets and shut down the system
I have seen in the next section.