Gain in-depth knowledge for passing your exam with Exam-Labs 101-500: LPIC-1 Exam 101 certification video training course. The most trusted and reliable name for studying and passing with VCE files which include LPI 101-500 practice test questions and answers, study guide and exam practice test questions. Unlike any other 101-500: LPIC-1 Exam 101 video training course for your certification exam.

101.1 Determine and configure hardware settings

1. Virtual filesystems

We'll start with the first topic. Topic 101: System Architecture. Subitem 101: Determine and configure hardware settings. We start with the you-name command. Let's take a look at the main page. A man page is a small help page for a command. Almost every command has a man page with all the information you need. We simply enter your name so you can see the main page of the command line. So here you can see your name and print system information. That's actually all we need to know to see what your name is doing. A little further down, there are various options, of which I spoke briefly in the first video. So you can always give options to a command to get other information or get more information, and so on. With the queue, we can leave the main page again. For example, we are typing your name with the option R, which stands for release, and it shows us the current kernel version. In this case, it is the kernel version five (400:42) generic. This kernel version is currently installed, and it is in use now. Maybe a quick pen What exactly is the kernel? The kernel is the core of the operating system. The kernel is responsible for memory management, process management, multitasking input and output operations, and everything that is somehow related to the hardware. The kernel has a modular structure and is a monolithic kernel, in addition to the functions I just mentioned. The kernel, of course, also has drivers for the hardware components. And these drivers are outsourced to individual, so-called modules. The special thing is that these modules can be loaded into the kernel or unloaded at runtime. So you can only run the modules you need yourself. Modules that are not required are simply removed from the kernel, which of course can save a lot of resources. Let's type, for example, your name with the option M standing for machine. The system architecture is displayed here. You name it; it shows us all the information you can output. We have, for example, here on the far left the kernel name of the computer and next to it the host name. Then the kernel version follows, which we have already viewed with your name up. And here we have the time at which the Colonel was created. Here we have the processor type, the hardware platform, and the architecture of the processor. In most cases, they are all the same. Finally, we have the operating system. You can also display individual things about the CPU with the following command: ls CPU, and here you can find a few details about the CPU used, which is installed here. I have here, for example, an intercourse CPU with a 1.6 CPU, so it's one number, and so on. So I think it is really important for the EP exam. So you just need to know that you can get some detailed CPU information with the command lscpu. Okay, let me clear my screen. Now we come to the so-called "soil file systems" or virtual file systems. We find one of these filesystems in the props directory. We use a CD to navigate to this directory. CD stands for Change Directory. So we proceed to CD-Proc. So now we are in the pros directory, and with LS, we can list the content. This directory is a virtual directory that is only available during runtime. It represents the processes that are currently running. The corresponding files and directories are not stored on the hard disk, but only in the working memory. This directory will be deleted as soon as the system is shut down. Most of the settings are, of course, only visible, and there is little point in changing them since the changes made are deleted again as soon as the system has been restarted. What do we see here? In this directory we see various subdirectories, all of which only have certain numbers as names. These numbers, so called "PIDS," represent process IDs. Each process that is started has its own process ID. So these are all certain processes that are currently running. There are certain commands that can be used to find out what a particular ID now stands for. But that's the topic of a later video. We also have various files, from which we can also find some information. Let's take a look at, for example, the file modules. We can look at files with the command cat. Let's take a look at the main page first. Cat will concatenate files and print on the standard output. In the past, CAT was mainly used to link files together, but you can also use it to simply output files. And this is actually standard today, with Q We leave the main page again and take a look at the contents of the modules file with cat modules. And here we see which modules are currently loaded in the kernel. That's a whole lot, and we can't do much with it at first, but that's not the issue now. Just for information about what is in this product directory, I clear the screen again and look at the second virtual file system. That would be the Sys directory. I'm going in there with CD, and with LSI I can show what is in this directory. And yeah, it looks a little tidier than the other one, but here too, similar to the propsystem, this directory is a virtual system. Again, files and directories are not stored on the hard disk, but in the working memory. While the product directory mainly contains processes, the system directory contains information about system hardware and kernel modules. Processing information is not listed here. We might take a look at the sample file. We are going to the Maybe City module, and there are various subdirectories here. I'm changing here again for the module list. By changing two parameters, we now have a file called Sick and Force. Let's see what's inside. Cat force. The result is As you can see, there is little to do with it. But as I said, this is absolutely not important. Not for the exam, but for everyday use, because you never look in there.

