Sign up ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

I want to mount my second hard disk from my Linux VMware guest but when I try

mount -t ext3 /dev/sdb2

it is not available.

fdisk -l /dev/sdb

gives me unknown format:

/dev/sdb1            2048     4208639     2103296   2d  Unbekannt
/dev/sdb2         4208640   137902079    66846720   2d  Unbekannt
/dev/sdb3       137902080   976773119   419435520   83  Linux

sdb1 is the Linux swap, sdb2 is my boot partition and sdb3 my home partition. It's basically a standard SUSE 12.1 default partition layout.

share|improve this question
what happens when you enter sudo dd if=/dev/sdb2 of=/tmp/fs.part bs=1M count=1 followed by sudo file /tmp/fs.part? –  jippie Apr 14 '12 at 12:15
This is a shorter version of the comment above: sudo file -sL /dev/sdb2 –  jippie Apr 14 '12 at 12:21
@jippie: /tmp/.fs.part: \0 –  Phpdevpad Apr 14 '12 at 12:22
There is no filesystem in /dev/sdb2. If there was, the answer would have been similar to Linux rev 1.0 ext3 filesystem data, UUID=76b4806e-a309-48e0-9ddd-706341edb5cd (needs journal recovery) (large files) does the short version give the same result? –  jippie Apr 14 '12 at 12:23
@Jippie: I see. I think the error is because I didn't shared this partition with vmware shared options. I can mount sda3. Thank you! –  Phpdevpad Apr 14 '12 at 12:24

1 Answer 1

First of all, afaik what fdisk -l / shows is normally not relevant for mounting. mdadm uses it for building RAID volumes and LVM uses it for scanning physical volumes, but in most cases the type which is set in the master boot record (the one you see with fdisk) is not used. The man page of mount says the mount uses the blkid library to determine the fs type. You can do the same:

blkid /dev/sda1
/dev/sda1: UUID="7S4ZFy-8sXS-Xk3x-WRvK-Lczt-HDgo-YOKLM1" TYPE="LVM2_member"

blkid /dev/vg00/lv1
/dev/vg00/lv1: LABEL="lv1" UUID="8c2a4ab6-aac6-43c2-9866-ee1c9c3a6f32" TYPE="ext4" 

If this doesn't help (and I think in your system this is the case), you can try to figure out the type using the command file -s. Examples from my machine:

file -s /dev/sda1
/dev/sdb1: LVM2 PV (Linux Logical Volume Manager), UUID: 7S4ZFy-8sXS-Xk3x-WRvK-Lczt-HDgo-YOKLM1, size: 1500299779584

file -s /dev/vg00/lv1
/dev/vg00/lv1: symbolic link to `../dm-19'

file -s /dev/dm-19
/dev/dm-19: Linux rev 1.0 ext4 filesystem data, UUID=8c2a4ab6-aac6-43c2-9866-ee1c9c3a6f32 (needs journal recovery) (extents) (large files) (huge files)

It is possible that blkid fails if the corresponding fs kernel module is not loaded...

share|improve this answer
Actually LVM has never used the partition table type id for finding pvs, and mdadm only used/uses it for the legacy 0.9 format metadata, and only when you have the kernel auto assemble the root instead of using an initramfs. Also blkid doesn't depend on the kernel module. –  psusi 2 days ago
Correct. lsblk (and not blkid) is the one which reads out the current system config from kernel. My fault. –  Daniel Alder yesterday
I didn't mention lsblk. What I was saying is that blkid just reads the data off the drive and matches it to known patterns to identify what it is... it does not require a kernel driver that is able to mount it. –  psusi yesterday
@psusi I mentioned lsblk because I was writing about blkid as if it was lsblk –  Daniel Alder yesterday

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.