Git Unlocked:: A Beginner's Guide to Version Control

Git is source code management systems. Its distributed version control system (DVCS) which facilitates multiple developers and teams to work in parallel.  Git’s primary emphasis is on providing speed while maintaining data integrity. Git also provides ability to perform almost all the operations offline, when network is not available. All the changes can be pushed to the server on network’s availability.

source: GIT workflow structure

Git is designed as a distributed version control system, which means:

Data Structure:

Git uses a data structure called a Merkle tree, where each commit points to its parent commit, forming a chain of versions. Each commit has a unique SHA-1 hash that identifies it and its content.

Objects:

There are four main types of objects in Git:

1. Blobs: Store file data.
2. Trees: Represent directories and contain blobs or other trees.
3. Commits: Point to trees and contain metadata such as author, date, and commit message.
4. Tags: Reference specific commits for marking release points24.

Branches:

Branches are pointers to commits, allowing multiple lines of development within the same repository. The default branch is usually called master or main.

Staging Area:

Before committing changes, files are added to the staging area using git add. This allows users to review changes before finalizing them in a commit.

Remote Repositories:

Git allows synchronization between local repositories and remote ones (like GitHub), enabling collaboration among multiple users.

Some of the commonly used terms are listed below :

1. Repository - is directory that contains all the project files.
2. Clone - it creates a working copy of local repository.
3. Branch - is created to encapsulate the development of new features or to fix bugs.
4. HEAD - points to the last commit.
5. Commit - commits changes to HEAD and not to remote repository.
6. Pull - Gets the changes from the remote repository to the local repository.
7. Push - Commits the local repository changes to the remote repository.

---------------------------------------------------------------------------------------------------------

To understand when to use "git fetch" instead of "git pull", let's break it down into simpler terms with an example.

git fetch: Think of this as checking for updates. It retrieves the latest changes from a remote repository (like GitHub) but does not apply those changes to your current working files. It’s like downloading new episodes of your favorite show but not watching them yet.

git pull: This command does two things at once: it fetches the latest changes and  immediately merges them into your current files. It’s like downloading those episodes and then watching them right away.

When to Use "git fetch"

1. You Want to Review Changes First: If you're working on a project and you want to see what others have done before you integrate their changes, `git fetch` allows you to check for updates without making any changes to your own work right away.

2. Avoiding Conflicts : If you have uncommitted changes in your local files, using `git pull` could create conflicts because it tries to merge changes automatically. By using `git fetch`, you can first see what has changed and then decide how to handle it.

3. Working Offline or Later: If you're in a situation where you can't deal with merging right away (like being on a beach without Wi-Fi), you can fetch the updates now and merge them later when you're ready.

Example : Imagine you're working on a team project.

1. You’re writing code on your laptop.

2. Your teammate pushes some updates to the shared repository while you’re still working.

3. You want to see what they changed without disrupting your current work.

  git fetch origin

  This command checks for any updates from the remote repository named "origin" and downloads the latest information about those changes, but it doesn’t change any of your files yet.

4. After fetching, you can review what your teammate did:

   git log origin/main

   This shows you the commit history of the remote branch so you can see what’s new.

5. Once you're ready and have made sure there are no conflicts, you can merge those changes:

   git merge origin/main

   Now your local files are updated with your teammate’s changes.

This way , use "git fetch" when you want to keep your local repository updated without immediately affecting your working files. This gives you more control over how and when to integrate changes from others, especially useful in collaborative environments or when you're not ready to merge yet.

--------------------------------------------------------------------

The recursive clone of a Git repository:

This refers to the process of cloning a repository along with all its submodules. Submodules are essentially repositories nested inside another repository, allowing you to include external libraries or components as part of your project.

How It Works : When you perform a standard clone using the command:

git clone [repository-url]

It only clones the main repository. If that repository contains submodules, those submodule directories will be created but will remain empty until you initialize and update them.

To clone a repository along with its submodules, you use the `--recurse-submodules` option:

git clone --recurse-submodules [repository-url]

This command does the following:

1. Clones the Main Repository: It creates a local copy of the main repository.

2. Initializes Submodules: It automatically initializes any submodules defined in the ".gitmodules" file.

3. Updates Submodules: It fetches the content of those submodules, ensuring they are populated with the correct data.

Example: Imagine you have a project that relies on a library hosted in another Git repository. If you want to include this library as a submodule in your project, your main repository might look like this:

- Main Repository: "MyProject"

  - Submodule: "ExternalLibrary"

If you were to clone MyProject without the recursive option, you'd end up with:

MyProject/

├── .git/

├── ExternalLibrary/  (empty)

└── other files...

with that option 

git clone --recurse-submodules [repository-url]

You would get:

MyProject/

├── .git/

├── ExternalLibrary/  (with content)

└── other files...

Why use Recursive Clone?

1. Convenience: It saves time by automatically fetching and setting up all necessary components for your project.
2. Consistency: Ensures that all required libraries or modules are at the correct version specified in the main repository.

Using a recursive clone is essential when working with projects that depend on multiple repositories to ensure everything is correctly set up from the start.

$ git clone --recursive git@github.xyz.com:smpi/xyz-tests.git

Cloning into 'xyz-tests'...

remote: Enumerating objects: 24, done.

remote: Counting objects: 100% (24/24), done.

remote: Compressing objects: 100% (21/21), done.

remote: Total 18759 (delta 13), reused 7 (delta 3), pack-reused 18735

Receiving objects: 100% (18759/18759), 125.23 MiB | 33.33 MiB/s, done.

Resolving deltas: 100% (12772/12772), done.

Updating files: 100% (5233/5233), done.

Submodule 'smpi-ci/mtt' (https://github.com/open-mpi/mtt-legacy.git) registered for path 'smpi-ci/mtt'

Submodule 'tests/hpc-smpi-fvt' (git@github.xyz.com:smpi/hpc-smpi-fvt.git) registered for path 'tests/hpc-smpi-fvt'

Submodule 'tests/ompi-tests' (git@github.xyz.com:smpi/ompi-tests.git) registered for path 'tests/ompi-tests'

Cloning into '/data/nfs_smpi_ci/xyz-tests/smpi-ci/mtt'...

remote: Enumerating objects: 1abc, done.        

remote: Counting objects: 100% (21/21), done.        

remote: Compressing objects: 100% (18/18), done.        

remote: Total 13184 (delta 7), reused 10 (delta 3), pack-reused 13163        

Receiving objects: 100% (13184/13184), 3.94 MiB | 20.67 MiB/s, done.

Resolving deltas: 100% (8686/8686), done.

Cloning into '/data/nfs_smpi_ci/xyz-tests/tests/hpc-smpi-fvt'...

remote: Enumerating objects: 15511, done.        

remote: Total 15511 (delta 0), reused 0 (delta 0), pack-reused 15511        

Receiving objects: 100% (15511/15511), 81.99 MiB | 28.47 MiB/s, done.

Resolving deltas: 100% (10318/10318), done.

Cloning into '/data/nfs_smpi_ci/xyz-tests/tests/ompi-tests'...

remote: Enumerating objects: 36104, done.        

remote: Total 36104 (delta 0), reused 0 (delta 0), pack-reused 36104

Receiving objects: 100% (36104/36104), 103.97 MiB | 26.81 MiB/s, done.

Resolving deltas: 100% (23820/23820), done.

Submodule path 'smpi-ci/mtt': checked out 'mnccd42d37c232883d3a600ac4151868a3327b7'

Submodule path 'tests/hpc-smpi-fvt': checked out 'abc5ab4afacfacccc04dacb2c55a41477d2c02'

Submodule path 'tests/ompi-tests': checked out 'xyx7f6e194df5bbc16e836f8d63556be363a94ca5'

$ 

------------

NOTE: With version 2.13 of Git and later, --recurse-submodules can be used instead of --recursive

With  older Git , you can use:

git clone --recursive git://github.com/foo/bar.git

For already cloned repos, or older Git versions, use:

git clone git://github.com/foo/bar.git

cd bar

git submodule update --init --recursive

------------

The "git merge" :

The "git merge" command is a fundamental feature in Git that allows developers to combine changes from different branches into a single branch. This process is essential for integrating various lines of development, such as feature branches or bug fixes, into the main codebase.

What git merge Does?

1. Combines Changes: The primary function of "git merge" is to integrate the histories of two branches. When you execute "git merge <branch-name>", Git takes the changes from the specified branch and merges them into your current branch, which is often referred to as the "receiving branch".

2. Creates a Merge Commit: If the branches have diverged (i.e., both have new commits since they last shared a common ancestor), Git creates a new commit known as a merge commit. This commit has two parent commits: one from each branch being merged. This allows Git to maintain a complete history of changes.

3. Finds the Common Base: Before merging, Git identifies the common ancestor (or merge base) of the two branches. It then computes the differences (diffs) between this common ancestor and each of the branches to apply those changes simultaneously.

4. Handling Conflicts: If there are conflicting changes in the same part of a file from both branches, Git will pause the merge process and prompt you to resolve these conflicts manually. Once resolved, you can finalize the merge with a commit.

Types of Merging

1) Fast-Forward Merge: If the current branch is directly behind the branch being merged (meaning it has no new commits since their last common ancestor), Git can simply move the pointer of the current branch forward to the latest commit of the other branch without creating a new commit 