2. Devices filesystem

In this video, we take a look at the device directory. The device directory is the dev directory. Dev stands for devices. We change to the directory with cddev, and let's display the content. We are seeing a lot here. Now it is not important for the test to know what exactly each individual file and directory means. Just this much TTY: these are all prefabricated consoles. We have a file for DVDs here. We have a file for CD-ROM. We have the hard disk. One is a partition on the hard drive, SD two is another partition, and so on. Then we have SR zero. SR Zero refers to the CD Rom.So these are individual files that basically reflect the device. Devices are also shown as files. In Linux, there is this term, "udef." You can see that in the overview on the LPI page. By the way, UDEF is written as follows udef stands for user space development, and it's a programme with which Linux manages the device files. UDF automatically manages the dev directory. When a hot-plug device, such as a USB stick, is plugged in, udef uses information from the file system to locate the hardware data. It reports this to the so-called Bieber system, and this creates a new device file under Death. So we don't have to lend a hand here ourselves. It all runs automatically, and you just have to know what's behind it. Perhaps a short digression on hotplug and coldplug devices LPE would like to know that too. What is the difference between hotplug and coldplug devices? A hot plug device is a hardware device that can be connected to the system during runtime and also be used immediately. For example, a USB stick. You insert a USB stick while the operating system is running, and you can then use it immediately. A code-plugged device is a device that can only be plugged in when the computer is switched off. That would be, for example, an ED hard drive that would have been installed separately. You can't do that during runtime. That is the difference. I mentioned earlier that when a hot plug device is plugged in, udef gets the information from this directory and reports this to the Debus system. What is the DEBUS system? DEBUS is a programme that sends messages back and forth between different applications and informs them about events. Udef uses, for example, Debuff to inform the user and the system when new hardware is connected. If a USB stick is inverted and the user receives a message on the screen that a USB stick has just been inserted and it is now available, then this message comes from the Diva system. Okay, that was a little digression into the device files. As I said, we don't have to know more for the exam, so I will see you in the next video.

3. Kernel modules

