mount partition type 'fd' fails with " unknown filesystem type 'linux_raid_member'"
Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
mount partition type 'fd' fails with " unknown filesystem type 'linux_raid_member'"
Hi,
I had an old NAS - single drive so no RAID that I configured.
Built the disk into a system I installed ubunto onto in the hopes of getting my data back. The disk is giving a SMART error, so it cannot/will not boot anymore - but seems to be okay as 'just a disk'.
Without copying/pasting check out the thread on hardforums. This is caused by a software layer raid that was implemented on the drive. Probably automatically by your NAS. You will need to mount it with mdadm and try to rebuild it to access your data.
Hopefully this is a linear - those partitions being different sizes. But don't go messing with anything (particularly partition type) till you know what you're dealing with.
The second thread you posted probably has all the doco you need. Let's see the output of
Yes the /proc/mdadm file is going to be a great place to look. Depending upon the output and what info is actually missing an mdadm with a scan argument may fill in the missing info and get you there.
You could also try explicitly specifying the file system type on the mount command and see if that works, its kind of hit or miss in this situation. Try adding a "-t ext3" to your mount command and see if it takes.
Mounting with -t ext3 took longer for a reply, but still no success.
Code:
root@ubuntu:~# mount -r -t ext3 /dev/sdb4 /data/x052
mount: wrong fs type, bad option, bad superblock on /dev/sdb4,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
Not accustomed on AIX to rebooting after installing, I suspect this is not a solution for Linux either, but will try a reboot before proceeding.
Before I try a mdadm command going to read the help and hop to understand that (a bit of explanation is missing in your 3-year post, but :smiley" when I saw type 'fd'!
After a reboot - had to reattach a keyboard and monitor to see I needed to press F1.
reboot was needed because system no longer saw disk (after the -t ext3 mount command I expect)
System (on console) said something about degraded state - I said yes, and mdadm starting doing "stuff"
Code:
root@ubuntu:~# mdadm -Q /dev/sdb4
/dev/sdb4: is not an md array
/dev/sdb4: device 0 in 2 device active raid1 /dev/md4. Use mdadm --examine for more detail.
I am guessing that the mdX devices are virtualizations of the sdbX devices.
Code:
root@ubuntu:~# ls -l /dev/md?
brw-rw---- 1 root disk 9, 1 Jan 16 14:13 /dev/md1
brw-rw---- 1 root disk 9, 2 Jan 16 14:13 /dev/md2
brw-rw---- 1 root disk 9, 3 Jan 16 14:13 /dev/md3
brw-rw---- 1 root disk 9, 4 Jan 16 14:13 /dev/md4
root@ubuntu:~# ls -l /dev/sdb?
brw-rw---- 1 root disk 8, 17 Jan 16 14:13 /dev/sdb1
brw-rw---- 1 root disk 8, 18 Jan 16 14:13 /dev/sdb2
brw-rw---- 1 root disk 8, 19 Jan 16 14:13 /dev/sdb3
brw-rw---- 1 root disk 8, 20 Jan 16 14:13 /dev/sdb4
Still no /proc/mdadm info
Code:
root@ubuntu:~# cat /proc/mdadm
cat: /proc/mdadm: No such file or directory
So, back to mdadm's suggestion to examine...
Code:
root@ubuntu:~# mdadm --help-options | grep examine
or, for --examine-bitmap, a file name.
--examine -E : Examine superblock on an array component
--examine-bitmap -X: Display the detail of a bitmap file
Hmm, was the NAT being tricky entering the device twice? Or does this mean something else.
Will wait for assistance now ... (note: I will probably not be able to look at this tomorrow, so my responses will be delayed).
Code:
root@ubuntu:~# mdadm -E /dev/md4
mdadm: No md superblock detected on /dev/md4.
root@ubuntu:~# mdadm -E /dev/sdb4
/dev/sdb4:
Magic : a92b4efc
Version : 0.90.00
UUID : a6ebb52b:a91421c4:a20483f2:e535f949
Creation Time : Thu Jan 24 10:51:54 2002
Raid Level : raid1
Used Dev Size : 728515520 (694.77 GiB 746.00 GB)
Array Size : 728515520 (694.77 GiB 746.00 GB)
Raid Devices : 2
Total Devices : 1
Preferred Minor : 4
Update Time : Wed Jan 16 15:13:10 2013
State : clean
Active Devices : 1
Working Devices : 1
Failed Devices : 1
Spare Devices : 0
Checksum : 39576ddd - correct
Events : 2063303
Number Major Minor RaidDevice State
this 0 8 20 0 active sync /dev/sdb4
0 0 8 20 0 active sync /dev/sdb4
1 1 0 0 1 faulty removed
root@ubuntu:~#
Still where I started...
Code:
root@ubuntu:~# mount -r /dev/sdb4 /data/x052
mount: unknown filesystem type 'linux_raid_member'
The error indicates that the superblock has this drive set to be one of the members of a two drive RAID1 software raid setup. This was more than likely implemented by the NAS automatically without your knowledge. Good news, its a RAID1 and you should be able to get your data back without much trouble.
So you should be able to do the mdadm assemble with the run option to get it mounted. It will just be in a "degraded" state forever unless you get a second drive rebuilt into the array.
This is the second time I run these steps, first time was on a console so I could not cut/paste the output.
stderr had many errors, so I suspect the disk is, for all effective purposes - dead.
What I could see this time:
Code:
root@ubuntu:~# fdisk -l /dev/sdb
Disk /dev/sdb: 750.2 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00007c00
Device Boot Start End Blocks Id System
/dev/sdb1 48195 5927984 2939895 fd Linux raid autodetect
/dev/sdb2 5927985 6136829 104422+ fd Linux raid autodetect
/dev/sdb3 6136830 8112824 987997+ fd Linux raid autodetect
/dev/sdb4 8112825 1465144064 728515620 fd Linux raid autodetect
root@ubuntu:~# mdadm -A -R /dev/md4 /dev/sdb4
mdadm: /dev/sdb4 is busy - skipping
root@ubuntu:~# mount /dev/sdb4 /data/x053
mount: unknown filesystem type 'linux_raid_member'
root@ubuntu:~# mount /dev/md4 /data/x053
mount: wrong fs type, bad option, bad superblock on /dev/md4,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
root@ubuntu:~# fdisk -l /dev/sdb
Note: this was a single disk NAS (WD "blue ring" something book), so yes, it made it RAID without me ever knowing
=== update ===
found messages - presented courtesy of dmesg
just the end, there are many many more.
No. I tried several times, but it seems the disk is too far damaged for any recovery using simple hardware.
Good luck!
I do want to add that the suggestions provided (which I have now forgotten) seemed very promising and worth the effort. But sometimes a disk is just "gone".
Now I have a real RAID6 NAS, and have a spare in the closet.
Last edited by Michael AM; 06-18-2013 at 04:51 PM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.