2) Three-Way Merge : When both branches have diverged, a three-way merge occurs. Here, Git uses three points (the two branch tips and their common ancestor) to create a new merge commit that reconciles changes from both branches.

Example: To illustrate how "git merge" works, let's go through a practical example involving two branches: main and feature.

1. Initial Setup: You start with a repository that has a `main` branch and you create a new branch called `feature` for development.

   git checkout -b feature main

2. Making Changes in the Feature Branch:

   You make some changes in the `feature` branch and commit them.

   # Edit some files

   git add <file>

   git commit -m "Add new feature"

3. Switching Back to Main:

   After completing your work on the "feature" branch, you switch back to the "main" branch.

   git checkout main

4. Making Additional Changes in Main: While you were working on the "feature", someone else made changes to the "main" branch. You can update it before merging:

   git pull origin main

5. Merging the Feature Branch into Main: Now, you can merge the changes from the "feature" branch into the "main" branch.

  

   git merge feature

If there are conflicting changes (e.g., both branches modified the same line in a file), Git will pause and prompt you to resolve these conflicts manually before completing the merge:

# Resolve conflicts in your editor, then stage the resolved files

git add <resolved-file>

# Complete the merge after resolving conflicts

git commit -m "Merge feature into main with conflict resolution"

Using "git merge", developers can effectively integrate changes from multiple branches, making it easier to collaborate on projects. Understanding how to handle different types of merges and resolve conflicts is crucial for maintaining a clean project history and ensuring smooth collaboration among team members.

-----------

The "git rebase" :

Git rebase is a powerful command in Git that allows you to integrate changes from one branch into another by moving the base of your current branch to a different commit. This process effectively rewrites the commit history, making it appear as though you started your work from a different point in the project history.

What Does Git Rebase Do?

1. Changing the Base: When you perform a rebase, you change the base of your current branch to a specified commit from another branch. This means that all the commits in your current branch will be reapplied on top of the new base commit, creating new commits in the process.

2. Linear History: One of the main advantages of rebasing is that it helps maintain a clean and linear project history. This is particularly useful for simplifying the commit log and making it easier to follow changes over time. Instead of having a branching structure, rebasing makes it look like all changes were made sequentially.

3. Interactive Rebasing: Git rebase can be performed in two modes: standard and interactive. The interactive mode allows you to modify commits during the rebase process, such as editing commit messages, squashing multiple commits into one, or even removing commits altogether.

To perform a standard rebase, you would typically use:

git rebase <base-branch>

For example, if you want to rebase your feature branch onto the main branch:

git checkout feature

git rebase main

This command will take all commits from "feature" and apply them on top of "main", effectively updating "feature" with the latest changes from `main`.

 Example: 

1. Initial Setup

   - You have two branches: main and feature

   - You make several commits on feature while others continue to update main.

2. Rebasing:

   - To incorporate the latest changes from main into feature, you would execute:

   git checkout feature

   git rebase main

3. Resolving Conflicts:

   - If there are conflicts during the rebase, Git will pause and allow you to resolve them. After resolving conflicts in the affected files, you would continue the rebase with:

   git add <resolved-file>

   git rebase --continue

Advantages of Git Rebase

1. Cleaner Commit History: By avoiding unnecessary merge commits, rebasing results in a more straightforward project history that is easier to read and understand.
2. Easier Debugging: A linear history simplifies tracking down bugs and understanding how features were developed over time.
3. Better Collaboration: Rebasing helps keep feature branches up-to-date with ongoing changes in the main branch, which can reduce conflicts when it's time to merge back into main.

What Happens During Rebase?

- Updating Your Work: When you run this command, Git looks at the latest commits in the `main` branch and applies your feature branch's commits as if you started working on them after the latest changes in main. This effectively updates your feature branch with any new changes that have been made in main.

- Cleaner History: Unlike merging, which creates a new commit that combines both branches (often making the history look complicated), rebasing keeps your project history neat and linear. It looks like all your work was done after the latest changes from main, even if it wasn't.

 Example : Imagine you are working on a project:

1. You create a branch called feature to add a new feature.

2. While you're working, someone else adds new updates to the main branch.

3. To ensure your feature includes those updates, you use git rebase main.

4. After running this command, your commits from feature will be placed on top of the latest commits from main, making it look like you developed your feature with all the latest updates in mind

NOTE:

While rebasing can be very useful, it is important to note that rewriting history can lead to complications if not handled carefully—especially if you've already pushed your changes to a shared repository. It’s generally advised not to rebase public branches that others may be using. 

Git rebase is a powerful tool for managing project history and integrating changes across branches while maintaining clarity and organization in your commit log.

Git rebase and the combination of `git pull` followed by `git merge` are related but not equivalent operations. Here’s a breakdown of their differences and how they function:

Git Pull vs. Git Rebase

1. Git Pull:

   - The `git pull` command is essentially a combination of two commands: git fetch followed by git merge. When you run git pull, Git fetches the latest changes from the remote branch and then merges those changes into your current branch, creating a new merge commit if necessary. This can lead to a more complex commit history with multiple merge commits, especially in collaborative environments where many changes are being made concurrently.

   git pull origin main

2. Git Rebase:

   - The git rebase command, on the other hand, takes the commits from your current branch and re-applies them on top of another branch (often the updated main branch). This effectively rewrites the commit history, creating a linear progression of commits without additional merge commits. This can make the project history cleaner and easier to follow

   git rebase main

Key Differences

History Structure: 

  - Merge: Results in a branching history with merge commits that reflect the integration points between branches.

  - Rebase: Produces a linear history that appears as if all changes were made sequentially on top of the base branch.

Conflict Resolution:

  - During a merge, if conflicts arise, you resolve them and then create a new merge commit.

  - During a rebase, conflicts must be resolved at each commit being reapplied, and you continue the rebase process after resolving each conflict

Use Cases:

  - Use git pull when you want to quickly integrate remote changes into your local branch, accepting the additional merge commit.

  - Use git rebase when you want to keep a clean history, especially in feature branches that have not yet been shared with others 

That way,  use git fetch when you want to check for updates without altering your current work, git pull for quickly updating your branch with remote changes (but be cautious of conflicts), and git merge when you want to combine different branches of work. 

Git Fork : A fork is a complete copy of a repository that allows you to make changes independently without affecting the original repository. It is often used in collaborative projects, especially on platforms like GitHub.

Purpose: Forking is typically used when you want to contribute to someone else's project. You can create your own version of the repository to experiment with or develop features without needing direct access to the original repository.

Isolation: A fork creates an entirely separate repository, meaning that changes made in your fork do not impact the original repository unless you explicitly submit a pull request.

Fprobe: Efficient Kernel Function Tracing in Linux

Fprobe is a function entry/exit probe mechanism in the Linux kernel, built on top of the ftrace framework. It allows developers to attach callbacks to function entry and exit points, similar to kprobes and kretprobes, but with improved performance for multiple functions through a single handler. This makes fprobe particularly useful for tracing and debugging kernel functions without the overhead associated with full ftrace features.

Key Features of Fprobe:

Performance: Provides faster instrumentation for multiple functions compared to traditional kprobes and kretprobes.

Structure: The fprobe structure includes fields for entry and exit handlers, allowing customized behavior when functions are entered or exited.

Registration: Fprobes can be registered using various methods, including function-name filters or direct address registration.