Okay, we come to the Pen Ultimate video from Area 101, determining and configuring hardware settings. I showed you that various data can be read out in the product directory. So we take a look at this again CD Pros and I discussed this with the example of cat modules, where you can see which modules the colonel has just loaded. And yeah, that looks a little bit confusing. We can't do anything with these zeros and so on. Yeah, that's a little bit ugly. Fortunately, there are some commands in Linux that show us the whole thing more clearly. If we now want to display the modules that the kernel has currently loaded, we choose the command LS mod, which stands for List modules. We examine the main page, man LS mod. LS Mod shows the status of modules in the Linux kernel. We can exit this man page using queue. Let me clear the screen again with the command clear. And now we enter the command: LS mod. And now we see it a little bit clearer. We get a tabular form of the information. Displayed on the left are the individual modules and the module names. In the middle is the size of the module in bytes. And here on the right side we can seehow many other modules this module is used by. Often, it is also behind it, indicating which modules exactly are working together. For example, in this case, we can see TTM with the module TTM. There are two other modules here, two other modules that are working with TTM together, and the module names are VMWGFX. We now have the option of asking if we would like to know what a particular module is or would like some more information about it. Then there is the mod info command. We look at the main page with mod info, and we can use modules. Now maybe we choose this one LP, and we will then see further information on this module. Here for example, under which pathyou can find this module. The module is only displayed as LP. Above, we can see only LP. However, in more detail for the module's detailed information, we can see that the name is LPO. Ko stands for Kernel Object. Sometimes only "O" is displayed for objects. So these are the extensions for the kernel modules. Here we can see which licence the module is under, what the module depends on, and some additional information. If we now, for example, want to display the author of a module, then we use mod info with the option information about a mod, such as the mod user name DRM And now we can see who wrote this module. There are four of them. Gareth Huge lee delgas Jose Francesca John Smells, author, has written the Modular GRMA. Another important option is the D option. D stands for description. With this, we can display the description of a module, which hopefully contains what this module does exactly. For example, Modin for DDRM. With the option, we can now see the description DRM sharedcore routines, DRM bridge infrastructure, and DRM panel infrastructure whatinfo. L would show us which licence this module was placed under. And we can see this module is placed under the GPL and has additional rights. As mentioned earlier, these modules, which arecurrently all running, as a reminder, wecan display them with LS mod. We can load and unload these modules during runtime. It is, of course, important that we make sure that we do not remove any modules from the kernel that the system urgently needs in order to function at all. The video module probably has something to do with the graphics, so I wouldn't necessarily want to unload it. I wouldn't necessarily want tounload the keyboard module either. At this point, we load the IP tables module. Iptables is the Linux firewall. The module is running, but the firewall is not configured at all, at least for me. Therefore, this module is not important at this point. to be able to unload or load a module. There is the command "mod probe." We look at the main page, adding and removing modules from the Linux kernel. So let's unload the IP tables module with mod probe, with the option "R" for remove and then the module name. It has IP tables. Okay, and here we get an error message that informs us about missing permissions. I am currently registered as a normal user, and fortunately a normal user cannot simply remove any modules from the kernel. To do this I would now have to login as root, or I use the pseudo command. Pseudo means that as a normal user, I receive administration rights for a command in order to be able to execute this command. And it's only for one command, so I will take the same command, but with Zoodo at the beginning. Zudo mods probe R to remove IP tables. Now I'm asked for the password, which of course I enter now, and we see that there is no confirmation or error message. With Linux, it is usually the case that if no message appears, then everything has worked correctly. in most cases. If there had been an error, we would have shown an error message again, as we have just done before. Okay, so I look again, LS not, and I'm searching for the module IP tables. I can't find it anymore. To be on the safe side, I look explicitly for IP tables. I do that with LS not.Pipe grab will appear later, but only in a limited form. The pipe symbol indicates that the result of LS mod is forwarded to the next command. The next command is grep. Grep means filtering these results for IP tables. In this case, and with LS not, we tell thesystem that it should first show us all that itshould first show us all modules and then send theresults with pipe to the next command. The next command is Grep, and Grep ensures that only the IP tables are displayed if available, so the command has no result. Iptables does not exist. So we have successfully loaded IP tables from the kernel. If we want to reload Iptables into the kernel, we use the mod probe command, this time without an option. So we're using pseudo-mode IP tables. Again, no message appears, so that command should have worked. Let's check it again and see whether IP Tablescan can now be found in the loaded modules again. So we use the same command as before LSmod, and now IP tables are shown to us. We are also shown the X tables that Iptables use. So we have successfully reloaded this module into the kernel. Before Modprobe, there were two commands that were used to load and unload modules. These are no longer used today, and they are no longer included in the requirements for the API Exam. However, I would like to mention them briefly at this point. You never know how the RM mod command will be used to unload modules. RM mod stands for "Remove module." Let's look at the main page. simple programme to remove a module from the Linux kernel. With RM mod, you could unload the corresponding module, and with the command Insert, which stands for insert module, you could load a module into the kernel in Smart. simple programme to insert a module in the Linux kernel. But as I said, it is no longer listed at LPI. I suppose you don't need to know that for the exam, but of course you can still take a look. It is important to know that with RM mod, as with MOD Probe, with the option R, you do not specify a path for unloading because mod looks for the path in which the module file is located using the command you name r. Yeah, we talked about this in a previous video. With your name, the current version is displayed, and Linux is able to use it to find the appropriate path itself. Within Smart, on the other hand, you couldn't just enter the module and it would be loaded, but you would have to enter the entire path to the module. For example, in the Smart Lip module now, the kernel version is kernel. Then, for example, input mouse mouse ko ko as a reminder. Reminder stands for "kernel object." And yeah, that's only an example; you wouldn't do this now, but this is how you would load a module into the kernel with the In Smart command. It is, of course, much easier with modProbe, where no path specification is necessary. which explains why InSmart is actually no longer used these days.

