Querying Unmounted Drive Information in Linux: Filesystem Detection Without Mounting


11 views

When dealing with removable drive bays in Linux, we often need to identify drive characteristics before mounting. Traditional approaches rely on successful mounting first, which fails when dealing with:

  • Unformatted drives
  • Unsupported filesystems
  • Corrupted partitions

Here are effective techniques to examine drives without mounting:

# 1. Using blkid (best for formatted drives)
sudo blkid /dev/sdX

# 2. Checking partition tables with fdisk
sudo fdisk -l /dev/sdX

# 3. Filesystem signature detection
sudo xxd -l 1024 /dev/sdX | less

For a GUI application, consider this Python example using subprocess:

import subprocess

def get_drive_info(device_path):
    try:
        # Try blkid first
        result = subprocess.run(['blkid', device_path], 
                              capture_output=True, text=True)
        if result.returncode == 0:
            return parse_blkid(result.stdout)
        
        # Fallback to filesystem signature check
        return check_filesystem_signature(device_path)
    except Exception as e:
        return {"error": str(e)}

def parse_blkid(blkid_output):
    # Implementation would parse TYPE= ext4 etc.
    pass

For more robust detection:

# Check for partition table type
sudo parted /dev/sdX print | grep 'Partition Table'

# Examine first sectors for filesystem markers
sudo dd if=/dev/sdX bs=512 count=1 | file -

When implementing this in production:

  • Always check for device existence first with os.path.exists()
  • Handle permission errors gracefully
  • Consider adding IOCTL calls for direct device queries

For frequent polling of drive bays:

  • Implement udev rule monitoring
  • Cache recent drive information
  • Use asynchronous checks for better UI responsiveness

When building GUI tools for managing hot-swappable eSATA drives in Linux, one persistent challenge is identifying drive characteristics before mounting. Traditional approaches relying solely on mount operations leave users in the dark when:

  • Drives contain unrecognized filesystems
  • Partition tables are corrupted
  • Drives are completely unformatted

Here are the most reliable methods to examine unmounted drives:

1. Using blkid for Filesystem Signature Detection


sudo blkid /dev/disk/by-path/pci-0000:00:1f.2-scsi-2:0:0:0

# Sample output:
# /dev/sdb1: UUID="5a92b85a-b6b5-4a5a-9e5c-aa55b5e5a5a5" TYPE="ext4"

2. Examining Partition Tables with fdisk/lsblk


sudo fdisk -l /dev/disk/by-path/pci-0000:00:1f.2-scsi-1:0:0:0

# Or for JSON output:
lsblk -f -J /dev/sdc

3. Low-Level Filesystem Probing with file


sudo file -s /dev/sdb1

# Output examples:
# "/dev/sdb1: Linux rev 1.0 ext4 filesystem data"
# "/dev/sdb1: DOS/MBR boot sector"

Here's how to integrate this into a Python GUI application:


import subprocess
import json

def get_unmounted_drive_info(device_path):
    try:
        # Get basic block device info
        lsblk = subprocess.run([
            'lsblk', '-f', '-J', device_path
        ], capture_output=True, text=True)
        
        if lsblk.returncode == 0:
            data = json.loads(lsblk.stdout)
            return {
                'filesystem': data['blockdevices'][0].get('fstype'),
                'label': data['blockdevices'][0].get('label'),
                'uuid': data['blockdevices'][0].get('uuid')
            }
        
        # Fallback to blkid
        blkid = subprocess.run([
            'blkid', '-o', 'export', device_path
        ], capture_output=True, text=True)
        
        info = {}
        for line in blkid.stdout.splitlines():
            if '=' in line:
                key, val = line.split('=', 1)
                info[key.lower()] = val
        return info
        
    except Exception as e:
        return {'error': str(e)}

For robust implementation, consider these scenarios:

  • Unformatted Drives: Check if output contains "data" (from file -s) with no filesystem markers
  • Corrupted Partitions: Verify partition table with parted -l
  • Encrypted Volumes: Look for LUKS headers with cryptsetup isLuks

When implementing this in a GUI tool:

  • Cache results for recently accessed devices
  • Run scans asynchronously to prevent UI freezing
  • Provide visual feedback during scanning (especially for large drives)

For specialized needs:

  • udisksctl for DBus integration
  • Direct filesystem header parsing (for custom detection)
  • Monitoring udev events for real-time notifications