Showing posts with label 201-450 LPIC-2. Show all posts
Showing posts with label 201-450 LPIC-2. Show all posts

Tuesday, 9 July 2024

Battle of the Certifications: LPIC-1 or LPIC-2 for Your IT Career?

Battle of the Certifications: LPIC-1 or LPIC-2 for Your IT Career?

In the ever-evolving world of Information Technology, certifications have become a crucial metric for showcasing skills and advancing careers. Among the myriad of options available, the Linux Professional Institute Certifications (LPIC) stand out, particularly the LPIC-1 and LPIC-2. This article delves into the nuances of these certifications, providing a comprehensive comparison to help you decide which certification aligns best with your career aspirations.

Understanding LPIC-1 and LPIC-2


What is LPIC-1?

LPIC-1 is the entry-level certification offered by the Linux Professional Institute (LPI). It is designed to verify the candidate's ability to perform maintenance tasks on the command line, install and configure a computer running Linux, and configure basic networking.

Key Objectives of LPIC-1:

  • System Architecture
  • Linux Installation and Package Management
  • GNU and Unix Commands
  • Devices, Linux Filesystems, Filesystem Hierarchy Standard

Why Choose LPIC-1?

  • Foundation Level: Perfect for beginners or those new to Linux.
  • Core Skills: Covers essential Linux skills and commands.
  • Market Demand: Recognized by employers globally, boosting entry-level job prospects.

What is LPIC-2?

LPIC-2 is the advanced level certification that targets professionals who are already familiar with the basics of Linux and wish to deepen their knowledge and skills. This certification focuses on the administration of small to medium-sized mixed networks.

Key Objectives of LPIC-2:

  • Capacity Planning
  • Linux Kernel
  • System Startup
  • Filesystem and Devices
  • Advanced Storage Device Administration
  • Network Configuration
  • System Maintenance

Why Choose LPIC-2?

  • Advanced Skills: Ideal for experienced professionals looking to specialize.
  • Leadership Roles: Opens doors to higher-level positions in IT.
  • Broad Scope: Covers advanced networking, security, and troubleshooting.

Comparative Analysis: LPIC-1 vs. LPIC-2


Skill Level and Prerequisites

LPIC-1 is designed for beginners. It requires no prior certification and serves as a stepping stone into the world of Linux administration.

LPIC-2, however, demands that candidates first obtain LPIC-1 certification. This ensures that they possess a solid foundational understanding of Linux before tackling more complex concepts.

Curriculum and Content Depth

LPIC-1:

  • Focuses on basic system administration.
  • Includes topics like file management, scripting, and basic networking.
  • Emphasizes understanding and using command-line tools.

LPIC-2:

  • Delves deeper into system and network administration.
  • Covers advanced topics such as kernel configuration, system recovery, and network troubleshooting.
  • Requires a solid grasp of Linux fundamentals, as it builds on the concepts learned in LPIC-1.

Career Impact

LPIC-1:

  • Ideal for entry-level positions such as Linux Administrator, Junior System Administrator, or IT Support Specialist.
  • Provides a strong foundation for further certifications and specializations.

LPIC-2:

  • Suitable for more advanced roles like Linux Engineer, Network Administrator, or Senior System Administrator.
  • Enhances prospects for leadership and specialized positions within the IT industry.

Exam Structure

LPIC-1:

  • Consists of two exams: 101-500 and 102-500.
  • Each exam covers specific topics within the overall curriculum.
  • Exam format includes multiple-choice and fill-in-the-blank questions.

LPIC-2:

  • Also consists of two exams: 201-450 and 202-450.
  • These exams are more challenging and require a deeper understanding of Linux systems.
  • Similar format to LPIC-1 but with more complex scenarios.

Deciding Between LPIC-1 and LPIC-2


For Beginners and New IT Professionals

If you are new to Linux or the IT field in general, LPIC-1 is the best starting point. It provides the essential knowledge and skills needed to understand and operate Linux systems. This certification is widely recognized and can significantly enhance your resume, making you a more attractive candidate for entry-level IT positions.

For Experienced IT Professionals

If you already possess a good understanding of Linux and have some hands-on experience, pursuing LPIC-2 can be highly beneficial. This certification not only validates your advanced skills but also prepares you for more complex and demanding roles in system and network administration.

For Career Advancement

Both certifications can serve as valuable milestones in your IT career. However, the choice depends on your current skill level and career goals. LPIC-1 is essential for building a solid foundation, while LPIC-2 is crucial for those aiming to advance to higher positions and take on more responsibilities.

Conclusion

Choosing between LPIC-1 and LPIC-2 depends largely on where you are in your career and what your professional goals are. LPIC-1 offers a strong entry point into the Linux administration field, providing essential skills and knowledge that can open doors to a variety of IT roles. On the other hand, LPIC-2 caters to professionals looking to deepen their expertise and take on more advanced roles in the industry.

Ultimately, both certifications are valuable assets. They not only enhance your technical skills but also increase your marketability and career prospects. By understanding the differences and benefits of each certification, you can make an informed decision that aligns with your career aspirations and professional development goals.

Thursday, 28 March 2024

Mastering Cybersecurity with Linux Professional Institute LPIC-2 Certification

Mastering Cybersecurity with Linux Professional Institute LPIC-2 Certification

In the rapidly evolving landscape of cybersecurity, staying ahead of threats requires a deep understanding of systems and networks. As businesses increasingly rely on Linux-based solutions for their infrastructure, professionals equipped with Linux Professional Institute LPIC-2 certification stand out as guardians of digital assets.

Understanding the Significance of LPIC-2


Bridging the Knowledge Gap

The LPIC-2 certification fills the void between basic Linux proficiency and advanced system administration skills. It equips professionals with the expertise needed to manage small to medium-sized enterprise networks efficiently. From configuring network services to implementing security measures, LPIC-2 encompasses a comprehensive skill set crucial for safeguarding critical data.

Empowering Cybersecurity Professionals

In the realm of cybersecurity, knowledge is power. LPIC-2 certification empowers professionals to fortify Linux-based systems against cyber threats effectively. By mastering intricate concepts like encryption, authentication, and access control, certified individuals become instrumental in ensuring the integrity and confidentiality of sensitive information.

Key Competencies Covered in LPIC-2


Advanced System Administration

LPIC-2 delves deeper into system administration, covering topics such as kernel modules, filesystem management, and device management. Professionals gain proficiency in optimizing system performance, troubleshooting complex issues, and implementing robust backup strategies to mitigate risks.

Networking Configuration and Security

A solid understanding of networking principles is essential in today's interconnected world. LPIC-2 equips professionals with the skills to configure and secure network services like DNS, DHCP, and LDAP. By implementing firewall rules and intrusion detection systems, certified individuals bolster network defenses against malicious actors.

Encryption and Data Protection

In an era marked by data breaches and privacy concerns, encryption plays a pivotal role in safeguarding sensitive information. LPIC-2 candidates learn to implement encryption mechanisms using tools like GnuPG and OpenSSL, ensuring data confidentiality both at rest and in transit.

Advantages of LPIC-2 Certification


Career Advancement Opportunities

LPIC-2 certification opens doors to lucrative career opportunities in cybersecurity and system administration. Employers recognize the value of certified professionals who possess the skills needed to navigate complex Linux environments with ease. From cybersecurity analyst roles to senior system administrator positions, the certification serves as a testament to one's expertise and dedication.

Enhanced Credibility and Trust

In an industry where trust is paramount, LPIC-2 certification enhances professional credibility and instills confidence in clients and employers alike. Certified individuals demonstrate their commitment to continuous learning and upholding industry best practices, positioning themselves as trusted advisors in the realm of cybersecurity.

Conclusion

In conclusion, Linux Professional Institute LPIC-2 certification serves as a cornerstone for professionals seeking to excel in the field of cybersecurity. By mastering advanced system administration, networking, and encryption techniques, certified individuals become indispensable assets in safeguarding digital assets against evolving threats. Whether you're looking to advance your career or fortify your organization's defenses, LPIC-2 certification is a testament to your commitment to excellence in cybersecurity.

Tuesday, 28 March 2023

What is LPIC-2 Certification?

LPIC-2 Certification, LPIC-2, 201-450 LPIC-2, 202-450 LPIC-2, LPIC-2 Linux Engineer, LPIC-2 Study Guide, LPIC-2 Practice Test, LPIC-2 Certification Mock Test

Introduction


LPIC-2 is a professional certification offered by the Linux Professional Institute (LPI). It is the second level of certification offered by LPI, which is a non-profit organization dedicated to the promotion and advancement of Linux and open-source software. LPIC-2 is designed to validate the advanced technical skills required to administer Linux-based systems.

Why LPIC-2 Certification is important?