The usage of fprobe :

The fprobe is a wrapper of ftrace (+ kretprobe-like return callback) to attach callbacks to multiple function entry and exit. User needs to set up the struct fprobe and pass it to register_fprobe(). Typically, fprobe data structure is initialized with the entry_handler and/or exit_handler as below.

NOTE: callbacks refer to functions that are executed in response to specific events, particularly when a function is entered or exited

A typical fprobe setup might look like this:

struct fprobe fp = {
    .entry_handler = my_entry_callback,
    .exit_handler = my_exit_callback,
};
register_fprobe(&fp, "func*", "func2");

-----------------------------------------------------

Simple C program that demonstrates how to use fprobe in the Linux kernel. This program sets up an fprobe to monitor the entry and exit of a specific kernel function. For this example, we'll assume that you want to probe a function named "target_function".

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/fprobe.h>
#include <linux/init.h>

// Function prototypes
int my_entry_callback(struct fprobe *fp, unsigned long entry_ip, unsigned long args, struct pt_regs *regs, void *data);
void my_exit_callback(struct fprobe *fp, unsigned long entry_ip, unsigned long args, struct pt_regs *regs, void *data);
void target_function(void); // Declare target_function prototype

// Define the fprobe structure
static struct fprobe fp = {
    .entry_handler = my_entry_callback,
    .exit_handler = my_exit_callback,
};

// The function we want to probe
void target_function(void) {
    printk(KERN_INFO "Inside target_function\n");
}

// Entry callback
int my_entry_callback(struct fprobe *fp, unsigned long entry_ip, unsigned long args, struct pt_regs *regs, void *data) {
    printk(KERN_INFO "Entered target_function\n");
    return 0; // Return an int as expected
}

// Exit callback
void my_exit_callback(struct fprobe *fp, unsigned long entry_ip, unsigned long args, struct pt_regs *regs, void *data) {
    printk(KERN_INFO "Exited target_function\n");
}

// Module initialization
static int __init my_module_init(void) {
    // Register the fprobe for the target function
    if (register_fprobe(&fp, "target_function", NULL)) {
        printk(KERN_ERR "Failed to register fprobe\n");
        return -1;
    }

    printk(KERN_INFO "Fprobe registered successfully\n");

    // Call the target function to see the callbacks in action
    target_function();

    return 0;
}

// Module cleanup
static void __exit my_module_exit(void) {
    // Unregister the fprobe
    unregister_fprobe(&fp);
    printk(KERN_INFO "Fprobe unregistered successfully\n");
}

module_init(my_module_init);
module_exit(my_module_exit);

MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Fprobe Example Module");
MODULE_AUTHOR("SACHIN P BAPPALIGE");

--------------------------------------------------------------------------

Compilation and Loading:

Step 1 : Save the code in a file named fprobe_example.c.

Step 2 : Create a Makefile as shown below

obj-m += fprobe_example.o

all:
    make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
    make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

--------------------------------------

# make
make -C /lib/modules/6.12.0-rc2+/build M=/root/fprobe modules
make[1]: Entering directory '/root/linux'
  CC [M]  /root/fprobe/fprobe_example.o
  MODPOST /root/fprobe/Module.symvers
  CC [M]  /root/fprobe/fprobe_example.mod.o
  CC [M]  /root/fprobe/.module-common.o
  LD [M]  /root/fprobe/fprobe_example.ko
  BTF [M] /root/fprobe/fprobe_example.ko
make[1]: Leaving directory '/root/linux'

# ls

Makefile  Module.symvers  fprobe_example.c  fprobe_example.ko  fprobe_example.mod  fprobe_example.mod.c  fprobe_example.mod.o  fprobe_example.o  modules.order

--------------------------------------------------

Step 3 : Insert module-->  insmod fprobe_example.ko

Step 4: Check kernel logs with dmesg to see output from the callbacks.

Step 5: Remove the module using  -->  rmmod fprobe_example

Here’s a C program that demonstrates how to use fprobe to monitor the do_fork function in the Linux kernel. This example sets up entry and exit callbacks to log when the do_fork function is called and when it returns.

-------------------------------------

#include <linux/module.h>

#include <linux/kernel.h>

#include <linux/fprobe.h>

#include <linux/init.h>

#include <linux/sched.h>

// Function prototypes for the entry and exit callbacks

int my_entry_callback(struct fprobe *fp, unsigned long entry_ip, unsigned long args, struct pt_regs *regs, void *data);

void my_exit_callback(struct fprobe *fp, unsigned long entry_ip, unsigned long args, struct pt_regs *regs, void *data);

// Define the fprobe structure

static struct fprobe fp = {

    .entry_handler = my_entry_callback,

    .exit_handler = my_exit_callback,

};

// Entry callback for do_fork

int my_entry_callback(struct fprobe *fp, unsigned long entry_ip, unsigned long args, struct pt_regs *regs, void *data) {

    printk(KERN_INFO "do_fork called: PID = %d\n", current->pid);

    return 0; // Return an int as required

}

// Exit callback for do_fork

void my_exit_callback(struct fprobe *fp, unsigned long entry_ip, unsigned long args, struct pt_regs *regs, void *data) {

    printk(KERN_INFO "do_fork returned: PID = %d\n", current->pid);

}

// Module initialization function

static int __init my_module_init(void) {

    // Register the fprobe for the do_fork function

    if (register_fprobe(&fp, "do_fork", NULL)) {

        printk(KERN_ERR "Failed to register fprobe for do_fork\n");

        return -1;

    }

    printk(KERN_INFO "Fprobe registered successfully for do_fork\n");

    return 0;

}

// Module cleanup function

static void __exit my_module_exit(void) {

    // Unregister the fprobe

    unregister_fprobe(&fp);

    printk(KERN_INFO "Fprobe unregistered successfully for do_fork\n");

}

module_init(my_module_init);

module_exit(my_module_exit);

MODULE_LICENSE("GPL");

MODULE_DESCRIPTION("Fprobe Example for do_fork");

MODULE_AUTHOR("SACHIN P BAPPALIGE");

------------------------------------------------------------------------------

NOTE: Fprobe and kprobe are both mechanisms used in the Linux kernel for tracing and debugging, but they have distinct characteristics and use cases.

Kprobe :

Purpose: Kprobes allow developers to insert probes at almost any kernel function entry or exit point. They enable dynamic instrumentation by setting breakpoints on specified functions.

Structure: Each kprobe consists of a handler that is invoked when the probe is hit, allowing for custom actions or logging.

Performance: Kprobes can introduce overhead, especially when multiple probes are registered, as they rely on software breakpoints (SWBP) which can be slower compared to other methods.

Recursion Handling: Kprobes maintain a per-CPU variable (`current_kprobe`) to manage recursion safely, which prevents re-entry into the same probe handler.

Developers commonly probe various Linux kernel functions to gather insights about system performance, debug issues, and monitor behavior. Here are some typical functions that are often probed:

Commonly Probed Kernel Functions : 

1)  do_fork: Used for process creation. Probing this function can help track process spawning and resource allocation.

2)  sys_read / sys_write: These functions handle system calls for reading from and writing to files. Probing them allows developers to monitor file I/O operations.

3)  schedule: Responsible for context switching between processes. Probing this function can provide insights into scheduling behavior and CPU usage.

4)  kmalloc / kfree: Functions for memory allocation and deallocation in the kernel. Probing these can help identify memory usage patterns and potential leaks.

5)  vfs_read / vfs_write:Virtual filesystem layer functions that manage file operations. Probing these functions helps in understanding file access patterns across different filesystems.

7)  tcp_sendmsg / tcp_recvmsg:Used for sending and receiving TCP messages. Probing these can assist in analyzing network performance and behavior.

8)  netif_receive_skb: This function processes incoming packets in the network stack. Probing it can help monitor network traffic handling.

9)  exit_notify: Handles the cleanup of a process upon exit. Probing this function can track process termination and resource cleanup.

10) __wake_up: Used to wake up processes waiting on a condition variable. Probing this can provide insights into synchronization and concurrency issues.

11) File System Operations: Functions like lookup, create, and unlink are also commonly probed to monitor filesystem interactions

In summary, while both kprobe and fprobe serve the purpose of tracing kernel functions, fprobe is tailored for efficiency and ease of use in scenarios requiring multiple function tracing. Kprobes offer broader capabilities but at the cost of performance overhead and complexity.