4. Display hardware

Two commands are still on our list in this last video. On the one hand, there would be the command lspci. As always. Let's take a look at the main page. PCI lists. all PCI devices. So we simply enter, and the system displays a list of all PCI devices on my system. There are a few options here. I think the most important ones are with the option v, called "both." Both are very common with a large number of commands, but not with everyone. Both show us a more detailed view of the outcome. And when we compare that, we see very clearly that we get significantly more information with the V option than without. So this is without the V option and now follows the V option. Here we have much more information than before this one.With this command, you can even enter it both twice or three times, which makes it even more detailed. We can use Lspcivaled than with RCI only one V. And then we have the possibility to use it with three Vs. and that would be the most detailed view there is. However, this is a special feature of lspci, and it does not apply to other commands. Another interesting option is the K option, lspci. the PCI devices, including the modules they use. We can see it here. Kernel driver in use is this one, and that is because of the K option. As the last command on the list, we have the command lsusb. We take a look at the main page, "list USB Devices," so lspci is for listing PCI devices. LSUSB is for listing USB devices. We just entered LS USB again and have buses one and two. And we have device one on bus one anddevice two devices are attached to bus and onedevice is attached to bus zero zero one. With the appropriate options, we can display the output in more detail here too. The view option works again. lsusb four. It stands for both. And here we have detailed information regarding buses and devices. instead of V. You can also choose the long form for both, but then you have to use two times the minus. So lsusb for both, and the result is the same as lsusb. Okay? For example, we can also specify that only the devices on bus two should be displayed. We can now specify that only the devices or a single special device be shown or displayed. You can choose the option S, or maybe LS USB. And we only want to show bus two. So it is, and the device has two. The result is now only bus two and device two. We can use Bus Two and Device One. Then that is shown. And if you just use bus two, then it only shows us bus two and device two. Or another possibility is that we can only display USB devices from a certain manufacturer. We see that the individual devices are displayed with an ID. The ID in front of the column is the so-called vendor ID. This one, this one, this one These are vendor IDs. And this is unique for every manufacturer. After the colon, we find the product ID. This one, this one. So we could now enter LS USB with the option D. And maybe we'll use this manufacturer ID 26 B. And the colon is important here. And now it only shows us the outcome for the manufacturer. With this manufacturer ID, you can, of course, combine the options. For example, we can type in LS USB with the option V for detailed information. And we only want to see the details of bus one, device one. Then here are the details: bus 2, device 1. And here's some more information. Another interesting option is the T option. Lsusbt stands for tree and shows us a tree view. The output is, of course, a bit poor in the system. We must not forget that we are using a virtual system here. on a real system with eight USB slots. The view would, of course, be a bit more meaningful. But I think what I want to show you here is bus two, port one with device one, and device two. And then we have to take a tree view. Okay, that's it for the first topping. We'll see you in the next Then it's about starting the system.

101.2 Boot the system

1. Boot process - part 1