LPIC-2 Certification is important for IT professionals who work with Linux-based systems. It validates their skills and knowledge in areas such as advanced system administration, networking, and security. LPIC-2 Certification can help IT professionals stand out in a competitive job market and increase their earning potential.

LPIC-2 Exam Details


To obtain LPIC-2 Certification, candidates must pass two exams: LPIC-2 Exam 201 and LPIC-2 Exam 202. Both exams consist of 60 multiple-choice and fill-in-the-blank questions, and candidates have 90 minutes to complete each exam. The passing score for each exam is 500 out of 800 points.

LPIC-2 Exam 201 covers topics such as kernel, system startup, file system and devices, advanced storage device administration, networking configuration, system maintenance, and domain name servers.

LPIC-2 Exam 202 covers topics such as email services, web services, file sharing, network client management, system security, and troubleshooting.

Benefits of LPIC-2 Certification


LPIC-2 Certification offers several benefits to IT professionals, including:

Enhanced Career Opportunities

LPIC-2 Certification can help IT professionals stand out in a competitive job market. It demonstrates their advanced technical skills and knowledge in Linux-based systems administration, which is a valuable skillset in many industries.

Increased Earning Potential

LPIC-2 Certification can increase an IT professional's earning potential. According to the Linux Professional Institute, LPIC-2 Certification holders can earn up to 19% more than non-certified professionals in similar roles.

Recognition and Credibility

LPIC-2 Certification is recognized globally as a validation of an IT professional's advanced technical skills and knowledge in Linux-based systems administration. It provides credibility to their expertise and can help them gain recognition among peers and employers.

LPIC-2 Certification Requirements


To obtain LPIC-2 Certification, candidates must meet the following requirements:

LPIC-1 Certification

Candidates must hold LPIC-1 Certification to be eligible for LPIC-2 Certification. LPIC-1 Certification validates the fundamental skills required to administer Linux-based systems.

Passing LPIC-2 Exams

Candidates must pass both LPIC-2 Exam 201 and LPIC-2 Exam 202 to obtain LPIC-2 Certification.

Active LPIC-1 Certification

Candidates must have an active LPIC-1 Certification at the time of taking LPIC-2 Exams.

LPIC-2 Certification Renewal


LPIC-2 Certification is valid for five years from the date of issue. To renew LPIC-2 Certification, candidates must earn 60 Continuing Education Units (CEUs) within the five-year period. CEUs can be earned by attending training courses, participating in webinars, and other professional development activities.

Conclusion

LPIC-2 Certification is a valuable credential for IT professionals who work with Linux-based systems. It validates their advanced technical skills and knowledge in areas such as system administration, networking, and security. LPIC-2 Certification can help IT professionals stand out in a competitive job market, increase their earning potential, and gain recognition and credibility among peers and employers.

                      202-450: Linux Engineer - 202 (LPIC-2 202)

Tuesday, 5 April 2022

201-450: Linux Engineer

201-450, 201-450 LPIC-2, 201-450 Online Test, 201-450 Questions, 201-450 Quiz, LPIC-2 Linux Engineer

LPIC-2 is the second certification in the multi-level professional certification program of the Linux Professional Institute (LPI). The LPIC-2 will validate the candidate's ability to administer small to medium–sized mixed networks.

Current version: 4.5 (Exam codes 201-450)

Objectives: 201-450

Prerequisites: The candidate must have an active LPIC-1 certification to receive the LPIC-2 certification.

Requirements: Passing exams 201. Each 90-minute exam is 60 multiple-choice and fill-in-the-blank questions.

Validity period: 5​ years unless retaken or higher level is achieved.

Cost: Click here for exam pricing in your country.

Languages for exams available in VUE test centers: English, German, Japanese, Portuguese (Brazilian)

Languages for exams available online via OnVUE: English

To become LPIC-2 certified the candidate must be able to:

◉ perform advanced system administration, including common tasks regarding the Linux kernel, system startup and maintenance;

◉ perform advanced Management of block storage and file systems as well as advanced networking and authentication and system security, including firewall and VPN;

◉ install and configure fundamental network services, including DHCP, DNS,  SSH, Web servers, file servers using FTP, NFS and Samba, email delivery; and

◉ supervise assistants and advise management on automation and purchases.

Source: lpi.org

Thursday, 17 February 2022

Help Us Refresh the LPIC-2 Certification Objectives

We have recently started the ball rolling on our regular refresh of the objectives for LPIC-2. We're always looking for opinions and other input from our community, too. If you are interested in helping out or just observing some of the discussions, subscribe to our public mailing list here: https://list.lpi.org/mailman/listinfo/lpi-examdev

Once you have subscribed, you can read the initial thoughts from Fabian Thorns, our Director of Product Development, in the list archives here: https://list.lpi.org/mailman/private/lpi-examdev/2022-February/004137.html

Everyone is welcome and we appreciate any and all contributions (trolling excepted).

LPIC-2 is the second certification in the multi-level professional certification program of the Linux Professional Institute (LPI). The LPIC-2 will validate the candidate's ability to administer small to medium–sized mixed networks. 

LPIC-2 Certification Objectives
Current version: 4.5 (Exam codes 201-450 and 202-450)

Objectives: 201-450, 202-450

Prerequisites: The candidate must have an active LPIC-1 certification to receive the LPIC-2 certification.

Requirements: Passing exams 201 and 202. Each 90-minute exam is 60 multiple-choice and fill-in-the-blank questions.

Validity period: 5​ years unless retaken or higher level is achieved.

Cost: Click here for exam pricing in your country.

Languages for exams available in VUE test centers: English, German, Japanese, Portuguese (Brazilian)

Languages for exams available online via OnVUE: English

To become LPIC-2 certified the candidate must be able to:

◉ perform advanced system administration, including common tasks regarding the Linux kernel, system startup and maintenance;

◉ perform advanced Management of block storage and file systems as well as advanced networking and authentication and system security, including firewall and VPN;

◉ install and configure fundamental network services, including DHCP, DNS,  SSH, Web servers, file servers using FTP, NFS and Samba, email delivery; and

◉ supervise assistants and advise management on automation and purchases.

Source: lpi.org

Thursday, 6 May 2021

201-450: Linux Engineer - 201 (LPIC-2 201)

201-450: Linux Engineer - 201 (LPIC-2 201)

LPIC-2 is the second certification in the multi-level professional certification program of the Linux Professional Institute (LPI). The LPIC-2 will validate the candidate's ability to administer small to medium–sized mixed networks.

Current version: 4.5 (Exam codes 201-450)

Objectives: 201-450

Prerequisites: The candidate must have an active LPIC-1 certification to receive the LPIC-2 certification.

Requirements: Passing exams 201. Each 90-minute exam is 60 multiple-choice and fill-in-the-blank questions.

Validity period: 5​ years unless retaken or higher level is achieved.

Languages for exams available in VUE test centers: English, German, Japanese, Portuguese (Brazilian)

Languages for exams available online via OnVUE: English

To become LPIC-2 certified the candidate must be able to:

◉ perform advanced system administration, including common tasks regarding the Linux kernel, system startup and maintenance;

◉ perform advanced Management of block storage and file systems as well as advanced networking and authentication and system security, including firewall and VPN;

◉ install and configure fundamental network services, including DHCP, DNS,  SSH, Web servers, file servers using FTP, NFS and Samba, email delivery; and

◉ supervise assistants and advise management on automation and purchases.

Read More: 201-450: Linux Engineer - 201 (LPIC-2 201)

Linux Professional Institute LPIC-2 tests ability to administer small to medium–sized mixed networks.

Prerequisites: An active LPIC-1 certification.

Validity period: 5​ years unless retaken or higher level is achieved.

Source: lpi.org

Saturday, 20 February 2021

LPIC-2 Exams Can Now Be Taken Online

201-450 LPIC-2, 202-450 LPIC-2, LPIC-2 Certifications, LPI LPIC-2 Certification, LPI LPIC-2 Primer, LPIC-2 Linux Engineer, LPIC-2 Practice Test

For several months, the Linux Essentials and LPIC-1 exams from Linux Professional Institute (LPI) have been offered online through Pearson VUE’s online testing platform, OnVUE. We are proud to announce that the LPIC-2 exams, 201 and 202, are also now available. The online offerings address the latest global challenge caused by the COVID-19 pandemic, while also making tests available to candidates who live in remote areas without a nearby Pearson VUE test center.

What candidates should know

LPIC-2 exams are currently available in English. Participation in the OnVUE online tests is only possible with Windows or Macintosh computers. LPI has been in discussion with Pearson VUE to make exams available on Linux computers, because we know that many of our applicants prefer the system they have been studying and working with. We are also continuously working to expand the languages in which our exams are offered. Please return to this channel regularly to see our announcements in these areas.

Also Read:

201-450: Linux Engineer - 201 (LPIC-2 201)

202-450: Linux Engineer - 202 (LPIC-2 202)

Source: lpi.org

Saturday, 26 September 2020

LPIC 2 – Linux Engineer

LPIC 2 – Linux Engineer, LPIC2 Certification, LPI Exam Prep, LPI Learning, LPIC-2 Guides

It is the second of LPI’s multilevel professional certification. It enables the candidate to administer small to medium-sized networks. To qualify for this certification, the candidate needs to have an active LPIC -1 Certification. However, the LPIC-1 and LPIC-2 exams can be taken in any order. The validity of this certification is 5 years. This certification covers the following topics:
  1. System StartUp
  2. Linux Kernel
  3. FileSystem and Devices
  4. Capacity Planning
  5. Advanced Storage Device Administration
  6. Network Configuration & System Maintenance
  7. File Sharing and Network Client Management
  8. Domain Name Server
  9. Web and Email
  10. System Security
LPIC 2 – Linux Engineer, LPIC2 Certification, LPI Exam Prep, LPI Learning, LPIC-2 Guides

To become LPIC-2 certified the candidate must be able to:

◉ perform advanced system administration, including common tasks regarding the Linux kernel, system startup and maintenance;

◉ perform advanced Management of block storage and file systems as well as advanced networking and authentication and system security, including firewall and VPN;

◉ install and configure fundamental network services, including DHCP, DNS,  SSH, Web servers, file servers using FTP, NFS and Samba, email delivery; and

◉ supervise assistants and advise management on automation and purchases.

Read More:

Saturday, 21 March 2020

LPI Exam 201 Prep: System Startup

LPI Exam 201 Prep, LPI Tutorial and Material, LPI Learning, LPI Certifications

Prerequisites

To get the most from this post, you should already have a basic knowledge of Linux and a working Linux system on which you can practice the commands covered in this post.

System startup and boot processes


What happens when you turn a Linux computer on?

Let's break the Linux boot process into nine steps that occur in almost every Linux configuration:

1. Hardware/firmware: The BIOS or firmware system reads the master boot record on the harddisk or other boot device (for example, CD, floppy, netboot, etc.).

2. A boot loader runs. Linux systems on x86 systems typically use LILO or GRUB. Some older systems might use loadlin to boot via an intermediate DOS partition. On Power PC® systems, this might be BootX or yaboot. In general, a boot loader is a simple program that knows where to look for the Linux kernel, perhaps choosing among several versions or even selecting other operating systems on the same machine.

3. The kernel loads.

4. The root filesystem is mounted. In some cases, a temporary ramdisk image is loaded before the true root filesystem to enable special drivers or modules that might be necessary for the true root filesystem.

One we have a root filesystem in place, we are ready for initialization proper.

5. Start the process init, the parent of all other Linux processes.

6. Read the contents of /etc/inittab to configure the remaining boot steps. Of special importance is the line in /etc/inittab that controls the runlevel the system will boot to (and therefore which further steps will be taken during initialization).
Actually, everything after this point is completely controlled by the content of the file /etc/inittab. Specifically, the scripts and tools that run generally follow some conventions, but in theory you could completely change /etc/inittab to run different scripts.

One specific setting in /etc/inittab is particularly crucial. A line similar to:

id:5:initdefault:

generally occurs near the top of the file, and sets the runlevel. This runlevel controls what actions are taken in the remainder on the /etc/inittab script.

Just what happens as an /etc/inittab script is processed? And specifically, what conventional files and directories are involved in the process?

7. Runlevel-neutral system initialization. Generally there are some initialization actions that are performed regardless of runlevel. These steps are indicated in /etc/inittab with a line like:

# System initialization.
si::sysinit:/etc/rc.d/rc.sysinit

On some Linux systems (mostly Debian-based systems), you will see something more like:

si::sysinit:/etc/init.d/rcS

If the latter case, /etc/init.d/rcS is a script that simply runs each of the scripts matching /etc/rcS.d/[Ss]??*. On the other hand, if your system uses /etc/rc.d/rc.sysinit, that file contains a single long script to perform all the initialization.

8. Runlevel-specific system initialization. You may actually define as many actions as you like related to runlevel, and each action may pertain to one or more runlevels. As a rule, /etc/inittab will contain some lines like:

l0:0:wait:/etc/rc.d/rc 0
# ...
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6

In turn, the script /etc/rc.d/rc will run all the files matched by the pattern /etc/rc$1.d/[KkSs]??*. For example, on the sample system described that starts at runlevel 5, we would run (in order):

/etc/rc5.d/K15postgresql
/etc/rc5.d/S01switchprofile
/etc/rc5.d/S05harddrake
...
/etc/rc5.d/S55sshd
...
/etc/rc5.d/S99linuxconf
/etc/rc5.d/S99local

The files(s) starting with "K" or "k" are kill scripts that end processes or clean up their actions. Those starting with "S" or "s" are startup scripts that generally launch new processes or otherwise prepare the system to run at that runlevel. Most of these files will be shell scripts, and most will be links (often to files in /etc/init.d/).

Most of the time, once a Linux system is running at a runlevel, you want to log into the system as a user. To let that happen, a program called getty runs to handle the login process. A number of variations on the basic getty are used by distribution creators, such as agetty, mgetty, and mingetty. All do basically the same thing.

9. Log in at the prompt. Our good friend /etc/inittab usually launches getty programs on one or more virtual terminals and does so for several different runlevels. Those are configured with lines like:

# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6

The first number reminds us of the virtual terminal where the getty runs; the next set of numbers are the several runlevels where this will happen (for example, launching mingetty in all of the runlevels 2, 3, 4, and 5).

Next steps might involve launching additional services, logging into a graphical environment, restoring UI settings, or other more personalized details that are outside the scope of this tutorial.

Understanding runlevels

The concept of runlevel is somewhat arbitrary, or at least it is not hardcoded into a Linux kernel. Valid runlevel numbers to set with the initdefault option (or override otherwise) are 0 - 6. By convention, the following meanings are given to each number:

Listing 1. Runlevels, defined

# Default runlevel. The runlevels used by Mandrake Linux are:
#   0 - Halt (Do NOT set initdefault to this)
#   1 - Single user mode
#   2 - Multiuser, without NFS (The same as 3, if you don't have networking)
#   3 - Full multiuser mode
#   4 - Unused
#   5 - X11
#   6 - Reboot (Do NOT set initdefault to this)

This convention, as you can see, is as used in the Mandrake Linux distribution, but most distributions obey the same convention. Text-only or embedded distributions may not use some of the levels, but will still reserve those numbers.

Configuration lines in /etc/inittab

You have seen a number of /etc/inittab lines in examples, but it is worth understanding explicitly what these lines do. Each one has the format:

id:runlevels:action:process

The id field is a short abbreviation naming the configuration line (1 - 4 characters in recent versions of init; 1 - 2 in ancient ones). The runlevels is explained already. Next is the action taken by the line. Some actions are "special," such as:

ca::ctrlaltdel:/sbin/shutdown -t3 -r now

This action traps the Ctrl-Alt-Delete key sequence (regardless of runlevel). But most actions simply relate to spawning. A partial list of actions includes:

◉ respawn: The process will be restarted whenever it terminates (as with getty).

◉ wait: The process will be started once when the specified runlevel is entered, and init will wait for its termination.

◉ once: The process will be executed once when the specified runlevel is entered.

◉ boot: The process will be executed during system boot (but after sysinit). The runlevels field is ignored.

Customizing system startup and boot processes


What is a boot loader?

LPI Exam 201 Prep, LPI Tutorial and Material, LPI Learning, LPI Certifications
A few years ago, a program called LILO was pretty much universally used to boot Linux on x86 systems. The name LILO is short for "LInux LOader." Nowadays, another program called GRUB (GRand Unified Bootloader) is more popular. On non-x86 Linux systems, other boot loaders are used, but they are generally configured in the same manner as LILO or GRUB.

While there are differences in their configuration syntaxes, LILO and GRUB perform largely the same task. Basically, each presents a choice of operating systems (including, perhaps, multiple Linux kernels) and loads the selected OS kernel into memory. Both programs let you pass arguments on to a Linux kernel along the way, and both can be configured to boot non-Linux operating systems on the same machine.

Either LILO or GRUB (or other boot loaders) generally lives in the MBR (Master Boot Record) of the primary hard disk, which is automatically loaded by system BIOS. LILO was restricted to loading a specific raw sector from a harddisk. GRUB is more sophisticated in that it understands a number of filesystem types such as ext2/3, ReiserFS, VFAT, and UFS. This means that GRUB doesn't need to rewrite the MBR every time a configuration file is changed (the way LILO does).

Configuring the LILO boot loader