Reference :

1) https://docs.kernel.org/trace/fprobe.html

Kprobes in Action : Instrumenting and Debugging the Linux Kernel

Kprobes (Kernel Probes) is a powerful feature in the Linux kernel that allows developers and system administrators to dynamically intercept and monitor any kernel function. It provides a mechanism for tracing and debugging the kernel by enabling you to inject custom code into almost any point in the kernel, allowing you to collect information, modify data, or even create entirely new behaviors. Kprobes are particularly useful for diagnosing kernel issues, performance tuning, and understanding kernel behavior without needing to modify the kernel source code or reboot the system.

Background on Kprobes:

Kprobes were introduced in the Linux kernel as a way to enable non-disruptive kernel tracing. The main use case is dynamic instrumentation, which allows developers to investigate how the kernel behaves at runtime without modifying or recompiling the kernel.

How Kprobes Work

Kprobes allow you to place a "probe" at a specific point in the kernel, known as a probe point. When the kernel execution reaches this probe point, the probe is triggered, and a handler function that you define is executed. Once the handler is done, the normal execution of the kernel resumes.

There are two types of handlers in Kprobes:

1. Pre-handler: This is executed just before the probed instruction.

2. Post-handler: This is executed after the probed instruction completes.

Key Components of Kprobes:

1. Kprobe Structure : Defines the probe, including the symbol name (function to be probed) and pointers to pre- and post-handlers.

   - Example:

     static struct kprobe kp = {
         .symbol_name = "do_fork",  // Name of the function to probe
     };

2. Pre-Handler: Executed before the instruction at the probe point. It can be used to capture the state of the system (e.g., register values).

   - Example:

     static int handler_pre(struct kprobe *p, struct pt_regs *regs) {
         printk(KERN_INFO "Pre-handler: register value is %lx\n", regs->ip);
         return 0;
     }

3. Post-Handler: Executed after the instruction at the probe point. This is useful for gathering information after the instruction has executed.

   - Example:

     static void handler_post(struct kprobe *p, struct pt_regs *regs, unsigned long flags) {
         printk(KERN_INFO "Post-handler: instruction completed\n");
     }

Inserting a Kprobe:

Once the Kprobe structure is set up, you register the probe using the `register_kprobe()` function, which activates the probe at the desired location in the kernel.

Example of inserting a probe:

int ret = register_kprobe(&kp);
if (ret < 0) {
    printk(KERN_ERR "Kprobe registration failed\n");
} else {
    printk(KERN_INFO "Kprobe registered successfully\n");
}

When you're done with the probe, it should be unregistered using `unregister_kprobe()`.

Use Cases for Kprobes:

1. Debugging: Inspect kernel function behavior and parameters at runtime without recompiling the kernel.

2. Performance Monitoring: Collect detailed performance statistics at various points in the kernel.

3. Dynamic Analysis: Understand kernel module or driver behavior in real-time.

4. Fault Injection: Inject faults at specific points in the kernel to test how the kernel reacts to errors.

5. Security Auditing: Monitor suspicious or unauthorized kernel activities.

Kprobes vs. Other Tracing Mechanisms:

- Ftrace: Another kernel tracing framework, but more focused on function-level tracing. Kprobes are more versatile as they allow you to probe any instruction.

- SystemTap**: Provides a higher-level interface that uses Kprobes under the hood.

- eBPF: A more modern, flexible, and performant tracing framework that has overlapping functionality with Kprobes.

Kprobe Variants:

1. Jprobes**: A variant that allows you to specify the exact function signature for the probe. This feature is deprecated in modern kernels.

2. Kretprobes**: A specialized form of Kprobes that hooks into the return path of functions, allowing you to trace function exits and the values returned by kernel functions.

Limitations of Kprobes:

- Probes introduce overhead, so excessive probing can impact system performance.

- Probing certain sensitive or timing-critical functions can lead to system instability.

- The handler code should be minimal and non-blocking to avoid disrupting the kernel execution flow.

Example Code:

Below is a basic example of how Kprobes can be used to monitor the `do_fork` function in the kernel, which is responsible for process creation:

#include <linux/kernel.h>
#include <linux/module.h>

#include <linux/kprobes.h>

static struct kprobe kp = {
    .symbol_name = "do_fork", // The function to probe
};

static int handler_pre(struct kprobe *p, struct pt_regs *regs) {
    printk(KERN_INFO "do_fork() called, IP = %lx\n", regs->ip);
    return 0;
}

static void handler_post(struct kprobe *p, struct pt_regs *regs, unsigned long flags) {
    printk(KERN_INFO "do_fork() completed\n");
}

static int __init kprobe_init(void) {
    kp.pre_handler = handler_pre;
    kp.post_handler = handler_post;
   
    if (register_kprobe(&kp) < 0) {
        printk(KERN_ERR "Kprobe registration failed\n");
        return -1;
    }
    printk(KERN_INFO "Kprobe registered successfully\n");
    return 0;
}

static void __exit kprobe_exit(void) {
    unregister_kprobe(&kp);
    printk(KERN_INFO "Kprobe unregistered\n");
}

module_init(kprobe_init);
module_exit(kprobe_exit);
MODULE_LICENSE("GPL");

This will print information to the kernel log each time the `do_fork()` function is invoked.

To compile and run the Kprobe example you provided, you need to follow these steps:

1. Prerequisites

- You need to have the Linux kernel headers installed.

- Make sure you have root (superuser) privileges, as you'll be loading kernel modules.

- You need `gcc` and `make` installed for compiling the kernel module.

  yum search glibc-static
  yum install glibc-static
  yum update --allowerasing

2. Write the Kprobe Kernel Module

   wget  https://raw.githubusercontent.com/torvalds/linux/master/samples/kprobes/kprobe_example.c

   Save the Kprobe code into a file, for example, `kprobe_example.c`:

3. Create a Makefile

Create a `Makefile` to automate the compilation of the kernel module. This Makefile should look like this:

makefile
obj-m += kprobe_example.o
all:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

4. Compile the Kprobe Kernel Module

$ make

This will use the kernel headers and create a module file `kprobe_example.ko`.

5. Insert the Kernel Module

To insert the module into the running kernel, use the `insmod` command. You need root privileges to load kernel modules:

$  insmod kprobe_example.ko

 6. Check Kernel Logs for Output

You can monitor the kernel logs to see the output of the Kprobe:

$ dmesg | tail

[18084.207866] kprobe_init: Planted kprobe at 00000000207be762

This will show you the success or failure of inserting the Kprobe and print any trace outputs when the kernel function (like `do_fork`) is invoked.

7. Trigger the Probed Function

You can manually trigger the `do_fork()` function by starting a new process, such as running any command: $ ls

Since `do_fork()` is involved in creating new processes, every time a new process is created, the Kprobe pre- and post-handlers will execute, and you'll see the output in `dmesg`.

8. Remove the Kernel Module

Once you're done with the Kprobe, you can remove the kernel module using `rmmod`:

$  rmmod kprobe_example

[root@myhost]# lsmod | grep probe
kprobe_example          3569  0
[root@myhost]# ls
[root@myhost]# rmmod kprobe_example
[root@myhost]# lsmod | grep probe
[root@myhost]#

Check the kernel log again to see the output confirming the Kprobe has been removed:

$ dmesg | tail

9. Clean Up

To clean the build directory and remove compiled files, you can run:

$ make clean

--------------------------------------------------------------------------------------------------------

Example Workflow:

$ vim kprobe_example.c                # Write the module code

$ vim Makefile                               # Create the Makefile

$ make                                             # Compile the module

$ insmod kprobe_example.ko          # Insert the module

$ dmesg | tail                                   # Check kernel logs for output

$ ls                                                    # Trigger the do_fork() function

$ dmesg | tail                                    # Check logs again to see Kprobe output

$ sudo rmmod kprobe_example      # Remove the module

$ make clean                                    # Clean up the build files

NFS (Network File System) : NFS Server and NFS Client configuration

NFS, or Network File System, is a distributed file system protocol developed by Sun Microsystems in 1984. It allows a system to share directories and files with others over a network. With NFS, users and applications can access files on remote systems as if they were local, enabling seamless file sharing across different systems, architectures, and locations.

Key Features of NFS:

- Transparency: NFS provides users with transparent access to files on a remote server as if they were located on their local machine.

- Interoperability: NFS is platform-independent, allowing different operating systems to communicate and share files across a network.

- Statelessness: In its early versions, NFS was designed to be stateless, meaning that the server did not maintain session information for clients. This design provided resilience but also led to limitations in reliability and consistency.

- Security: Over time, NFS introduced several security improvements, including support for Kerberos authentication in NFSv4.

History and Evolution of NFS :

1. NFSv1 (1984):

   - NFS was initially developed by Sun Microsystems as a way to provide network file sharing in SunOS.
   - It was proprietary to Sun and served as an early attempt to allow file sharing across systems in a networked environment.

2. NFSv2 (1989):

   - The first widely available version, NFSv2, was introduced in RFC 1094.
   - It operated using the User Datagram Protocol (UDP) for fast, connectionless communication.
   - NFSv2 supported only 32-bit file sizes, which limited its scalability as file sizes grew.
   - It used a stateless protocol, meaning the server didn’t keep track of clients, which simplified server-side management but limited its capabilities for complex applications.

3. NFSv3 (1995):

   - Introduced in RFC 1813, NFSv3 addressed many limitations of NFSv2.
   - Improvements:
     - Larger file size support with 64-bit file handling.
     - Asynchronous Writes: To improve performance, NFSv3 allowed asynchronous writes, meaning the client could continue            writing without waiting for server acknowledgment.
     - Introduced support for TCP, allowing for better reliability in file transfers over unreliable networks.
     - Still stateless but more robust in handling large workloads.

4. NFSv4 (2003):

   - Defined in RFC 3530, NFSv4 represented a significant evolution from previous versions.
   - Major Features:
     - Stateful Protocol: NFSv4 introduced statefulness, allowing for better handling of file locks and recovery from network                failures.
     - Security: NFSv4 incorporated stronger security features, including support for Kerberos and improved ACLs (Access                  Control Lists).
     - Single Port: NFSv4 used a single well-known port (2049), which simplified firewall configuration.
     - Performance Optimizations: NFSv4 added features like compound operations and better caching mechanisms to enhance            performance in WAN environments.
   - Cross-Platform: As a stateful and more secure protocol, NFSv4 gained popularity across different Unix-like systems and               was widely adopted in enterprise environments.

5. NFSv4.1 (2010):

   - Introduced pNFS (parallel NFS), allowing clients to read and write files in parallel, which improved performance for large, distributed workloads.
   - Sessions: NFSv4.1 introduced sessions, providing reliable and robust mechanisms for handling multiple file operations.

6. NFSv4.2 (2016):

   - Added new features like server-side cloning, application I/O hints, and a standardized method for handling holes in sparse files.

NFS Server Configuration : 

1. Install NFS Utilities:

   First, install the NFS server utilities (`nfs-utils`) using `dnf`. This package provides essential NFS-related services and tools, including `rpcbind`, `nfsd`, and other utilities needed for the NFS server to function.

   dnf install nfs-utils -y

2. Manage Firewall:

   If the firewall is running, it can block NFS traffic by default. Use these commands to check the status, stop, or disable the firewall. If security is a concern, you should configure the firewall to allow NFS traffic on specific ports instead of turning it off entirely.

   systemctl status firewalld

   systemctl stop firewalld

   systemctl status firewalld

If you need to keep the firewall running, ensure you open the following ports for NFS:

   firewall-cmd --add-service=nfs --permanent

   firewall-cmd --reload

3. Start and Enable NFS Services:

   To make the NFS server persist across reboots, enable and start the `nfs-server.service`. The NFS server will provide access to the shared directories over the network.

   systemctl start nfs-server.service

   systemctl enable nfs-server.service

   systemctl status nfs-server.service

4. Restart `rpcbind` and `nfs-utils` Services:

   NFS requires RPC (Remote Procedure Call) services to operate, specifically the `rpcbind` service. Restart `rpcbind` and `nfs-utils` to ensure proper functioning of NFS.

   systemctl restart rpcbind.service

   systemctl restart nfs-utils.service

5. Create a Directory to Share:

   Create the directory that you want to export (share) over NFS. For example, in this case:

   mkdir /sachinpb

   

6. Configure NFS Exports:

   Edit the `/etc/exports` file to configure the directory export settings. This file defines which directories will be shared over NFS and the permissions for each directory.

   edit  /etc/exports  ==> /sachinpb *(rw,async,no_root_squash)

Add the following line to export the `/sachinpb` directory to all clients (`*`), with read-write access, asynchronous mode (`async`), and no root squashing (`no_root_squash`):

Here’s what these options mean:
   - `rw`: Clients can read and write to the shared directory.
   - `async`: Writes to the shared directory will be cached, improving performance.
   - `no_root_squash`: The root user on the client will have root privileges on the NFS share. Use with caution, as it could pose security risks.

7. Apply Export Settings:

   After updating `/etc/exports`, use `exportfs` to apply the export settings:

   exportfs -a

   You can verify the shared directories using `showmount`:

  showmount -e

8. Test NFS Server:

   Navigate to the shared directory and create a test file to verify that the NFS export is accessible.

   cd /sachinpb
   touch file1

NFS Client Configuration

1. Manage Firewall:

   As with the server, the firewall on the client might block NFS traffic. If needed, stop the firewall or configure it to allow NFS traffic. Check and stop the firewall:

   systemctl status firewalld
   systemctl stop firewalld

2. Install NFS and RPC Utilities:

   Install the required packages on the client side. The `nfs-utils` package provides the necessary utilities for mounting NFS shares, and `rpcbind` is essential for NFS communication.

   dnf install rpc* -y
   dnf install nfs-utils -y

3. Create a Mount Point:

   Create a directory on the client machine where the NFS share will be mounted. This directory acts as the local mount point for the NFS share.

mkdir /sachinpb

4. Mount the NFS Share:

   Use the `mount` command to mount the NFS share from the server. Replace `9.53.174.120` with the actual IP address or hostname of your NFS server:

   mount -t nfs 9.x.y.12:/sachinpb /sachinpb

OR, you can also add this in /etc/fstab file  as shown below :

# cat /etc/fstab
9.x.y.12:/sachinpb     /sachinpb  nfs     defaults        0 0

followed by mount -a

This command mounts the `/sachinpb` directory from the NFS server onto the `/sachinpb` directory on the client.

5. Verify the Mount:

   Change to the mounted directory and check if the contents from the NFS server are visible on the client machine:

    cd /sachinpb

   If the mount is successful, you should see the `file1` created earlier on the NFS server.

Mastering Remote Server Management with Python's Paramiko Library

Paramiko is a powerful Python library that implements the SSH (Secure Shell) protocol, specifically SSHv2. It provides both client and server functionality, making it suitable for a variety of tasks involving secure remote connections. Here are the main features and uses of Paramiko.

1) SSH Protocol Implementation:

Paramiko is a pure-Python implementation of the SSHv2 protocol, allowing secure communication over unsecured networks. It supports both client and server functionalities, enabling users to create secure connections and transfer data securely.

2) Client and Server Functionality:

As a client, Paramiko can connect to remote servers, execute commands, and transfer files securely using SFTP (SSH File Transfer Protocol).

As a server, it can accept incoming SSH connections, allowing users to run their own SSH servers in Python.

3) High-Level API:

The library provides a high-level API that simplifies common tasks such as executing remote shell commands or transferring files. This makes it easier for developers to implement SSH functionality without dealing with the complexities of the underlying protocol.

4) Cryptography Support:

Paramiko relies on the cryptography library for cryptographic functions. This library uses C and Rust extensions to provide secure encryption methods necessary for implementing SSH.

5) Key Management:

It supports various authentication methods, including password-based authentication and public/private key pairs. Users can manage host keys and perform host key verification to enhance security.

6) Extensibility:

While Paramiko is powerful on its own, it also serves as the foundation for higher-level libraries like Fabric, which further simplify remote command execution and file transfers.

Common Use Cases

1. Remote Command Execution: Automating tasks by executing shell commands on remote servers.
2. File Transfers: Securely transferring files between local and remote systems using SFTP.
3. System Administration: Automating system administration tasks across multiple servers in a secure manner.
4. Integration with Other Tools: Often used in conjunction with other Python libraries and frameworks to enhance functionality in deployment scripts or DevOps tools.

