Skip to content

NimTechnology

Trình bày các công nghệ CLOUD một cách dễ hiểu.

  • Kubernetes & Container
    • Docker
    • Kubernetes
      • Ingress
      • Pod
    • Helm Chart
    • OAuth2 Proxy
    • Isito-EnvoyFilter
    • Apache Kafka
      • Kafka
      • Kafka Connect
      • Lenses
    • Vault
    • Longhorn – Storage
    • VictoriaMetrics
    • MetalLB
    • Kong Gateway
  • CI/CD
    • ArgoCD
    • ArgoWorkflows
    • Argo Events
    • Spinnaker
    • Jenkins
    • Harbor
    • TeamCity
    • Git
      • Bitbucket
  • Coding
    • DevSecOps
    • Terraform
      • GCP – Google Cloud
      • AWS – Amazon Web Service
      • Azure Cloud
    • Golang
    • Laravel
    • Python
    • Jquery & JavaScript
    • Selenium
  • Log, Monitor & Tracing
    • DataDog
    • Prometheus
    • Grafana
    • ELK
      • Kibana
      • Logstash
  • BareMetal
    • NextCloud
  • Toggle search form

[Ubuntu/LVM] Reattach LVM Disk to new Physical Server.

Posted on October 21, 2024October 21, 2024 By nim No Comments on [Ubuntu/LVM] Reattach LVM Disk to new Physical Server.

If you’re connecting an old LVM disk to your Raspberry Pi 4 and want to reuse it, here’s a step-by-step guide on how to detect, activate, and mount the logical volumes (LVs) on that disk.

Contents

Toggle
    • Step 1: Verify Disk Detection
    • Step 2: Scan for LVM Physical Volumes (PVs)
    • Step 3: Scan for Volume Groups (VGs)
    • Step 4: Activate the Volume Group
    • Step 5: List Logical Volumes
    • Step 6: Mount the Logical Volumes
    • Step 7: Check the Mount
    • Optional: Add to /etc/fstab for Auto-Mount
    • Step 8: Cleaning Up (Optional)
  • Explain more:
    • In your example:
    • Adjusting Values:

Step 1: Verify Disk Detection

When you plug in the old disk, first check if the Raspberry Pi detects it using:

sudo lsblk

Look for your disk in the output. For example, it may be listed as /dev/sdX (where X is a letter like b, c, etc.).

Step 2: Scan for LVM Physical Volumes (PVs)

Once the disk is detected, scan for LVM physical volumes on it:

sudo pvscan

This command will list all available physical volumes. If your old disk contains LVM partitions, it should appear here.

Step 3: Scan for Volume Groups (VGs)

Next, scan for any volume groups (VGs) on the disk:

sudo vgscan

This should detect the volume group associated with the old disk.

Step 4: Activate the Volume Group

After detecting the volume group, you need to activate it to make the logical volumes available:

sudo vgchange -ay

This command activates all volume groups and makes the associated logical volumes available.

Step 5: List Logical Volumes

To see the logical volumes on the activated volume group, run:

sudo lvdisplay

This will show the logical volumes that are part of the activated volume group.

Step 6: Mount the Logical Volumes

Once the logical volumes are detected, mount them to use their contents. First, check the filesystem type of the LV (usually ext4, but it could be different):

sudo blkid /dev/<vg_name>/<lv_name>

Replace <vg_name> with the name of the volume group and <lv_name> with the logical volume name. This command will show the filesystem type (like ext4, xfs, etc.).

Now, create a mount point and mount the LV:

sudo mkdir /mnt/old_disk
sudo mount /dev/<vg_name>/<lv_name> /mnt/old_disk

Replace <vg_name> and <lv_name> with the appropriate values.

Step 7: Check the Mount

To ensure the disk is successfully mounted, check it with:

df -h

This will show you all mounted disks and their usage. You should see your old disk mounted at /mnt/old_disk.

Optional: Add to /etc/fstab for Auto-Mount

If you want the logical volume to mount automatically on boot, add an entry to /etc/fstab:

  1. Open /etc/fstab:
   sudo nano /etc/fstab
  1. Add the following line at the end of the file:
   /dev/<vg_name>/<lv_name>  /mnt/old_disk  ext4  defaults  0  2

Replace the values as needed (ensure the filesystem type matches the output of blkid).

  1. Save and exit by pressing CTRL + X, then Y, and Enter.

This will ensure your disk mounts automatically when the Raspberry Pi starts.

Step 8: Cleaning Up (Optional)

If you plan to repurpose the disk and start fresh, you can remove the existing LVM configuration:

  1. Deactivate the Volume Group:
   sudo vgchange -an <vg_name>
  1. Remove the Logical Volumes:
   sudo lvremove /dev/<vg_name>/<lv_name>
  1. Remove the Volume Group:
   sudo vgremove <vg_name>
  1. Remove the Physical Volume:
   sudo pvremove /dev/sdX

After this, you can partition and format the disk as you wish using standard tools like fdisk and mkfs.


Would you like to proceed with any of these steps, or do you need further clarification on a specific part?

Explain more:

The line /dev/<vg_name>/<lv_name> /mnt/old_disk ext4 defaults 0 2 is an entry in the /etc/fstab file, which is used to define how filesystems are mounted automatically at boot. The numbers 0 and 2 at the end of this line have specific purposes related to system checks during boot.