The LILO boot loader is configured with the contents of the file /etc/lilo.conf. For full details on configuration options, read the manpage on lilo.conf. Several initial options control general behavior. For example, you will often see boot=/dev/hda or similar; this installs LILO to the MBR of the first IDE hard disk. You might also install LILO within a particular partition, usually because you use a different main boot loader. For example, boot=/dev/sda3 installs LILO to the third partition of the first SCSI disk. Other options control the appearance and wait time of LILO.

Remember that after you have edited a /etc/lilo.conf configuration, you need to run LILO to actually install a new boot sector used during initialization. It is easy to forget to install new settings, but the boot loader itself cannot read the configuration except as encoded as raw sector offsets (which LILO calculates when run).

When using LILO you are mainly interested in the one or more image= lines and perhaps in some other= lines if you multiboot to other operating systems. A sample /etc/lilo.conf might contain:

Listing 2. Sample LILO configuration

image=/boot/bzImage-2.7.4
label="experimental"
image=/boot/vmlinuz
label="linux"
initrd=/boot/initrd.img
append="devfs=mount acpi=off quiet"
vga=788
read-only
other=/dev/hda3
label=dos

This configuration would allow you to choose at runtime either a 2.7.4 development kernel or a stable kernel (the latter happens to utilize an initial ramdrive during boot). You can also select a DOS installation installed to partition 3 on the first IDE drive.

Configuring the GRUB boot loader

A nice thing about GRUB is that it does not need to be reinstalled each time you change boot configuration. Of course, you do need to install it once in the first place, usually using a command like grub-install /dev/hda. Generally, distributions will do this for you during installation, so you may never explicitly run this.

However, since GRUB knows how to read many filesystems, normally you can simply change the contents of /boot/grub/menu.lst to change the options for the next bootup. Let's look at a sample configuration:

Listing 3. Sample GRUB configuration

timeout 5
color black/yellow yellow/black
default 0
password secretword

title linux
kernel (hd0,1)/boot/vmlinuz root=/dev/hda2 quiet
vga=788 acpi=off
initrd (hd0,1)/boot/initrd.img

title experimental
kernel (hd0,1)/boot/bzImage-2.7.4 root=/dev/hda2 quiet

title dos
root (hd0,4)
makeactive
chainloader +1

Changing options within the boot loader (LILO)

Both LILO and GRUB allow you to pass special parameters to the kernel you select. If you use LILO, you may pass boot prompt arguments by appending them to your kernel selection. For example, for a custom boot setting, you might type:

LILO: linux ether=9,0x300,0xd0000 root=/dev/ha2 vga=791 acpi=on

This line passes special parameters to the Ethernet module, specifies the root partition, chooses video mode, etc. Of course, it is not all that friendly, since you need to know the exact options available and type them correctly.

Of particular importance is the option to change the runlevel from the boot loader. For example, for recovery purposes, you may want to run in single-user mode, which you can do with the following:

LILO: experimental single

or:

LILO: linux 1

Another special option is the init= argument, which lets you use a program other than init as the first process. An option for a fallback situation might be init=/bin/sh, which at least gets you a Linux shell if init fails catastrophically.

Changing options within the boot loader (GRUB)

With GRUB, you have even more flexibility. In fact, GRUB is a whole basic shell that lets you change boot loader configurations and even read filesystems. For custom boot options, press "e" in the GRUB shell, then add options (such as a numeric runlevel or the keyword "single" as with LILO). All the other boot prompt arguments you might type under LILO can be edited in a GRUB boot command, using simple readlines-style editing.

For some real sense of the power, you can open a GRUB command line. For example, suppose you think your /etc/inittab might be misconfigured, and you want to examine it before booting. You might type:

grub> cat (hd0,2)/etc/inittab

This would let you manually view your initialization without even launching any operating system. If there were a problem there, you might want to boot into single-user mode and fix it.

Customizing what comes after the boot loader

Once you understand the steps in a Linux post-kernel boot process (in other words, the init process and everything it calls), you also understand how to customize it. Basically, customization is just a matter of editing /etc/inittab and the various scripts in /etc/rc?.d/ directories.

For example, I recently needed to customize the video bios on a Debian-based Linux laptop using a third-party tool. If this didn't run before X11 ran, my XOrg driver would not detect the correct video modes. Once I figured out what the issue was, the solution was as simple as creating the script /etc/rcS.d/S56-resolution.sh. In other words, I began running an extra script during every system startup.

Notably, I made sure this ran before /etc/rcS.d/S70xorg-common by the simple convention that scripts run in alphabetical order (if I wanted it to run later, I might have named it S98-resolution.sh instead). Arguably, I might have put this script only in the /etc/rc5.d/ directory to run when X11 does -- but my way lets me manually run startx from other runlevels.

Everything in the initialization process is out in the open, right in the filesystem; almost all of it is in editable text scripts.

System recovery


About recovery

The nicest thing about Linux from a maintenance perspective is that everything is a file. Of course, it can be perplexing at times to know which file something lives in. But as a rule, Linux recovery amounts to using basic filesystem utilities like cp, mv, and rm, and a text editor like vi. Of course, to automate these activities, tools like grep, awk, and bash are helpful; or at a higher level, perl or python. This tutorial does not address basic file manipulation.

Assuming you know how to manipulate and edit files, the only "gotcha" perhaps remaining for a broken system is not being able to use the filesystems at all.

Fixing a filesystem with fsck

Your best friend in repairing a broken filesystem is fsck. The next tutorial (on topic 203) has more information, so we will just introduce the tool here.

The tool called fsck is actually just a front-end for a number of more narrow fsck.* tools -- fsck.ext2, fsck.ext3, or fsck.reiser. You may specify the type explicitly using the -t option, but fsck will make an effort to figure it out on its own. Read the manpage for fsck or fsck.* for more details. The main thing you want to know is that the -a option will try to fix everything it can automatically.

You can check an unmounted filesystem by mentioning its raw device. For example, use fsck /dev/hda8 to check a partition not in use. You can also check a rooted filesystem such as fsck /home, but generally do that only if the filesystem is already mounted as read-only, not as read-write.

Mounting and unmounting with mount and umount

A flexible feature of Linux systems is the fine-tuned control you have over mounting and unmounting filesystems. Unlike under Windows and some other operating systems, partitions are not automatically assigned locations by the Linux kernel, but are instead attached to the single / root hierarchy by the mount command. Moreover, different filesystem types (on different drives, even) may be mounted within the same hierarchy. You can unmount a particular partition with the umount command, specifying either the mount point (such as /home) or the raw device (such as /dev/hda7).

For recovery purposes, the ability to control mount points lets you do forensic analysis on partitions -- using fsck or other tools -- without risk of further damage to a damaged filesystem. You may also custom mount a filesystem using various options; the most important of these is mounting read-only using either of the synonyms -r or -o ro.

As a quick example, you might want to substitute one user directory location for another, either because of damage to one or simply to expand disk space or move to a faster disk. You might perform this switch using something like:

# umount /home # old /dev/hda7 home dir
# mount -t xfs /dev/sda1 /home # new SCSI disk using XFS
# mount -t ext3 /dev/sda2 /tmp # also put the /tmp on SCSI

Mounting at bootup with /etc/fstab

For recovery, system upgrades, and special purposes, it is useful to be able to mount and unmount filesystems at will. But for day-to-day operation, you generally want a pretty fixed set of mounts to happen at every system boot. You control the mounts that happen at bootup by putting configuration lines in the file /etc/fstab. A typical configuration might look something like this:

Listing 4. Sample configuration in /etc/fstab

/dev/hda7 / ext3 defaults 1 1
none /dev/pts devpts mode=0620 0 0
/dev/hda9 /home ext3 defaults 1 2
none /mnt/cdrom supermount
dev=/dev/hdc,fs=auto,ro,--,iocharset=iso8859-1,codepage=850,umask=0 0 0
none /mnt/floppy supermount
dev=/dev/fd0,fs=auto,--,iocharset=iso8859-1,sync,codepage=850,umask=0 0 0
none /proc proc defaults 0 0
/dev/hda8 swap swap defaults 0 0

Tuesday, 17 March 2020

LPI Exam 201 Prep: Filesystem

LPI Exam, 201 Prep, LPI Learning, LPI Tutorial and Material, LPI Certification

Prerequisites

To get the most from this tutorial, you should already have a basic knowledge of Linux and a working Linux system on which you can practice the commands covered in this tutorial.

Creating and configuring filesystem options


Let's go out of order and start with creating and configuring filesystems and options.

Creating partitions

Before you can work with Linux filesystems, you need to create them. But before you can create a filesystem, you need to create a partition to put it on. As a brief primer, on x86 machines, hard disks may be divided into four primary partitions, but the last of those primary partitions may contain a number of extended partitions inside it.