This video is the first about the boot process. How does this boot process work? The computer is turned on, as is the BIOS or UEFA. Recently, some simple hardware tests For example, whether there is a hard disc at all, how it is addressed, and so on. The buyer then looks in the master boot record (MBR, for short), which is in the first sector of the hard disk, to see if it can find a so-called bootloader. A bootloader, formerly also called a bootstrap loader, is a programme that is responsible for starting the Linux kernel. There are different bootloaders. The most common and up-to-date should be Grab Two, but Grub Legacy or Grub One can also be used. Maybe you can call it Grub One too. I think it's still very widespread today. By the way, Grub stands for "grand unified bootloader." Lilo is another well-known bootloader that is no longer widely used today. LILO stands for Linux loader. After the bootloader has started the kernel, it starts the so-called initial RAM disk, or initrd for short. Init RD is a temporary file system that is only used during the boot process. Init Rd creates a file system image on a reserved area of main memory that only contains files and directories needed for the system to start. Init Road then starts the init process. The Init process is the first process that is started on a Linux system, and therefore it always has Process ID 1, or PID 1, for short, init itself. Then it starts all other programs, and as soon as it has been started, the initial run disc is no longer required and is therefore switched off. So if we take a look at the currently running processes on a Linux system and maybe display them in a tree view with the PS 3 command—we will talk more about it later—then we can see exactly which processes are running here. And the P options mean that we can see the process ID in brackets with the options P. Let me scroll up a little bit. In the first place, with the process ID one, we see the process SystemD. System D is the successor to INIT. We will talk about SystemD in a separate video. We have installed the current Ubuntu version, in which this version is no longer used, but System D. And accordingly, the first process that is started on the System D system is also the System D process, which is given the process ID One. As I said, we will come to a detailed explanation of what System D and System are in a moment. At this point, I would install an older Ubuntu with the help of LXC containers. So I have LXC installed on my system, and I want to launch an Ubuntu 14. Since the Linux container, or LXE for short, does not appear in the Epic exam, I will not go into it in much detail here I have just downloaded the Ubuntu 14 image here and started it as a container, which is much faster than I had to create a new virtual machine. Now, okay, now I'm locked in an Ubuntu 14 container. And now I wanted to use the command pstree with the option P again, but I saw that my Ubuntu 14.04 did not know this command command not found.I tried to install it, but it didn't work either. Okay, so we have to choose another command, which is PS with the options e and F. With these options, we can see the processes that are running at the moment but, unfortunately, not in a tree view. But I think that helps too. We can see here that blood has been in it. As previously stated, it has always been the PID. And here you can see it; processor D is in it. Okay, so I am going straight out of here, so I'm back to my current Ubuntu. Perhaps you have already seen it when you boot a Linux system. If you have not just set it so that you only see a background image but also what the system does when booting, you can see that many tests are carried out. There will be hardware that is recognised and started, and so on. However, nobody can read along that quickly. Maybe you could read the word "error" somewhere when booting up, but the startup process is far too fast to be able to read what exactly it was about. In this case, we can, for example, use the command to send a message. We take a look at the main page mandmesg Dmesg prints or controls the kernel ring buffer. DMSG is used to examine or control the kernel ring buffer. The default action is to display all messages from the kernel ring buffer. D messages read out the so-called kernel ring buffer. The kernel ring buffer stores kernel messages as well as items that are locked during boot. The kernel ring buffer is 16,392 bytes by default. When it's full, the oldest messages just drop out. I run Dmsg, and we see a lot of information here that we can look at here, so that we can then understand again what actually happened during the boot. And now, for example, if you want to search for an error or a warning, you can pass the message to Grep. We will talk about that later again, but we've already done that. In another case, we can use the message followed by the grip error. For example, the I option here means that no distinction is made between upper and lower case. Now only the locks on which the system reported an error are displayed. So you can now understand exactly where errors have occurred. Another option is to use the journalCTL command to query the system via Djornal. If called without parameters, it will show the full contents of the genre, starting with the oldest entry collected genreCTL shows all system messages on a system. Therefore, of course, this only works with current Linux distributions that also use Systemd. I just briefly mentioned that system as the successor to this unit. As a result, this Vinit is available in current versions. Everything that happens in this system is simply locked by CTL. The output is made here, page by page. Through space. We go one picture further, and so we can go through the pages until the very bottom. You can leave this with queue. If you look closely, we see that there are messages from the kernel, the network manager, and so on. Let me show this. Here we have messages from accession DeepestDemon, system Dartkit, and so on. Here is a kernel message. And if you just want to see the kernel messages, which are the most important ones in most cases, then you can use genre CTL with a key option. In this case, of course, KS K stands for kernel, so that only the messages from the kernel are displayed here and here. As you see, we have only the kernel messages.

Pay a fraction of the cost to study with Exam-Labs 101-500: LPIC-1 Exam 101 certification video training course. Passing the certification exams have never been easier. With the complete self-paced exam prep solution including 101-500: LPIC-1 Exam 101 certification video training course, practice test questions and answers, exam practice test questions and study guide, you have nothing to worry about for your next certification exam.

Hide