Search for a command to run...
A tech enthusiast and cloud engineer with a passion for sharing knowledge. Through this blog, I delve into the world of Cloud computing, DevOps, Cloud Security and the latest in tech trends. Join me on this journey as I explore and demystify the digital world. Outside of tech, I’m an avid soccer fan and enjoy writing. This blog combines my professional insights with my creative passions.
No comments yet. Be the first to comment.
Introduction GitHub Actions provides a powerful way to automate workflows in your repositories. By creating custom actions, you can encapsulate reusable workflows, scripts, and automation steps into a single unit. In this article, we will walk throug...
When conducting performance testing, resource allocation plays a critical role in ensuring that your application not only meets performance expectations but also operates efficiently. Deciding whether to start with high resource allocations and adjus...
As businesses evolve and adopt cloud technologies, the management of sensitive data becomes increasingly crucial. Azure Key Vault, a cloud service provided by Microsoft, offers a secure storage solution for cryptographic keys, secrets, and certificat...
I am tempted to call the Azure Automation Service a "Task Scheduler on steroids". It is of course an oversimplification as the Azure Automation service is used for more than just scheduling tasks but I guess it can serve as a good introduction to wha...
On this page
When working with Linux filesystems, particularly XFS, you may occasionally run into issues when attempting to mount partitions. Recently, I encountered a problem with mounting an XFS filesystem, which provided valuable insights into troubleshooting filesystem issues. In this post, I'll walk you through the issue, the troubleshooting process, and the steps I followed to resolve it.
I attempted to mount an XFS partition using the following command:
sudo mount -t xfs /dev/sdm1 /mariadb/prddisk
However, I received the following error message:
mount: /mariadb/prddisk: wrong fs type, bad option, bad superblock on /dev/sdm1, missing codepage or helper program, or other error.
At first glance, this error could be due to several factors:
Filesystem corruption
Incorrect filesystem type
Damaged superblock
Missing system utilities for XFS
To investigate further, I used dmesg to check the kernel logs:
dmesg | grep sdm1
The output provided more specific information:
[9373848.668073] XFS (sdm1): Unmounting Filesystem cbcecfa4-54ad-48c3-9dbf-f7cc49151913
[9603307.038109] XFS (sdm1): Filesystem has duplicate UUID dce22b56-4bc9-48da-927a-72ce29c5dcff - can't mount
It turned out that the issue was a duplicate UUID in the XFS filesystem, which was preventing the system from mounting the partition.
UUIDs (Universally Unique Identifiers) are intended to uniquely identify filesystems, allowing the operating system to reference partitions even when their underlying device names (e.g. /dev/sdm1) change. If two filesystems have the same UUID, this creates a conflict, and Linux refuses to mount the filesystem.
In this case, the dmesg logs clearly indicated that the partition's UUID (dce22b56-4bc9-48da-927a-72ce29c5dcff) was duplicated.
To confirm the UUID, I used the blkid command:
sudo blkid /dev/sdm1
This confirmed that the UUID of the filesystem was indeed duplicated with another existing filesystem, which can happen if a disk was cloned or a snapshot was created without updating the UUID.
The easiest way to resolve this issue is by generating a new UUID for the filesystem using the xfs_admin tool:
sudo xfs_admin -U generate /dev/sdm1
This command generates a new UUID for the XFS partition, resolving the duplication issue.
Before mounting the filesystem again, I decided to check for any corruption that might have occurred during previous mounting attempts. I used the xfs_repair utility:
sudo xfs_repair /dev/sdm1
If any corruption is found, xfs_repair will attempt to fix the issue. In my case, the filesystem was in good health. (You might need to use the -L flag to clear the log for the command to be successful)
After changing the UUID and ensuring the filesystem's integrity, I retried mounting the partition:
sudo mount -t xfs /dev/sdm1 /mariadb/prddisk
This time, the filesystem mounted successfully without any errors.
If you have an entry for this partition in /etc/fstab, don't forget to update it with the new UUID. You can use blkid again to retrieve the new UUID and update /etc/fstab accordingly:
UUID=<new_uuid> /mariadb/prddisk xfs defaults 0 0
In some cases, the error message about a "bad superblock" might indicate that the filesystem's superblock is corrupted. If you suspect this, you can use the xfs_db tool to inspect the superblock:
sudo xfs_db -c "sb 0" -r /dev/sdm1
If the superblock is damaged, you can attempt to repair it using xfs_repair. Always ensure that the filesystem is unmounted before performing these operations.
If you continue to encounter mounting issues due to the duplicate UUID error, you can try mounting the filesystem with the -o nouuid option. This option tells the system to ignore the UUID check temporarily, which might be useful for troubleshooting:
sudo mount -t xfs -o nouuid /dev/sdm1 /mariadb/prddisk
However, this is not a permanent solution and should only be used as a temporary workaround. After mounting, it's still important to address the UUID conflict.
XFS is a robust filesystem, but like any system, it can run into issues such as duplicate UUIDs or corruption. Fortunately, tools like xfs_repair and xfs_admin make it relatively easy to resolve these problems. By systematically checking for issues, repairing the filesystem, and generating a new UUID, I was able to resolve the duplicate UUID problem and successfully mount the partition.
If you're facing similar issues, I hope this guide helps you troubleshoot and resolve the problem. Always remember to back up important data before making changes to your filesystem!