In the past there were a number of restrictions about the highest cylinders where bootable partitions can occur, maximum disk sizes, locations of primary partitions on large disks, and so on. However, for the last five years or more, pretty much all system BIOSes flexibly handle disks of essentially unlimited size, and modern bootloaders (at least for Linux) have no important restrictions about partition sizes or locations.

The only rule that remains to worry about nowadays concerns operating systems other than Linux. Sometimes those still insist on living in primary partitions near the front of a hard disk. Linux partitions are more than happy to reside on extended partitions and anywhere on any accessible disk drive.

There are several widely used tools in the Linux world for creating and manipulating partitions on hard disks. The oldest such tool is fdisk. Somewhat later, the curses-based cfdisk became popular. GNU parted is also used in many distributions. Further, the installation systems for most Linux distributions and/or their graphical environments come with partitioning front-ends that provide friendlier interfaces to viewing and modifying partitions.

Of these tools, fdisk remains the most flexible and most forgiving tool. But "forgiving" is a slightly odd term to use here. Writing unintended partition-table information is a recipe for disaster regardless of what tool you use. But if your partitions have been created in somewhat non-standard ways, often by non-Linux operating systems and tools, fdisk will generally forge ahead where other tools might refuse to try at all. If it works, however, cfdisk is generally friendlier and more interactive. And parted provides more powerful options about resizing and moving existing partitions non-destructively than fdisk or cfdisk.

Whatever tool you use to create partitions, the concepts are similar. First, you need to perform these operations as root, ideally in single-user mode. And it's hard to make this point too strongly: Be careful when you modify partitions: ideally, have all important data backed up, and pay careful attention to what changes you make.

Before you start modifying a partition table, it is a good idea to be clear about what partitions currently exist. The command fdisk -l /dev/hda (or similar for other disks, for example /dev/hdb or /dev/sda) gives you information on existing partitions. mount is also helpful in understanding how these existing partitions are actually being used. If you wish to create new partitions, keep in mind any extra sectors within the fourth primary partition that might be available for additional extended partitions.

Let's see an example of a partition table on a Linux system of mine:

Listing 1. Sample partition table

% fdisk -l /dev/sda
Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders

Device Boot   Start      End      Blocks     Id  System
/dev/sda1   *        1     1216     9767488+     7  HPFS/NTFS
/dev/sda3         1217     4255    24410767+    83  Linux
/dev/sda4         4256     9729    43969905      5  Extended
/dev/sda5         4256     4380     1004031     82  Linux swap /
Solaris
/dev/sda6         4381     5597     9775521     83  Linux

This tells us several things. First of all, we can see that partition one is probably used by a foreign operating system. And running mount will let us know:

% mount | head -1
/dev/sda3 on / type reiserfs (rw,noatime,notail,commit=600)

That is, the existing system is rooted on /dev/sda3. Perhaps most interestingly, the /dev/sda4 partition extends to cylinder 9729, but the extended partitions within it use only part of that space.

After discovering some free space available on the drive, let's create a partition within it using fdisk:

% fdisk /dev/sda

The number of cylinders for this disk is set to 9729. There is nothing wrong with that, but this is larger than 1024 and could, in certain setups, cause problems with:

1. Software that runs at boot time (such as old versions of LILO).
2. Booting ant partitioning software from other operating systems (such as DOS FDISK, OS/2 FDISK).

Listing 2. Creating a partition

Command (m for help): n
Command action
l   logical (5 or over)
p   primary partition (1-4)
l
First cylinder (5598-9729), default 5598):
Using default value 5598
Last cylinder or +size or +sizeM or +sizeK (5598-9729, default 9729):
+10000M

Command (m for help): w
The partition table has been altered!

Everything that follows a colon is typed in by the user (you). At this point, we have created a new 10 GB Linux partition:

/dev/sda7 5598 6814 9775521 83 Linux

Keep reading to find out how to use this partition. Note that you may need to reboot a system to make new partitions accessible.

Making a filesystem in a partition

Just having a partition is not quite enough; you need to make the filesystem. Above we created a new Linux partition at /dev/sda7, but we need to decide which of the many filesystems Linux supports to use within that partition. Do we want the historical default ext2? Or the newer journaling-enhanced extension ext3 format? Maybe we want one of the enhanced filesystems contributed to Linux by other parties: ReiserFS, XFS, JFS. Or maybe we need a filesystem that interoperates with another operating system, such as Minix, MSDOS, or VFAT (some others can be read if created already, but not always created with Linux tools).

All of the tools for making new filesystems follow the naming convention mkfs.*. That is, your system might have mkfs.ext2, mkfs.minix, mkfs.xfx, and so on, usually installed in /sbin/. Also, you may access each of these using the basic mkfs -t <fstype> switch. Several, but not all, of the filesystems also have compact forms like mke3fs. The filesystems that are available depend on your specific Linux distribution and version, and any extra tools you might have installed. mkfs.ext2 is available on nearly every distribution.

The basics of making a filesystem are simple. Just run your desired mkfs.* tool against the partition you want the filesystem to exist on. For example:

% mkfs.xfs /dev/sda7

The displayed messages will vary according to the filesystem type you used. Generally, the messages give you information on the number of inodes, blocks, journaling type (if any), extents, and fragments relevant to that particular filesystem's usage strategy. Many of the filesystem creation tools warn you if you try to create a new filesystem on a partition with an existing filesystem, but not all of them will, so proceed with great caution (creating a new filesystem over an old one will probably result in data loss).

Making an ISO filesystem with mkisofs

A special case of making a filesystem is the creation of an ISO filesystem, which is a system image that may be written to a writeable CD or DVD device. An ISO filesystem is special in the sense that it is really just a (large) file with data laid out in a certain way rather than in an arrangement of a raw device like /dev/cdrom or /dev/hdb3.

The basic idea of creating an ISO filesystem -- which really means either an ISO9660 or HFS hybrid volume -- is simply to take the files in one or more existing hierarchies and arrange them into an ISO image. ISO9660 itself is limited to simple DOS-style 8.3 names, but the Rock Ridge and Joliet extensions allow storage of longer names and/or additional file attributes. For example, to create an image of a project, you might use a command like:

% mkisofs -o ProjectCD.iso -r ~/project-files ~/project-extras

In this case, we create an ISO image that uses Rock Ridge attributes (but unlike -R sets more useful values, such as all files readable) and contains a merge of all the files in two directories. Other options would let us add bootable headers to the image, create an HFS image, attach directories in specified locations other than root, and fine-tune file options.

Making an ISO filesystem with cdrecord

Transferring an ISO image to a recordable CD or DVD is often accomplished nowadays using a front-end tool, often a GUI interface. For example, both Gnome and KDE make CD burning part of their file-manager interface. Some commercial tools exist also. But for a system administrator, the older command-line tool cdrecord is a trusted utility that is present on most modern distributions and is much closer to "standard" than are other front-ends. Generally, the basic usage just requires specifying the device you want to write to and the ISO file you want to write.

As usual with Linux utilities, you may also specify a number of options to the record process, such as -overburn for CDs larger than 650 MB or a specific burn speed for your writer. See the manpage for cdrecord for current details.

You can find the device with the -scanbus option. The device you want is named as a numeric triple indicating the bus, not a regular block device in the filesystem. For example, you might see something like (abridged):

Listing 3. Finding a recordable device

% cdrecord -scanbus
[...]
scsibus0:
0,0,0     0) 'ATA     ' 'WDC WD800UE-00HC' '09.0' Disk
0,1,0     1) *
[...]
scsibus1:
1,0,0   100) 'Slimtype' 'DVDRW SOSW-852S ' 'PSB2' Removable
CD-ROM
[...]

With bus information in hand, you can burn an image:

% sudo cdrecord -overburn -v speed=16 dev=1,0,0
/media/KNOPPIX_V3.6-2004-08-16-EN.iso

In this case, the image is oversized and I know my burner supports 16x. The action command output is rather verbose because of the -v option, but that helps in understanding the whole process.

Making an ISO filesystem with dd

Of final note, sometimes you want to create a brand new ISO image not out of some directories in your main filesystem, but rather from an already existing CD or DVD. To make an ISO image from a CD, just use the command dd, but refer to the raw block device for the CD rather than to the mounted location:

% dd if=/dev/cdrom of=project-cd.iso