Here’s a breakdown of the entire entry:

  1. /dev/<vg_name>/<lv_name>: This specifies the device or logical volume to be mounted. It points to the LVM logical volume you want to mount (replace <vg_name> and <lv_name> with the actual names).
  2. /mnt/old_disk: This is the mount point where the filesystem will be mounted, i.e., the directory where the content of the logical volume will be accessible.
  3. ext4: This is the filesystem type (in this case, ext4). If the filesystem on your logical volume is different (e.g., xfs or btrfs), you would specify that here.
  4. defaults: This defines the default mount options. The defaults option typically includes:
    • rw: Read-write access.
    • suid: Allow set-user-identifier (SUID) and set-group-identifier (SGID) bits.
    • dev: Interpret character or block special devices on the filesystem.
    • exec: Allow execution of binaries.
    • auto: Automatically mount at boot.
    • nouser: Disallow users to mount.
    • async: Write filesystem operations asynchronously.
  5. 0 (Dump flag): This number controls dump behavior, which is a legacy feature for backup. It’s used to determine whether the filesystem should be dumped (backed up) by the dump utility.
    • 0: Do not dump the filesystem (most common setting).
    • 1: Enable dumping for this filesystem.
  6. 2 (FSCK Order): This number controls fsck (filesystem check) behavior, specifying the order in which filesystems are checked during boot. It can be:
    • 0: Do not check the filesystem at boot (common for non-critical or data drives).
    • 1: Perform a check on the root filesystem first (this should only be set for the root filesystem).
    • 2: Check this filesystem after the root filesystem (used for non-root filesystems that should be checked after the root).

In your example:

  • 0: The filesystem is not scheduled for dumping (backup).
  • 2: The filesystem will be checked at boot, but after the root filesystem (/). This is the appropriate setting for most non-root filesystems.

Adjusting Values:

  • If you don’t want the filesystem to be checked at boot, change the 2 to 0.
  • If the filesystem is critical and should be checked before others, you can use 1, but this should be reserved for the root filesystem (/).

Let me know if you need more details or further clarification!

BareMetal

Post navigation

Previous Post: An AWS IAM Security Tooling Reference [2024]
Next Post: [Laravel] Laravel code is helpful

More Related Articles

[Linux] Error when run apt update BareMetal
[Kafka-Zookeeper] Starting Kafka and Zookeeper Apache Kafka
[SSH] Add new user to SSH to Ubuntu BareMetal
[rclone] Mount folder in linux with google drive by rclone. So helpful to backup data! BareMetal
[Prometheus/Grafana] Install Prometheus and Grafana on ubuntu. BareMetal
[Node exporter] Install node_exporter on MacOS BareMetal

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Tham Gia Group DevOps nhé!
Để Nim có nhiều động lực ra nhiều bài viết.
Để nhận được những thông báo mới nhất.

Recent Posts

  • [Azure] The subscription is not registered to use namespace ‘Microsoft.ContainerService’ May 8, 2025
  • [Azure] Insufficient regional vcpu quota left May 8, 2025
  • [WordPress] How to add a Dynamic watermark on WordPress. May 6, 2025
  • [vnet/Azure] VNet provisioning via Terraform. April 28, 2025
  • [tracetcp] How to perform a tracert command using a specific port. April 3, 2025

Archives

  • May 2025
  • April 2025
  • March 2025
  • February 2025
  • January 2025
  • December 2024
  • November 2024
  • October 2024
  • September 2024
  • August 2024
  • July 2024
  • June 2024
  • May 2024
  • April 2024
  • March 2024
  • February 2024
  • January 2024
  • December 2023
  • November 2023
  • October 2023
  • September 2023
  • August 2023
  • July 2023
  • June 2023
  • May 2023
  • April 2023
  • March 2023
  • February 2023
  • January 2023
  • December 2022
  • November 2022
  • October 2022
  • September 2022
  • August 2022
  • July 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • January 2022
  • December 2021
  • November 2021
  • October 2021
  • September 2021
  • August 2021
  • July 2021
  • June 2021

Categories

  • BareMetal
    • NextCloud
  • CI/CD
    • Argo Events
    • ArgoCD
    • ArgoWorkflows
    • Git
      • Bitbucket
    • Harbor
    • Jenkins
    • Spinnaker
    • TeamCity
  • Coding
    • DevSecOps
    • Golang
    • Jquery & JavaScript
    • Laravel
    • NextJS 14 & ReactJS & Type Script
    • Python
    • Selenium
    • Terraform
      • AWS – Amazon Web Service
      • Azure Cloud
      • GCP – Google Cloud
  • Kubernetes & Container
    • Apache Kafka
      • Kafka
      • Kafka Connect
      • Lenses
    • Docker
    • Helm Chart
    • Isito-EnvoyFilter
    • Kong Gateway
    • Kubernetes
      • Ingress
      • Pod
    • Longhorn – Storage
    • MetalLB
    • OAuth2 Proxy
    • Vault
    • VictoriaMetrics
  • Log, Monitor & Tracing
    • DataDog
    • ELK
      • Kibana
      • Logstash
    • Fluent
    • Grafana
    • Prometheus
  • Uncategorized
  • Admin

Copyright © 2025 NimTechnology.