Pre-requisites:

• python -m pip install --upgrade pip
• dnf install rust*

Consider using a virtual environment to avoid conflicts with system packages. You can create one using:

• python3 -m venv myenv
• source myenv/bin/activate

(myenv) [root@my-host ~]# pip3 install paramiko
Collecting paramiko
Successfully built bcrypt cryptography
Installing collected packages: pycparser, bcrypt, cffi, pynacl, cryptography, paramiko
Successfully installed bcrypt-4.2.0 cffi-1.17.1 cryptography-43.0.1 paramiko-3.5.0 pycparser-2.22 pynacl-1.5.0
(myenv) [root@my-host ~]#

 

To SSH into a remote host and run the ANY command using Python, you can use the Paramiko library. Below is a code snippet that demonstrates how to do this. 

------------------python code-------------------------------------

import paramiko

def ssh_ls_command(hostname, username, password):

    try:

        # Create an SSH client instance

        ssh = paramiko.SSHClient()

        # Automatically add the server's host key (for simplicity)

        ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())

        # Connect to the remote host

        ssh.connect(hostname, username=username, password=password)

        # Execute the 'ls' command

        stdin, stdout, stderr = ssh.exec_command('ls')

        # Read the output from stdout

        output = stdout.read().decode()

        error = stderr.read().decode()

        # Close the SSH connection

        ssh.close()

        if output:

            print("Output of 'ls' command:")

            print(output)

        if error:

            print("Error:")

            print(error)

    except Exception as e:

        print(f"An error occurred: {e}")

# Example usage

hostname = 'remote-host.com'

username = 'root'

password = 'mypassword'

ssh_ls_command(hostname, username, password)

where :

• Importing Paramiko: The script starts by importing the paramiko library.
• Creating SSH Client: An instance of SSHClient is created to manage connections.
• Host Key Policy: The set_missing_host_key_policy method is used to automatically add the server's host key. This is convenient for testing but should be handled more securely in production.
• Connecting: The connect method establishes a connection to the remote host using the provided hostname, username, and password.
• Executing Command: The exec_command method runs the specified command (ls in this case) on the remote server.
• Reading Output: The standard output and error are read and printed.
• Error Handling: Any exceptions during the process are caught and displayed.

--------------------------------------------------------------------------

OUTPUT:

(myenv) [root@my-host ~]# python3 ssh.py
Output of 'ls' command:
anaconda-ks.cfg
kernel-6.11.0-0.rc5.22.el10.src.rpm
linux
original-ks.cfg
rpmbuild
test_tunnel.c
test_tunnel_kern.c
(myenv) [root@my-host ~]#

----------------------------------------------------------------------------

Paramiko is an essential tool for Python developers who need to implement secure communication over SSH. Its ease of use, combined with robust features for managing SSH connections and executing commands remotely, makes it a popular choice for automation and system administration tasks.

CMA (Contiguous Memory Allocator) - Linux Memory Management Mechanism

CMA (Contiguous Memory Allocator) in Linux is a memory management mechanism designed to provide large contiguous blocks of physical memory for specific use cases, such as DMA (Direct Memory Access) operations or device drivers that require continuous memory regions. When discussing CMA (Contiguous Memory Allocator), it's crucial to focus on physical memory*rather than virtual memory due to the specific requirements of devices and hardware components that rely on direct access to memory. physical memory is referenced instead of virtual memory in the context of CMA.

Purpose:

Some hardware, like certain device drivers or subsystems (e.g., graphics or networking devices), need large chunks of physically contiguous memory. However, as Linux uses a virtual memory system, physical memory can become fragmented over time. CMA ensures that these devices get the required memory, even if the system is fragmented.

How it Works:

   - CMA reserves a portion of memory at boot time, which can later be allocated in contiguous blocks when requested.

   - During normal system operation, this reserved memory isn't locked away—it can be used for general purpose allocations. However, when a contiguous allocation request comes, this memory is freed and given to the device or driver that requested it.

Device and Hardware Requirements:

   - Certain hardware components (like GPUs, network cards, or other peripherals) require contiguous blocks of physical memory for  DMA (Direct Memory Access) operations or other high-performance activities.

   - DMA is a process where devices communicate directly with the physical memory without the CPU's intervention. For DMA to work efficiently, the hardware needs physically contiguous memory, meaning that the memory addresses are adjacent in physical memory.

   - Virtual memory is designed to make efficient use of available memory for software processes, but virtual memory can be fragmented and non-contiguous in physical memory. This is because virtual memory maps logical addresses to scattered physical memory locations.

CMA Guarantees Physical Contiguity:

 The key feature of CMA is that it reserves a contiguous region of physical memory that can be allocated on demand. Virtual memory, on the other hand, is not necessarily contiguous in physical terms.

   - Even though processes use virtual addresses (which are convenient for applications), the underlying devices or drivers that require DMA or large contiguous blocks of memory need physical addresses, and CMA ensures that this need is met.

Physical vs. Virtual Memory:

   - Physical Memory: Refers to the actual RAM installed in the system. It's where data is physically stored, and it must be contiguous for hardware operations.

   - Virtual Memory: Is an abstraction provided by the operating system that allows applications to use more memory than physically available. It is divided into pages, which can be scattered across different locations in physical memory.

For example, a 4 GB virtual address space could be mapped to non-contiguous physical memory chunks. However, if a device needs to access a block of memory directly through DMA, the physical memory it accesses must be contiguous.

Virtual Memory Can’t Be Used Directly for DMA or Hardware Access: 

   - Virtual memory is designed for software abstraction and can be fragmented across the physical memory. This is fine for applications but unsuitable for devices that require access to memory in a sequential physical block.

   - When devices perform DMA, they must work with real physical addresses. Therefore, allocating memory in virtual space doesn’t meet the requirement unless the physical memory behind those virtual addresses is also contiguous, which is why CMA allocates from physical memory directly.

How CMA Works with Physical Memory:

   - CMA reserves a chunk of  physical memory at boot time that can later be allocated in contiguous blocks when requested by the device drivers. It does so to ensure that even when the system’s physical memory becomes fragmented, there will still be a large contiguous block of physical memory available for hardware components.

   - Although this memory is allocated from the physical address space, it can be used by virtual memory applications when it's not being actively used by a device.

CMA deals with physical memory because certain devices and hardware require contiguous blocks of physical RAM for tasks like DMA. Virtual memory, which can be fragmented across different physical locations, doesn't meet the needs of these operations. Physical memory contiguity ensures that devices can perform high-speed data transfers efficiently, whereas virtual memory, though beneficial for applications, cannot guarantee this contiguity.

CMA Allocation and Range:

   - CMA typically reserves a contiguous memory range at boot time based on system configuration or kernel parameters. The location and size of the CMA region are either:

     - Automatically determined by the kernel based on memory requirements.

     - Specified manually using kernel boot parameters.

   - CMA memory is reserved in the physical memory address space and is set aside as a separate region from the rest of the memory.

Kernel Boot Parameters:

   - The size and location of the CMA region can be controlled via kernel boot parameters, such as:

     - `cma=size[M/G]`: Specifies the size of the CMA region. For example, `cma=512M` would reserve                     512 MB for CMA.

     - `cma_start=address`: Specifies the starting address of the CMA region in the physical memory.

     - `cma_end=address`: Specifies the ending address of the CMA region.

   Example:

   cma=256M cma_start=0x20000000 cma_end=0x30000000

   This reserves 256 MB for CMA starting at the physical address `0x20000000`.

Where is CMA Allocated?:

   - CMA is allocated during boot time and usually resides in the lower end of the physical memory to ensure that DMA or other hardware requests can access it easily.

   - CMA allocations can be made in any part of the memory, but it usually starts from a specific predefined region (if not defined manually).

6. Checking CMA Information in Linux:

   You can get details about CMA configuration by looking at certain files in the `/proc` or `/sys` filesystems:

/proc/meminfo: This file contains general memory information, including CMA. You can find the CMA reserved region under the entry `CmaTotal` and the currently used CMA memory under `CmaFree`.

     Example:

     CmaTotal:  262144 kB

     CmaFree:   131072 kB

/sys/kernel/debug/cma: If CMA debugging is enabled, this directory will provide detailed information about the CMA memory allocations.

Example to View CMA Memory: cat /proc/meminfo | grep Cma