You might wonder why not just use cp if the goal is to copy bytes. Actually, if you ignore a reported I/O error when the raw device runs out of bytes to copy, the cp command is likely to work. However, dd is better style (and doesn't complain, but instead reports a summary of activity).

Operating the Linux filesystem


Mounting and unmounting with mount and umount

A flexible feature of Linux systems is the fine-tuned control you have over mounting and unmounting filesystems. Unlike under Windows and some other operating systems, partitions are not automatically assigned locations by the Linux kernel, but are instead attached to the single / root hierarchy by the mount command. Moreover, different filesystem types (on different drives, even) may be mounted within the same hierarchy. You can unmount a particular partition with the umount command, specifying either the mount point (such as /home) or the raw device (such as /dev/hda7).

For recovery purposes, the ability to control mount points lets you do forensic analysis on partitions -- using fsck or other tools -- without risk of further damage to a damaged filesystem. You may also custom mount a filesystem using various options; the most important of these is mounting read-only using either of the synonyms -r or -o ro.

As a quick example, you might want to substitute one user directory location for another, either because of damage to one or simply to expand disk space or move to a faster disk. You might perform this switch using something like:

# umount /home # old /dev/hda7 home dir
# mount -t xfs /dev/sda1 /home # new SCSI disk using XFS
# mount -t ext3 /dev/sda2 /tmp # also put the /tmp on SCSI

Default mounting

For day-to-day operation, you generally want a pretty fixed set of mounts to happen at every system boot. You control the mounts that happen at bootup by putting configuration lines in the file /etc/fstab. A typical configuration might look something like this:

Listing 4. Sample configuration for mounting at bootup

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
       proc            /proc           proc    defaults        0       0
       /dev/sda3       /               reiserfs notail         0       1
       /dev/sda5       none            swap    sw              0       0
       /dev/sda6       /home           ext3    rw              0       2
       /dev/scd0       /media/cdrom0   udf,iso9660 ro,user,noauto  0   0
       /media/Ubuntu-5.04-install-i386.iso /media/Ubuntu_5.04 iso9660
rw,loop 0 0

In the above listing, the first field (<file system>) is normally the block device to mount. The second field (<mount point>) is the mounted location. In some special cases, something other than a block device is given first. For supermount devices, you will see none. /proc is another odd case. You might also mount loopback devices, which are usually regular files.

The third field (<type>) and fourth field (<options>) are fairly straightforward; options depend on filesystem type and usage. The fifth field (<dump>) is usually zero. The sixth field (<pass>) should be 1 for the root filesystem and 2 for other filesystems that should be fscked during system boot.

Automounting with AMD and automount

Linux has quite a few ways of automatically mounting media that is removable (floppies, CDs, USB drives) or otherwise not of fixed availability (such as NFS filesystems). The goal of all these tools is similar, but each works slightly differently.

The tool AMD (automount daemon) is somewhat older and operates in userland. Basically, AMD runs periodically to see if any new mountable filesystems have become available generally for NFS filesystems. For the most part, AMD has been replaced in Linux distributions by Autofs, which runs as a kernel process.

You set up Autofs by compiling it into the kernel you use. After that, the behavior of the Autofs daemon (usually /etc/init.d/autofs) is controlled by the file /etc/auto.master, which in turn references a map file. For example:

# Sample auto.master file
# Format of this file: mountpoint map options
/mnt /etc/auto.mnt --timeout=10

The referenced /etc/auto.mnt specifies one or more subdirectories of /mnt that will be mounted (if access is requested). Unmounting will occur automatically, in this case 10 seconds after last access.

# Sample /etc/auto.mnt
floppy -fstype=auto,rw,sync,umask=002 :/dev/fd0
cdrom -fstype=iso9660,ro,nosuid,nodev :/dev/cdrom
remote -fstype=nfs example.com:/some/dir

Automounting with supermount and submount

The tools supermount and submount are kernel-level tools (either compiled into the base kernel or kernel modules) to automatically mount removable media when accessed. submount is somewhat newer, but supermount is still probably used in more distributions. Neither tool is useful for NFS remote mounts, but either is more seamless than Autofs for local media.

In either case, devices requiring automounting are generally listed in the /etc/fstab configuration. The tools use slightly different syntaxes in /etc/fstab, but both are straightforward. A supermount-enabled /etc/fstab might contain the following:

# Example of supermount in /etc/fstab
none /mnt/cdrom supermount fs=auto,dev=/dev/cdrom 0 0
none /mnt/floppy supermount fs=auto,dev=/dev/fd0,--,user,rw 0 0

submount specifies the block device in the regular location rather than as a mount option. For example:

/dev/cdrom /mnt/cdrom subfs fs=cdfss,ro,users 0 0
/dev/fd0 /mnt/floppy subfs fs=floppyfss,rw,users 0 0

What is currently mounted?

A Linux user has several ways to see a list of current mounts. The mount command with no options (or with the -l option) lists currently mounted paths. If you like, you can filter the results with the -t fstype option.

The underlying dynamic information on mounted filesystems lives in /etc/mtab. The mount and umount commands and other systems processes will update this file to reflect current status; you should treat this file as read-only. A subset of the mount status information is additionally contained in /proc/mounts.

Special tools

The tool sync forces changed unwritten blocks to disk. You should not need to use this in normal situations, but you can sometimes check for disk problems by checking for a non-zero exit status. Modern filesystems, particularly journaling filesystems like ext3, Reiser, and JFS, effectively do syncing on every write.

If you like, you can manually disable or enable the use of a swapping or enable/disable swapping for particular devices. Normally, every device marked as type swap in /etc/fstab is used for swapping.

Maintaining a Linux filesystem


Fixing a filesystem with fsck

Your best friend in repairing a broken filesystem is fsck.

The tool called fsck is actually just a front-end for a number of more narrow fsck.* tools -- fsck.ext2, fsck.ext3, or fsck.reiser. You may specify the type explicitly using the -t option, but fsck will make an effort to figure it out on its own. Read the manpage for fsck or fsck.* for more details. The main thing you want to know is that the -a option will try to fix everything it can automatically.

You can check an unmounted filesystem by mentioning its raw device. For example, use fsck /dev/hda8 to check a partition not in use. You can also check a rooted filesystem such as fsck /home, but generally do that only if the filesystem is already mounted as read-only, not as read-write.

Checking blocks with badblocks

The badblocks utility does a lower-level test of the quality of a block device (or partition) than fsck does. badblocks may -- destructively or non-destructively -- examine the reliability of blocks on a device by writing and reading test patterns. The default option is -n for a slower mode that preserves existing data. For a brand-new partition with no existing files, you can (and probably should) use the -w. This tool simply informs you of bad blocks; it does not repair or mark them.

However, in practice, you are usually better off using the badblock-checking wrapper in the fsck.* tool for your filesystem. For example, e2fsck (also called fsck.ext2) has the option -c to find and mark badblocks that the badblocks tool can detect. ReiserFS has similar --check and --badblocks options (but is not quite as automatic). Read the documentation for your particular filesystem for details on wrappers to badblocks.

Finding other maintenance utilities

Several tools are available for examining and fine-tuning Linux filesystems. In normal usage, the default settings for filesystems are well designed, but occasionally you will want to use filesystem tools for forensic analysis on crashed systems or to tune performance on systems with well-defined usage patterns.

Each filesystem type has its own set of tools; check the documentation for the filesystem you use for more details. Most have a similar array of tools. Some examples include:

◉ dumpe2fs: Output information about an ext2/3 filesystem.
◉ tune2fs: Adjust filesystem parameters on an ext2/3 filesystem.
◉ debugfs: Interactively fine-tune and examine an ext2/3 filesystem.
◉ debugreiserfs: Output information about a Reiser filesystem.
◉ reiserfstune: Adjust filesystem parameters on a Reiser filesystem.
◉ xfs_admin: Adjust filesystem parameters of an XFS filesystem.

Saturday, 14 March 2020

LPI Exam 201 Prep: Hardware

Configuring RAID


What is RAID?

RAID (Redundant Array of Inexpensive Disks) provides mechanisms to combine multiple partitions on different hard drives into larger or more resilient virtual hard drives. Numerous RAID levels were initially defined, but only three remain in common use: RAID-0 (disk striping), RAID-1 (mirroring), and RAID-5 (striping with parity information). RAID-4 is also occasionally used; it is similar to RAID-5 but puts parity information on exactly one drive rather than distributing it.

LPI Exam 201 Prep, LPI Exam Prep, LPI Prep, LPI Tutorial and Material

This tutorial discusses the "new-style" RAID under Linux (the default for 2.4 and 2.6 kernels with backports to earlier kernels available). The "old-style" RAID initially present in 2.0 and 2.2 kernels was buggy and should not be used. Specifically, "new-style" means the 0.90 RAID layer made by Ingo Molnar and others.

Using a RAID array

There are two basic parts to using a RAID array. The simple part is mounting the RAID device. Once a RAID (virtual) device is configured, it looks to the mount command the same as a regular block device partition. A RAID device is named as /dev/mdN once it is created, so you might mount it as:

% mount /dev/md0 /home

You can also include a line in /etc/fstab to mount the RAID virtual partition (this is usually the preferred method). The device driver reads superblocks of raw partitions to assemble a RAID partition once it has been created.

The more complicated part (more detailed, anyway) involves creating the RAID device out of relevant raw partitions. You can create a RAID partition with the tool mkraid combined with an /etc/raidtab configuration file.

You can also use the newer tool mdadm, which can usually operate without the need for a separate configuration file. In most distributions, mdadm is supplanting raidtools (which includes mkraid), but this tutorial discusses mkraid to follow the LPI exam objectives. The concepts are similar either way, but you should read the mdadm manpage to learn about its switches.

The layout of /etc/raidtab

The following definitions are used in the /etc/raidtab file to describe the components of a RAID. This list is not exhaustive.

◉ raiddev: The virtual disk partition provided by RAID (/dev/md?). This is the device that mkfs and fsck work with, and that is mounted in the same way as an actual hard disk partition.

◉ raid-disk: The underlying partitions used to build a RAID. They should be marked (with fdisk or similar tools) as partition type 0xFD.

◉ spare-disk: These disks (typically there's only one) normally lie unused. When one of the raid disks fails the spare disk is brought online as a replacement.

Configuring RAID-0

RAID-0 or "disk striping" provides more disk I/O bandwidth at the cost of less reliability (a failure in any one of the raid-disks and you loose the entire RAID device). For example the following /etc/raidtab entry sets up a RAID-0 device:

raiddev /dev/md0
    raid-level      0
    nr-raid-disks   2
    nr-spare-disks  0
    chunk-size      32
    persistent-superblock   1
    device          /dev/sda2
    raid-disk       0
    device          /dev/sdb2
    raid-disk       1

This defines a RAID-0 virtual device called /dev/md0. The first 32 KB chunk of /dev/md0 is allocated to /dev/sda2, the next 32 KB go on /dev/sdb2, the third chunk is on /dev/sda2, etc.

To actually create the device, simply run:

% sudo mkraid /dev/md0

If you use mdadm, switches will configure these options rather than the /etc/raidtab file.

Configuring RAID-1

RAID-1 or "disk mirroring" simply keeps duplicate copies of the data on both block devices. RAID-1 gracefully handles a drive failure with no noticeable drop in performance. RAID-1 is generally considered expensive since half of your disk space is redundant. For example:

raiddev /dev/md0
    raid-level      1
    nr-raid-disks   2
    nr-spare-disks  1
    persistent-superblock 1
    device          /dev/sdb6
    raid-disk       0
    device          /dev/sdc5
    raid-disk       1
    device          /dev/sdd5
    spare-disk      0

Data written to /dev/md0 will be saved on both /dev/sdb6 and /dev/sdc5. /dev/sdd5 is configured as a hot spare. In the event /dev/sdb6 or /dev/sdc5 malfunctions, /dev/sdd5 will be populated with data and brought online as a replacement.

Configuring RAID-5

RAID-5 requires at least three drives and uses error correction to get most of the benefits of disk striping but with the ability to survive a single drive failure. On the positive side, it requires only one extra redundant drive. On the negative side, RAID-5 is more complex; when a drive does fail, it drops into degraded mode which can dramatically impact I/O performance until a spare-disk can be brought online and repopulated.

raiddev /dev/md0
    raid-level        5
    nr-raid-disks     7
    nr-spare-disks    0
    persistent-superblock 1
    parity-algorithm  left-symmetric
    chunk-size        32
    device            /dev/sda3
    raid-disk         0
    device            /dev/sdb1
    raid-disk         1
    device            /dev/sdc1
    raid-disk         2
    device            /dev/sdd1
    raid-disk         3
    device            /dev/sde1
    raid-disk         4
    device            /dev/sdf1
    raid-disk         5
    device            /dev/sdg1
    raid-disk         6

Using mke2fs or mke3fs

If you format a RAID-5 virtual device using e2fs or e3fs, you should pay attention to the stride option. The -R stride=nn option will allow mke2fs to better place different ext2-specific data structures in an intelligent way on the RAID device.

If the chunk size is 32 KB, it means that 32 KB of consecutive data will reside on one disk. If an ext2 filesystem has 4 KB block size then there will be eight filesystem blocks in one array chunk. We can indicate this information to the filesystem by running:

% mke2fs -b 4096 -R stride=8 /dev/md0

RAID-5 performance is greatly enhanced by providing the filesystem with correct stride information.

Kernel support and failures

Enabling the persistent-superblock feature allows the kernel to start the RAID automatically at boot time. New-style RAID uses the persistent superblock and is supported in 2.4 and 2.6 kernels. Patches are available to retrofit 2.0 and 2.2 kernels.

Here's what happens when a drive fails:

◉ RAID-0: All data is lost>
◉ RAID-1/RAID-5: The failed drive is taken offline and the spare disk (if it exists) is brought online and populated with data.

The document "The Software-RAID HOWTO" in the Linux HOWTO project discusses swapping in drives for failed or updated drives, including when such drives are hot-swappable and when a reboot will be required. Generally, SCSI (or Firewire) are hot-swappable while IDE drives are not.

Adding new hardware


About hardware

Linux, especially in recent versions, has an amazingly robust and broad capability to utilize a variety of hardware devices. In general, there are two levels of support that you might need to worry about in supporting hardware. At a first level, there is a question of supporting a device at a basic system level; doing this is almost always by means of loading appropriate kernel modules for your hardware device.

At a second level, some devices need more-or-less separate support from the X11R6 subsystem: generally either XFree86 or X.Org (very rarely, a commercial X11 subsystem is used, but this tutorial does not discuss that).

Support for the main hot-swappable device categories -- such as those using PCMCIA or USB interfaces -- are covered in their own topic sections to follow.

About X11

A quick note: X.Org is essentially the successor project to XFree86 (technically a fork). While XFree86 has not officially folded, almost all distribution support has shifted to X.Org because of licensing issues. Fortunately, except for some minor renaming of configuration files, the initial code base for both forks is largely the same; some newer special features are more likely to be supported in X.Org only.

X11R6 is a system for (networked) presentation of graphical applications on a user workstation. Perhaps counter-intuitively, an "X server" is the physical machine that a user concretely interacts with using its keyboard, pointing device(s), video card, display monitor, etc. An "X client" is the physical machine that devotes CPU time, disk space, and other non-presentation resources to running an application. In many or most Linux systems, the X server and X client are the self-same physical machine and a very efficient local communication channel is used for an application to communicate with user I/O devices.

An X server -- such as X.Org -- needs to provide device support for the I/O devices with which a user will interact with an application. Overwhelmingly, where there is any difficulty, it has to do with configuring video cards and display monitors. Fortunately, this difficulty has decreased in recent X.Org/XFree86 versions with much more automatic detection performed successfully. Technically, an X server also needs to support input devices -- keyboards and mice -- but that is usually fairly painless since these are well standardized interfaces. Everything else -- disk access, memory, network interfaces, printers, special devices like scanners, and so on -- are all handled by the X client application, generally by the underlying Linux kernel.

Kernel device support

Almost everything you need to know about device support in the Linux kernel boils down to finding, compiling, and loading the right kernel modules. That topic is covered extensively in the Topic 201 tutorial -- readers should consult that tutorial for most issues.

To review kernel modules, the main tools a system administrator needs to think about are lsmod, insmod, and modprobe. Also rmmod to a lesser extent. The tools lsmod, insmod and rmmod are low-level tools to, respectively, list, insert, and remove kernel modules for a running Linux kernel. modprobe performs these same functions at a higher level by examining dependencies, then making appropriate calls to insmod and rmmod behind the scenes.

Examining hardware devices

Several utilities are useful for scoping out what hardware you actually have available. The tool lspci provides detailed information on findable PCI devices (including those over PCMCIA or USB buses, in many cases). Correspondingly setpci can configure devices on PCI buses. lspnp lists plug-and-play BIOS device nodes and resources. lsusb similarly examines USB devices (and has a setpnp to modify configurations).

Setting up an X11 server (part one)

Basically, X.Org (or XFree86) come with a whole lot of video drivers and other peripheral drivers; you need to choose the right ones to use. Ultimately, the configuration for an X server lives in the rather detailed, and somewhat cryptic, file /etc/X11/xorg.conf (or xfree86.conf). A couple standard utilities can be used for somewhat friendlier modification of this file, but ultimately a text editor works. Some frontends included with X.Org itself include xorgcfg for graphical configuration (assuming you have it working well enough to use that) and xorgconfig for a text-based setup tool. Many Linux distributions package friendlier frontends.

The tool SuperProbe is often useful in detecting the model of your video card. You may also consult the database /usr/X11R6/lib/X11/Cards for detailed information on supported video cards.

Setting up an X11 server (part two)

Within the configuration file /etc/X11/xorg.conf, you should create a series of "Section" ... "EndSection" blocks, each of which defines a number of details and options about a particular device. These section names consist of:

* Files:          File pathnames
* ServerFlags:    Server flags
* Module:         Dynamic module loading
* InputDevice:    Input device description
* Device:         Graphics device description
* VideoAdaptor:   Xv video adaptor description
* Monitor:        Monitor description
* Modes:          Video modes descriptions
* Screen:         Screen configuration
* ServerLayout:   Overall layout
* DRI:            DRI-specific configuration
* Vendor:         Vendor-specific configuration

Setting up an X11 server (part three)

Among the sections, Screen acts as a master configuration for the display system. For example, you might define several Monitor sections, but select the one actually used with:

Section "Screen"
    Identifier    "Default Screen"
    Device        "My Video Card"
    Monitor       "Current Monitor"
    DefaultDepth  24
    SubSection "Display:
          Depth       24
          Modes       "1280x1024" "1024x768" "800x600"
    EndSubSection
    # more subsections and directives
Endsection

The section named ServerLayout is the real "master" configuration -- it refers to both the Screen to use and to various InputDevice sections. But if you have a problem, it is almost always with selecting the right Device or Monitor. Fortunately, DPMS monitors nowadays usually obviate the need to set painful Modeline options (in the bad old days, you needed to locate very specific timings on your monitors scan rates; usually DPMS handles this for you now).

Configuring PCMCIA devices


About PCMCIA

PCMCIA devices are also sometimes called PC-Card devices. These (thick) credit-card sized peripherals are generally designed to be easily hot-swappable and transportable and are used most widely in notebook computers. However, some desktop or server configurations also have PCMCIA readers, sometimes in an external chassis connected via one of several possible buses (a special PCI or ISA card, a USB translator, etc). A variety of peripherals have been created in PCMCIA form factor, including wireless and Ethernet adaptors, microdrives, flash drives, modems, SCSI adapters, and other special-purpose devices.

Technically, a PCMCIA interface is a layer used to connect to an underlying ISA or PCI bus. For the most part, the translation is transparent -- the very same kernel modules or other tools that communicate with an ISA or PCI device will be used to manage the same protocol provided via PCMCIA. The only real special issue with PCMCIA devices is recognition of the insertion event and of the card type whose drivers should load.

Nowadays, the PCMCIA peripheral packaging is being eclipsed by USB and/or Firewire devices. While PCMCIA is a bit more convenient as a physical form-factor (usually hiding cards in the machine chassis), USB is closer to universal on a range of machines. As a result, many devices that have been packaged as PCMCIA in the past might now be packaged as USB "dongle" style devices; these are more readily available at retail outlets.

Recognizing a PCMCIA device (part one)

In modern kernels -- 2.4 and above -- PCMCIA support is available as a kernel module. Modern distribution will include this support, but if you compile a custom kernel, include the options CONFIG_HOTPLUG, CONFIG_PCMCIA, and CONFIG_CARDBUS. The same support was previously available in separately in the pcmcia-cs package.

The modules pcmcia_core and pcmcia support loading PCMCIA devices. yenta_socket is also generally loaded to support the CardBus interface (PCI-over-PCMCIA):

% lsmod | egrep '(yenta)|(pcmcia)'
pcmcia                 21380  3 atmel_cs
yenta_socket           19584  1
pcmcia_core            53568  3 atmel_cs,pcmcia,yenta_socket

Once a card is inserted into a PCMCIA slot, the daemon cardmgr looks up a card in the database /etc/pcmcia/config then loads appropriate supporting drivers as needed.

Recognizing a PCMCIA device (part two)

Let us take a look at the PCMCIA recognition in action. I inserted a card into a Linux laptop with a PCMCIA slot and with the previously listed kernel module support. I can use the tool cardctl to see what information this peripheral provided:

% cardctl ident
Socket 0:
  product info: "Belkin", "11Mbps-Wireless-Notebook-Network-Adapter"
  manfid: 0x01bf, 0x3302
  function: 6 (network)

This information is provided by the pcmcia_core kernel module by querying the physical card. Once the identification is available, cardmgr scans the database to figure out what driver(s) to load. Something like:

% grep -C 1 '0x01bf,0x3302' /etc/pcmcia/config
card "Belkin FSD6020 v2"
  manfid 0x01bf,0x3302
  bind "atmel_cs"

In this case, we want the kernel module atmel_cs to support the wireless interface this card provides. You can see what actually got loaded by looking at either /var/lib/pcmcia/stab or /var/run/stab, depending on your system:

% cat /var/run/stab
Socket 0: Belkin FSD6020 v2
0       network atmel_cs        0       eth2

Debugging a PCMCIA device

In the above example, everything worked seamlessly. The card was recognized, drivers loaded, and the capabilities ready to go. That is the best case. If things are not as smooth, you might not find a driver to load.

If you are confident that your PCMCIA device can use an existing driver (for example, it is compatible with another chipset), you can manually run insmod to load the appropriate kernel module. Or if you use this card repeatedly, you can edit /etc/pcmcia/config to support your card, indicating the needed driver. However, guessing a needed module is unlikely to succeed -- you need to make sure your card really is compatible with some other known PCMCIA card.

Loading PCMCIA devices can be customized with the setup scripts in /etc/pcmcia/, each named for a category of function. For example, when an 802.11b card like the previous example loads, the script /etc/pcmcia/wireless runs. You can customize these scripts if your device has special setup requirements.

Using "schemes" for different configurations

If you need to use a PCMCIA device in multiple configurations, you may use the cardctl scheme command to set (or query) a configuration. For example:

% sudo cardctl scheme foo
checking: eth2
/sbin/ifdown: interface eth2 not configured
Changing scheme to 'foo'...
Ignoring unknown interface eth2=eth2.
% cardctl scheme
Current scheme: 'foo'.

In this case, I have not actually defined the foo scheme, but in general, if you change a scheme, device reconfiguration is attempted. Schemes may be used in setup scripts by examining the $ADDRESS variable:

# in /etc/pcmcia/network.opts (called by /etc/pcmcia/network)
case "$ADDRESS" in
work,*,*,*)
    # definitions for network in work scheme ...
    ;;
default,*,*,*)
    # definitions for network in default scheme ...
    ;;
