Mounting Unknown Partition Type

October 14, 2011 at 20:21:39
Specs: Linux x86_64
I was given several PCs that have some type of embedded disk drive that contains a custom Linux Kernel that only runs one main program. I need to gain access to the disk to change the root password so I can gain access to the systems. I attempted to boot a Fedora Live CD and started the process. fdisk reveled three partitions. 1: Boot Partition (1.5MB) 2: OS Partition (238MB) 3: Main program space (6.5MB) I am able to mount partition 1 and 3 without any problems but partition 2 reports:
# mount /dev/sda2 /mnt/sda2
EXT2-fs (sda2): error: can't find an ext2 filesystem on dev sda2
FAT: invalid media value (0x77)
mount: you must specify the filesystem type

I've tried several different types and none have worked. I know for sure this partition contains the critical files I need because I can not find any linux os files on the other two partitions and the lilo configuration file on the sda1 (/etc/lilo.conf) specifies /dev/sda2 as the root disk.

Just for the record I have no access to any utilities nor console when the system is booted. The only thing I can report is when use Ctrl+Alt+F2 to be presented with the login prompt it says the Computer Name is "SuperStation". I would appreciate any suggestions.


See More: Mounting Unknown Partition Type

Report •

#1
October 15, 2011 at 01:29:06
Try the command:

file -sL /dev/sda2

to see if you can determine what type of filesystem is on the partition. You can then investigate ways of mounting that particular filesystem.


Report •

#2
October 15, 2011 at 07:36:53
Thank you for the quick response. I finally discovered that solution last night but its output reveals nothing. Output Below.

# file -sL /dev/sda1
/dev/sda1: Linux rev 1.0 ext2 filesystem data, UUID=3397c7a7-3750-455d-98cc-55d5ac321d97

# file -sL /dev/sda2
/dev/sda2: data

# file -sL /dev/sda3
/dev/sda3: Linux Compressed ROM File System data, little endian size 6291456 version #2 sorted_dirs CRC 0xb3698320, edition 0, 2188 blocks, 823 files

Looking at the lilo.conf file I see the Linux Kernel is stored on sda1 (/bzImage), Is it possible that the kernel has some module that allows access to sda2?


Report •

#3
October 15, 2011 at 08:41:27
My guess would be that the filesystem is one that is nor supported by the Fedora Live CD (XFS possibly as that is often used in embedded Linux devices). Try downloading the PartEd Live CD (http://gparted.sourceforge.net/livecd.php) which recognizes just about any filesystem that is used with Linux. If that doesn't recognize the filesystem I don't know what further to suggest.

Report •

Related Solutions

#4
October 15, 2011 at 09:08:52
Great Solution with different output but no go.

# mount /dev/sda2 /mnt/sda2
ISOFS: Unable to identify CD-ROM format.
SQUASHFS error: Can't find a SQUASHFS superblock on sda2
XFS (sda2): bad magic number
XFS (sda2): SB validate failed
mount: you must specify the filesystem type

Can I exam the kernel in any way? Uncover any secrets the kernel might hold?


Report •

#5
October 15, 2011 at 09:30:07
The tried to boot the custom kernel using a the Grub Super Disk (You know to play with the kernel arguments) and at first try I got a Kernel Panic reporting: not syncing: VFS: Unable to mount root fs on unknown-block(1,0)

Could the kernel be utilizing some custom fs to access the partition? Any suggestions of kernel arguments that I could try to interrupt the kernel boot just enough to mount the partition and drop me to a bash/sh terminal or something?

Heres the lilo.conf just in case it helps

disk=/dev/loop0
     bios=0x80
     cylinders=500
     heads=8
     sectors=16
     partition=/dev/loop1
        start=16
     partition=/dev/loop2
        start=3072
     partition=/dev/loop3
        start=50816
boot=/dev/loop0
lba32
compact

delay=10
default=SuperVision
root=/dev/hda2

map=/boot/map
image=/bzImage
	label=SuperVision
	read-only
        initrd=/boot/initrd.splash
        append="mode=normal splash=silent"
image=/bzImage
        label="Maintain"
        read-only
        initrd=/boot/initrd.splash
        append="mode=maintain"
image=/bzImage
        label="Console"
        read-only
        initrd=/boot/initrd.splash
        append="mode=console"


Report •

#6
October 15, 2011 at 10:33:06
Are you sure it isn't qnx?

1/3 of highway deaths are caused by drunks. The rest are by people who can't drive any better than a drunk.


Report •

#7
October 15, 2011 at 10:40:55
Interesting!! If you are implying the QNX Microkernel then no I did not and for that matter have never heard of QNX.

If this did turn out to be QNX, what can I do to break (change) the root password?


Report •

#8
October 16, 2011 at 10:40:52
I'd dd the thing to some file before you loose it all.

Is this one of those M-systems disks?

I just can't tell for sure what the format is exactly. Others would be very correct in that you really do have a XFS format. Wonder is they just used the data portion raw.

See the man pages for mount for any xfs options.

Actually now that I see it, it seems to be more like a IRIX or Silicon Graphics format. That is odd because I never heard of an embedded version.

I was going to start by.
Mount it as a qnx format if it is or use one of the qnx demo disks either the 4x or the live cd out there I think it is 6.2.3 or close to that. I use a qemu vm with qnx running to do stuff.

1/3 of highway deaths are caused by drunks. The rest are by people who can't drive any better than a drunk.


Report •

#9
October 16, 2011 at 12:35:12
Thanks for the continued help. Not to worry making a dd copy was the first thing I did. Nice thing is I can do some examining of the back up image on my main Ubuntu 11.04 machine without booting in and out of live cds.

I tried mounting it as QNX but both the live gparted cd and my Ubuntu 11.04 OS do not have the support for QNX Partitions. I heard there is an optional QNX FS module available for Ubuntu 7 or 8 but non newer.

If their are any examining tools you would like me to try on the partition then I would be more then willing to post the output. Heres some debug from fdisk and file.

# fdisk SuperVision.img -l
Disk sda.img: 0 MB, 0 bytes
8 heads, 16 sectors/track, 0 cylinders
Units = cylinders of 128 * 512 = 65536 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

  Device Boot      Start         End      Blocks   Id  System
sda.img1               1          24        1528   83  Linux
sda.img2              25         397       23872   83  Linux
sda.img3             398         500        6592   83  Linux

# file -sL SuperVision.img
sda.img: x86 boot sector, LInux i386 boot LOader; partition 1: ID=0x83, starthead 1, startsector 16, 3056 sectors; partition 2: ID=0x83, starthead 0, startsector 3072, 47744 sectors; partition 3: ID=0x83, starthead 0, startsector 50816, 13184 sectors, code offset 0xeb


Report •

#10
October 17, 2011 at 17:08:08
The id is 83 so that should be a linux native one. As to why it doesn't mount, I guess it could be just raw.

See this post for how to use the program file to get format.

http://forum.soft32.com/linux2/iden...

1/3 of highway deaths are caused by drunks. The rest are by people who can't drive any better than a drunk.


Report •

Ask Question