Output might look like this

CmaTotal:         524288 kB

CmaFree:          512000 kB

This tells you the total reserved CMA memory (`CmaTotal`) and the currently available CMA memory (`CmaFree`).

Summary:

- CMA is allocated at boot and reserves contiguous memory blocks for devices needing such memory.

- It can be specified using boot parameters (size, start, and end address).

- The reserved memory is used by the system when no contiguous memory requests are made and freed when needed for such operations.

- You can check the allocation and usage through system files like `/proc/meminfo`.

========================FADUMP=========================================

Firmware assisted dump (fadump) is a dump capturing mechanism provided as a reliable alternative to kdump on IBM POWER systems. The fadump utility captures the vmcore file from a fully-reset system with PCI and I/O devices. This mechanism uses firmware to preserve memory regions during a crash and then reuses the kdump userspace scripts to save the vmcore file. The memory regions consist of all system memory contents, except the boot memory, system registers, and hardware Page Table Entries (PTEs).

The fadump mechanism offers improved reliability over the traditional dump type, by rebooting the partition and using a new kernel to dump the data from the previous kernel crash. 

README: /usr/share/doc/kexec-tools/fadump-howto.txt

In the Secure Boot environment, the GRUB2 boot loader allocates a boot memory region, known as the Real Mode Area (RMA). The RMA has a size of 512 MB, which is divided among the boot components and, if a component exceeds its size allocation, GRUB2 fails with an out-of-memory (OOM) error.

Options for Using fadump:

fadump=on:  This is the default setting for enabling fadump. It reserves memory from a special area called **CMA (Contiguous Memory Allocator)**. Think of this as a memory-saving technique that allows some of this reserved memory to still be used by other parts of the system during normal operation. The idea is to avoid wasting memory that would otherwise sit idle.

fadump=nocma: This option tells the system not to use the special CMA-backed memory for fadump. Instead, it reserves a portion of memory separately and completely, which might be useful if you want to capture more detailed information, like user-level data, during a crash. By not using CMA, this memory is reserved exclusively for fadump and isn't used for other tasks while the system is running.

fadump=on: Imagine you have a spare room (memory) in your house. Normally, you leave it empty just in case you need to store something later (for fadump). But with this setting, you let guests use the room for sleeping when you don’t need it. When something goes wrong (system crash), you ask them to leave so you can use it to store important things (dump data).

 fadump=nocma: Now, if you set the option to nocma, it's like keeping that spare room off-limits to guests at all times, so it's always ready for storing important stuff whenever you need it.

fadump=on (default): Allows the reserved memory to be used for other tasks when the system is working normally, saving memory.

fadump=nocma : Keeps the reserved memory off-limits to other tasks, ensuring that it's available for storing more detailed data during a crash.

The system with SLES distro will  automatically choose  whether to use `fadump=nocma` or `fadump=on`, depending on the KDUMP_DUMPLEVEL setting. On RHEL based systems , you can set fadump=on /fadump=nocma using grubby command followd by reboot. Or else you can add "/etc/default/grub" file to add these options and run "grub2-mkconfig -o /boot/grub2/grub.cfg"

KDUMP_DUMPLEVEL determines how much information is captured in a system crash. If it’s set to exclude user pages, the system will automatically use `fadump=on` (the default behavior). But, if user pages are **included** in the dump, it will switch to `fadump=nocma`.

Multipath setup in Linux

A multipath setup in Linux is a configuration that allows multiple physical paths (usually represented by multiple physical storage devices or network connections) to be used to access a single logical device or storage target. The primary goal of multipath is to enhance redundancy and fault tolerance while providing load balancing and improved performance. Multipath is commonly used in storage area networks (SANs) and environments where high availability and reliability are critical.

Here are the key components and concepts of a multipath setup in Linux:

Multipath Devices (Multipath): In a multipath setup, there is a logical device known as a multipath device (often referred to as a multipath or mpath). This logical device represents a single storage target, such as a disk or LUN (Logical Unit Number), even though it is accessible through multiple physical paths.

Physical Paths: Physical paths are the actual connections or channels through which the storage target is accessible. These paths can be physical SCSI buses, Fibre Channel links, iSCSI connections, or any other transport mechanism. Each path is associated with a unique identifier, typically called a World Wide Name (WWN), device name, or other similar identifiers.

Path Management: The multipath software in Linux (such as multipathd and multipath-tools) manages the physical paths and ensures that they are utilized effectively. It monitors the status of the paths and makes decisions about which path to use for I/O operations. It can also detect and respond to path failures or changes in path availability.

Load Balancing: Multipath configurations often include load balancing mechanisms that distribute I/O requests across the available paths. This helps improve performance by distributing the workload and preventing one path from becoming a bottleneck.

Redundancy and Failover: Multipath setups provide redundancy and failover capabilities. If one path fails due to hardware or network issues, the system can automatically switch to an alternate path without interrupting I/O operations. This enhances system reliability and availability.

Device Mapper (DM-Multipath): In Linux, the Device Mapper subsystem is commonly used to manage multipath devices. DM-Multipath is a kernel component that works with the multipath software to create and manage multipath devices. It presents a single device to the operating system, which is actually a combination of the multiple physical paths.

Configuration Files: To set up multipath in Linux, administrators configure multipath settings using configuration files. The main configuration file is typically located at /etc/multipath.conf (or a similar location) and defines the behavior of the multipath devices.

Multipath Tools: The multipath tools package (multipath-tools or similar) includes utilities such as multipath and multipathd that are used to manage and configure multipath devices. These tools help monitor path status, configure load balancing policies, and perform other administrative tasks related to multipathing.

-----------------------------------

For Example : This system is using multipath and LVM for storage management to provide redundancy and flexibility in managing storage devices. Both sda and sdb are part of the multipath configuration, and their partitions are managed using LVM. This setup is commonly used in enterprise environments for high availability and fault tolerance

There are three partitions on the multipath device mpatha (which represents both sda and sdb due to multipathing). 

The lsblk command is used to list block devices on this system, displaying information about disks, partitions, and their relationships. Let's break down the lsblk output:

----------------------------------------------------------------------------------------

#lsblk

NAME                            MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT

sda                               8:0    0   80G  0 disk

└─mpatha                        253:0    0   80G  0 mpath

  ├─mpatha1                     253:1    0    4M  0 part

  ├─mpatha2                     253:2    0    1G  0 part  /boot

  └─mpatha3                     253:3    0   79G  0 part

    ├─rhel_myhost-root 253:4    0 47.7G  0 lvm   /

    ├─rhel_myhost-swap 253:5    0    8G  0 lvm   [SWAP]

    └─rhel_myhost-home 253:6    0 23.3G  0 lvm   /home

sdb                               8:16   0   80G  0 disk

└─mpatha                        253:0    0   80G  0 mpath

  ├─mpatha1                     253:1    0    4M  0 part

  ├─mpatha2                     253:2    0    1G  0 part  /boot

  └─mpatha3                     253:3    0   79G  0 part

    ├─rhel_myhost-root 253:4    0 47.7G  0 lvm   /

    ├─rhel_myhost-swap 253:5    0    8G  0 lvm   [SWAP]

    └─rhel_myhost-home 253:6    0 23.3G  0 lvm   /home

#

Here's a breakdown of the information in each column:

NAME: This column shows the name of the block device.

MAJ:MIN: Major and minor device numbers that uniquely identify the device to the operating system.

RM: This indicates whether the device is removable (1 for yes, 0 for no).

SIZE: The size of the device, often in gigabytes (G) or megabytes (M).

RO: This indicates whether the device is read-only (1 for yes, 0 for no).

TYPE: The type of device, which can be "disk" for physical disks or "part" for partitions. In this case, you also see "mpath" and "lvm," which are related to storage management.

MOUNTPOINT: The mount point where the device is currently mounted. If it's not mounted, this field will be empty.

Now, let's interpret the information based on the provided output:

There are two disk devices: sda and sdb.

Both sda and sdb are part of a multipath configuration, as indicated by the "mpath" type.

Each disk (sda and sdb) has three partitions (mpatha1, mpatha2, and mpatha3), and each of these partitions is used in an LVM (Logical Volume Management) setup.

The /boot partition (mpatha2) is mounted on both sda and sdb, and it contains the boot files.

The root (/) partition (rhel_myhost-root) is mounted on both sda and sdb, and it is the root filesystem.