esac

You may of course, set schemes in initialization scripts or via other triggering events (in a cron job, via a GUI interface, etc.).

Configuring Universal Serial Bus devices


About USB

As the section on PCMCIA mentioned, USB is somewhat newer technology that has largely eclipsed PCMCIA in importance. USB allows chaining of up to 127 devices on the same bus using a flexible radial topology of hubs and devices. USB comes in several versions with increasing speeds, the latest being 2.0. The latest USB version theoretically supports up to 480 MBsec. USB 1.1 supported the lower speed of 12 MBsec. In practice, there are a lot of reasons that particular devices might, in fact, operate much slower than these theoretical numbers -- but it is still a reasonably fast bus interface.

Recognizing a USB device (part one)

At an administrative level, USB works very similarly to PCMCIA. The kernel module is usbcore. Support is better in 2.4+ kernels than in earlier 2.2 kernels. Above the usbcore level, one of several kernel modules support: uhci, uhci_hcp, ohci, ohci_hcp, ehci, ehci_hcp. Exactly which kernel modules you need depends on the chipset your machine uses; and in the case of ehci whether it supports USB 2.0 high speed. Generally, if your machine support ehci (or ehci_hcp), you will also want a backward-compatible ehci module loaded. Brad Hards' "The Linux USB sub-system" contains details on exactly which chipsets support which kernel modules. For multiuse kernels, you should just compile in all the USB modules.

Assuming you get a kernel with the correct support, the hotplug subsystem should handle loading any drivers needed for a specific inserted USB device. The file /proc/bus/usb/devices contains detailed information on the currently available USB devices (both hubs and peripherals).

Recognizing a USB device (part two)

Normally the USB bus is mounted as a dynamically generated filesystem similar to the /proc/ filesystem. The filesystem type is known as either usbdevfs or usbfs. Depending on your distribution, /proc/bus/usb/ might get mounted either in initialization scripts such as /etc/rcS.d/S02mountvirtfs or via an /etc/fstab configuration. In the latter case, you might have a line like:

# /etc/fstab
none /proc/bus/usb usbdevfs defaults 0 0

Otherwise, an initialization script might run something like:

mount -t usbdevfs none /proc/bus/usb

The recognition of devices and control over the USB subsystem is contained in the /etc/hotplug/, especially within /etc/hotplug/usb.rc and /etc/hotplug/usb.agent. Inserting a USB device will modprobe a driver. You may customize the initialization of a device further by creating a /etc/hotplug/usb/$DRIVER script for your particular peripheral.