The swap partition (rhel_myhost-swap) is also mounted on both sda and sdb and is used for swap space.

The /home partition (rhel_myhost-home) is mounted on both sda and sdb and is used for user home directories.

Here's what each of these partitions is typically used for:

mpatha1: This partition appears to be very small (only 4MB), and it is often used for storing bootloader-related files. Specifically, it might contain the GRUB bootloader's core files or other boot-related data. It's a common practice to allocate a small partition for bootloader files to ensure that they are easily accessible and less likely to be affected by changes or issues in the rest of the filesystem. A small partition like this is often sufficient for storing the essential boot files.

mpatha2: This partition is mounted as /boot, and it contains the kernel and initial ramdisk files needed for booting the system. /boot typically holds the Linux kernel, GRUB configuration files, and other boot-related data. Having a separate /boot partition is a common practice, especially in systems that use LVM or other complex storage configurations. It ensures that essential boot files are easily accessible and are less prone to issues that might affect other partitions.

mpatha3: This partition appears to be the largest and is not directly mounted as part of the root filesystem (/). Instead, it seems to be part of an LVM (Logical Volume Management) setup. It is divided into multiple logical volumes (rhel_myhost-root, rhel_myhost-swap, and rhel_myhost-home) that are used for various purposes:

rhel_myhost-root: This is the root filesystem (/) where most of the operating system and software are installed.

rhel_myhost-swap: This logical volume is used as swap space, which is used for virtual memory and can help improve system performance.

rhel_myhost-home: This logical volume is typically used for user home directories. User data and files are stored in the /home directory, which is often mounted on a separate filesystem to isolate user data from the root filesystem.

So, mpatha1 is likely used for bootloader files, mpatha2 is the /boot partition containing boot-related files, and mpatha3 represents an LVM setup with separate logical volumes for the root filesystem, swap space, and user home directories. This kind of partitioning and storage management allows for flexibility, scalability, and better system maintenance

You can map the UUID specified in the /etc/fstab file to the corresponding device name, such as /dev/sda1, /dev/sdb1, or /dev/mpatha1. The UUID (Universally Unique Identifier) is a unique identifier assigned to each filesystem or partition and is a more reliable way to identify devices than device names, which can change if hardware configurations are altered.

To map a UUID to the corresponding device name, you can use the blkid command. 

[root@myhost ~]# blkid

/dev/mapper/rhel_myhost-root: UUID="XXXXXXXXXXXXXXX" BLOCK_SIZE="512" TYPE="xfs"

/dev/mapper/mpatha3: UUID="XXXXXXXXX" TYPE="LVM2_member" PARTUUID="XXXXXXXX"

/dev/sda: PTUUID="XXXXXXXX" PTTYPE="dos"

/dev/mapper/mpatha: PTUUID="abc" PTTYPE="dos"

/dev/sdb: PTUUID="XXXXXXX" PTTYPE="dos"

/dev/mapper/mpatha1: PARTUUID="abc-01"

/dev/mapper/mpatha2: UUID="XXXXXXXXXXXXXXXXXXXX" BLOCK_SIZE="512" TYPE="xfs" PARTUUID="XXXXX"

/dev/mapper/rhel_myhost-swap: UUID="abc123c" TYPE="swap"

/dev/mapper/rhel_myhost-home: UUID="xyz123" BLOCK_SIZE="512" TYPE="xfs"

[root@myhost ~]#

-----------------

[root@myhost ~]# cat /boot/grub2/device.map

# this device map was generated by anaconda

(hd0)      /dev/mapper/mpatha

[root@myhost ~]#

--------------

[root@myhost ~]# cat /etc/fstab

#

# /etc/fstab

/dev/mapper/rhel_myhost-root /                       xfs     defaults        0 0

UUID=XXXXXXXXXXXXXXXXXXXXXXX /boot                   xfs     defaults        0 0

/dev/mapper/rhel_myhost-home /home                   xfs     defaults        0 0

/dev/mapper/rhel_myhost-swap none                    swap    defaults        0 0

[root@myhost ~]#

A multipath setup in Linux provides redundancy, load balancing, and fault tolerance for storage devices, ensuring that data remains accessible even if one path or connection fails. This technology is crucial in enterprise environments where continuous access to data is essential for operations.

----------------------------

The grub2-install command is a utility used in Linux to install the GRUB (Grand Unified Bootloader) bootloader onto a device, typically a hard disk or a partition.

The primary purpose of the grub2-install command is to install the GRUB bootloader on a specific device. You specify the target device as an argument to the command. 

For example :  grub2-install /dev/sda

In this example, the GRUB bootloader is installed on the MBR (Master Boot Record) of /dev/sda, which is typically the primary boot device.

Boot Device Configuration:

When GRUB is installed on a device, it configures the bootloader to locate and load the kernel and initial ramdisk (initrd) from the designated boot device or partition. It also stores configuration information, such as the location of the kernel and the root filesystem.

Device Map Configuration:

GRUB maintains a device map that associates BIOS drive numbers (e.g., (hd0), (hd1)) with actual device names (e.g., /dev/sda, /dev/sdb). The grub2-install command updates or creates this device map, ensuring that GRUB can correctly identify the boot device.

Bootloader Configuration File:

GRUB bootloader configurations are specified in the /boot/grub2/grub.cfg (or similar) file. This configuration file is automatically generated by GRUB utilities and scripts based on the system's configuration, such as the kernel and initrd locations, boot options, and menu entries.

Boot Menu:

GRUB provides a boot menu during system startup, allowing users to select from available kernels and boot options. The grub2-install command ensures that the necessary components for this boot menu are installed and configured correctly.

Updating GRUB Configuration:

In addition to installing GRUB, the grub2-install command also updates the bootloader's configuration to reflect changes in the system's disk layout or partitioning scheme. This includes updating device names and paths if necessary.

EFI and UEFI Support:

The behavior of grub2-install can differ depending on whether the system uses BIOS or UEFI (Unified Extensible Firmware Interface) for booting. For UEFI systems, the grub2-install command installs the UEFI version of GRUB and configures it accordingly.

Additional Options:

The grub2-install command supports various options to specify installation details, such as the target architecture, firmware type (BIOS or UEFI), and more. You can use the --target, --boot-directory, and other options to customize the installation.

----------------------------------------------------------

The PReP boot partition is a specialized partition used on PowerPC systems that follow the PReP boot standard to store firmware-specific bootloader and boot-related files. On the other hand, the /boot partition is a common convention on Linux systems, including PowerPC systems, to store kernel, initramfs, and bootloader configuration files, but it is not tied to any specific firmware standard and is used across various hardware architectures.

PReP Boot Partition:

The PReP boot partition is a specific partition type used in the context of the PReP boot standard, which is a firmware standard for booting PowerPC-based systems.

Its primary purpose is to store the bootloader and boot-related information required to initiate the boot process on PowerPC systems adhering to the PReP standard.

It typically contains essential firmware boot files, such as Open Firmware or IEEE 1275-compliant firmware, which are necessary to start the system.

/boot Partition:

The /boot partition is a common convention used on various Linux distributions, including those running on PowerPC systems.

Its purpose is to store the kernel, initramfs (initial RAM disk), bootloader configuration files, and other files required for the early stages of the boot process.

The /boot partition is part of the Linux filesystem structure and is used by the Linux bootloader (e.g., GRUB) to locate and load the kernel and initramfs during the boot process.

Firmware Dependency:

PReP Boot Partition:

The PReP boot partition's usage is closely tied to the firmware standard it follows, such as Open Firmware or IEEE 1275-compliant firmware. The firmware is responsible for loading the bootloader from this partition.

It may also contain firmware-specific files and configurations.

/boot Partition:

The /boot partition is not firmware-dependent and is part of the Linux filesystem. It is managed by the Linux bootloader (e.g., GRUB) and the operating system itself.

The bootloader reads the kernel and initramfs from the /boot partition during the boot process, and this partition is independent of the system's firmware.

Common Usage:

PReP Boot Partition:

Commonly used on older PowerPC-based systems that adhere to the PReP standard.

It's specific to the boot process defined by the firmware standard used on these systems

/boot Partition:

Widely used on various Linux distributions, including those on PowerPC systems.

It's part of the standard Linux filesystem structure and is used on many different hardware platforms.