[opensuse] need file from former md RAID1 member
My Google Fu isn't working very well. I need to mount the following ro long enough to find and fetch one file from what's showing up as /dev/md127. Base on a /unix.stackexchange.com page Google found[1] I tried mdadm -A /dev/sdg12 but get message device /dev/sdb12 exists but is not an md array. Of course, because it is only one of two original parts. I tried this from a different PC and get the same message. Also from that page I tried mdadm --assemble --scan which only got a usage message on the first machine, and got No arrays found in config file or automatically. On the second Next tried on first. mount -t ext4 -o ro,noatime /dev/sdg12 /mnt but get the message /dev/sdg12 is already mounted or /mnt busy df shows no use of either /mnt or sdg12, and there is no sdg<anything> showing as in use in /proc/mdstat. What do I need to do? The machine this disk came from is the one of two I'm currently trying to use for the recovery, but isn't necessary to the recovery, simply what was handy and known to have working RAID modules available. Its own RAID1 was migrated from 320GB disks to 500GB several years ago. # blkid /dev/sdg12 /dev/sdg12: UUID="fc3787e2-bc83-c66c-8afe-62881c75f7f0" UUID_SUB="40d2e084-2321-f3f4-f6f7-c64f526127f3" LABEL="5" TYPE="linux_raid_member" # mdadm --examine /dev/sdg12 /dev/sdg12: Magic : a92b4efc Version : 1.0 Feature Map : 0x1 Array UUID : fc3787e2:bc83c66c:8afe6288:1c75f7f0 Name : 5 Creation Time : Tue Jan 6 23:55:05 2009 Raid Level : raid1 Raid Devices : 2 Avail Dev Size : 2072296 (1011.86 MiB 1061.02 MB) Array Size : 1036148 (1011.86 MiB 1061.02 MB) Super Offset : 2072304 sectors Unused Space : before=0 sectors, after=8 sectors State : clean Device UUID : 40d2e084:2321f3f4:f6f7c64f:526127f3 Internal Bitmap : 2 sectors from superblock Update Time : Sat Apr 16 21:40:43 2011 Checksum : c6042453 - correct Events : 8 Device Role : Active device 0 Array State : AA ('A' == active, '.' == missing, 'R' == replacing) # cat /proc/mdstat Personalities : [raid1] md120 : inactive sdg13[0](S) 78140056 blocks super 1.0 md121 : inactive sdg14[0](S) 156280216 blocks super 1.0 md122 : inactive sdg8[1](S) 10650988 blocks super 1.0 md123 : inactive sdg10[0](S) 10650988 blocks super 1.0 md124 : inactive sdg9[0](S) 10650988 blocks super 1.0 md125 : inactive sdg11[0](S) 28362652 blocks super 1.0 md126 : inactive sdg7[1](S) 9422016 blocks super 1.0 md127 : inactive sdg12[0](S) 1036148 blocks super 1.0 md3 : active raid1 sdb11[3] sda11[2] 10650988 blocks super 1.0 [2/2] [UU] bitmap: 0/163 pages [0KB], 32KB chunk md0 : active raid1 sdb8[3] sda8[2] 9422016 blocks super 1.0 [2/2] [UU] bitmap: 0/144 pages [0KB], 32KB chunk md4 : active raid1 sda12[2] sdb12[3] 28362652 blocks super 1.0 [2/2] [UU] bitmap: 0/217 pages [0KB], 64KB chunk md7 : active raid1 sdb15[2] sda15[0] 156280216 blocks super 1.0 [2/2] [UU] bitmap: 0/2 pages [0KB], 65536KB chunk md6 : active raid1 sda14[2] sdb14[3] 78140056 blocks super 1.0 [2/2] [UU] bitmap: 0/150 pages [0KB], 256KB chunk md5 : active raid1 sdb13[3] sda13[2] 1036148 blocks super 1.0 [2/2] [UU] bitmap: 0/8 pages [0KB], 64KB chunk md2 : active raid1 sdb10[3] sda10[2] 10650988 blocks super 1.0 [2/2] [UU] bitmap: 0/163 pages [0KB], 32KB chunk md1 : active raid1 sdb9[3] sda9[2] 10650988 blocks super 1.0 [2/2] [UU] bitmap: 0/163 pages [0KB], 32KB chunk unused devices: <none> [1] https://unix.stackexchange.com/questions/64889/how-to-mount-recover-data-on-... -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-11-14 05:10, Felix Miata wrote:
My Google Fu isn't working very well. I need to mount the following ro long enough to find and fetch one file from what's showing up as /dev/md127.
Base on a /unix.stackexchange.com page Google found[1] I tried
mdadm -A /dev/sdg12
but get message
device /dev/sdb12 exists but is not an md array.
Of course, because it is only one of two original parts. I tried this from a different PC and get the same message. Also from that page I tried
mdadm --assemble --scan
which only got a usage message on the first machine, and got
No arrays found in config file or automatically.
On the second Next tried on first.
mount -t ext4 -o ro,noatime /dev/sdg12 /mnt
but get the message
/dev/sdg12 is already mounted or /mnt busy
df shows no use of either /mnt or sdg12, and there is no sdg<anything> showing as in use in /proc/mdstat.
It is part of /dev/md127, so you can not mount it separately while this is so. You may do, perhaps: mount -t ext4 -o ro,noatime /dev/md127 /mnt
# cat /proc/mdstat Personalities : [raid1] md120 : inactive sdg13[0](S) 78140056 blocks super 1.0
...
md127 : inactive sdg12[0](S) 1036148 blocks super 1.0
-- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Carlos E. R. composed on 2017-11-14 05:26 (UTC+0100):
Felix Miata wrote:
My Google Fu isn't working very well. I need to mount the following ro long enough to find and fetch one file from what's showing up as /dev/md127.
Base on a /unix.stackexchange.com page Google found[1] I tried
mdadm -A /dev/sdg12
but get message
device /dev/sdb12 exists but is not an md array.
Of course, because it is only one of two original parts. I tried this from a different PC and get the same message. Also from that page I tried
mdadm --assemble --scan
which only got a usage message on the first machine, and got
No arrays found in config file or automatically.
On the second Next tried on first.
mount -t ext4 -o ro,noatime /dev/sdg12 /mnt
but get the message
/dev/sdg12 is already mounted or /mnt busy
df shows no use of either /mnt or sdg12, and there is no sdg<anything> showing as in use in /proc/mdstat.
It is part of /dev/md127, so you can not mount it separately while this is so.
You may do, perhaps:
mount -t ext4 -o ro,noatime /dev/md127 /mnt
On 2nd machine, where it's sdb12 rather than sdg12, and md122 instead of md127: wrong fstype, bad option, bad superblock on /dev/md122 missing codepage or helper program, or other error dmesg says simply (md122) unable to read superblock.
# cat /proc/mdstat Personalities : [raid1] md120 : inactive sdg13[0](S) 78140056 blocks super 1.0
...
md127 : inactive sdg12[0](S) 1036148 blocks super 1.0-- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Felix Miata composed on 2017-11-13 23:51 (UTC-0500):
Carlos E. R. composed on 2017-11-14 05:26 (UTC+0100):
You may do, perhaps:
mount -t ext4 -o ro,noatime /dev/md127 /mnt
On 2nd machine, where it's sdb12 rather than sdg12, and md122 instead of md127:
wrong fstype, bad option, bad superblock on /dev/md122 missing codepage or helper program, or other error
dmesg says simply
(md122) unable to read superblock.
Turns out Carlos suggestion works fine when using the correct filesystem type, ext3. :-p And I had the wrong disk, so the needed file isn't on it. :-( -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-11-14 07:12, Felix Miata wrote:
Felix Miata composed on 2017-11-13 23:51 (UTC-0500):
Carlos E. R. composed on 2017-11-14 05:26 (UTC+0100):
You may do, perhaps:
mount -t ext4 -o ro,noatime /dev/md127 /mnt
On 2nd machine, where it's sdb12 rather than sdg12, and md122 instead of md127:
wrong fstype, bad option, bad superblock on /dev/md122 missing codepage or helper program, or other error
dmesg says simply
(md122) unable to read superblock.
Turns out Carlos suggestion works fine when using the correct filesystem type, ext3. :-p And I had the wrong disk, so the needed file isn't on it. :-(
Ah! :-) It would have worked out in "auto" mode, too. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 14/11/17 04:10, Felix Miata wrote:
My Google Fu isn't working very well. I need to mount the following ro long enough to find and fetch one file from what's showing up as /dev/md127.
Okay ...
Base on a /unix.stackexchange.com page Google found[1] I tried
mdadm -A /dev/sdg12
but get message
device /dev/sdb12 exists but is not an md array.
Of course, because it is only one of two original parts. I tried this from a different PC and get the same message. Also from that page I tried
You would do. Okay. When you boot the system, mdadm will probably try to create the array and stop. At which point, everything you try will fail because you've got a partially assembled, broken array.
mdadm --assemble --scan
Which will fail for the above reason ...
which only got a usage message on the first machine, and got
No arrays found in config file or automatically.
On the second Next tried on first.
mount -t ext4 -o ro,noatime /dev/sdg12 /mnt
but get the message
/dev/sdg12 is already mounted or /mnt busy
I'm a little surprised at that but not really, it probably failed for the same reason ...
df shows no use of either /mnt or sdg12, and there is no sdg<anything> showing as in use in /proc/mdstat.
What do I need to do?
Okay, this is simple. You've got a v1.0 mirror so ... "cat /proc/mdstat" tells you that sdg12 has been assembled into md127 so mdadm --stop /dev/md127 This will get rid of all the debris lying around the linux internals left by a partially assemmbled array. Next, try your mount command. I would expect it to work BUT. That's only true for a v1.0 mirror that hasn't been messed about with adding removing etc drives. Yours is v1.0, so you should be lucky. If that fails, then try mdadm --assemble /dev/sdg12 --force (You might need a number eg "mdadm --assemble /dev/md100 /dev/sdg12 --force". You can safely pick an unused number at random, but then cat /proc/mdstat to make sure mdadm hasn't changed it.) It should then mount okay. If it doesn't, try "mdadm --run /dev/md100" then try to mount it again. Once you've done a forced assembly, it should just work normally as a degraded array, so a reboot will have everything come back fine. Just remember, whenever you are troubleshooting a raid, be prepared REPEATEDLY to do a "mdadm --stop". Having a half-built array that refuses to do anything is the usual reason people complain that they can't fix a broken array. And rather than stackexchange, go and read the linux raid wiki :-) https://raid.wiki.kernel.org/index.php/Linux_Raid Cheers, Wol
The machine this disk came from is the one of two I'm currently trying to use for the recovery, but isn't necessary to the recovery, simply what was handy and known to have working RAID modules available. Its own RAID1 was migrated from 320GB disks to 500GB several years ago.
# blkid /dev/sdg12 /dev/sdg12: UUID="fc3787e2-bc83-c66c-8afe-62881c75f7f0" UUID_SUB="40d2e084-2321-f3f4-f6f7-c64f526127f3" LABEL="5" TYPE="linux_raid_member"
# mdadm --examine /dev/sdg12 /dev/sdg12: Magic : a92b4efc Version : 1.0 Feature Map : 0x1 Array UUID : fc3787e2:bc83c66c:8afe6288:1c75f7f0 Name : 5 Creation Time : Tue Jan 6 23:55:05 2009 Raid Level : raid1 Raid Devices : 2
Avail Dev Size : 2072296 (1011.86 MiB 1061.02 MB) Array Size : 1036148 (1011.86 MiB 1061.02 MB) Super Offset : 2072304 sectors Unused Space : before=0 sectors, after=8 sectors State : clean Device UUID : 40d2e084:2321f3f4:f6f7c64f:526127f3
Internal Bitmap : 2 sectors from superblock Update Time : Sat Apr 16 21:40:43 2011 Checksum : c6042453 - correct Events : 8
Device Role : Active device 0 Array State : AA ('A' == active, '.' == missing, 'R' == replacing)
# cat /proc/mdstat Personalities : [raid1] md120 : inactive sdg13[0](S) 78140056 blocks super 1.0
md121 : inactive sdg14[0](S) 156280216 blocks super 1.0
md122 : inactive sdg8[1](S) 10650988 blocks super 1.0
md123 : inactive sdg10[0](S) 10650988 blocks super 1.0
md124 : inactive sdg9[0](S) 10650988 blocks super 1.0
md125 : inactive sdg11[0](S) 28362652 blocks super 1.0
md126 : inactive sdg7[1](S) 9422016 blocks super 1.0
md127 : inactive sdg12[0](S) 1036148 blocks super 1.0
md3 : active raid1 sdb11[3] sda11[2] 10650988 blocks super 1.0 [2/2] [UU] bitmap: 0/163 pages [0KB], 32KB chunk
md0 : active raid1 sdb8[3] sda8[2] 9422016 blocks super 1.0 [2/2] [UU] bitmap: 0/144 pages [0KB], 32KB chunk
md4 : active raid1 sda12[2] sdb12[3] 28362652 blocks super 1.0 [2/2] [UU] bitmap: 0/217 pages [0KB], 64KB chunk
md7 : active raid1 sdb15[2] sda15[0] 156280216 blocks super 1.0 [2/2] [UU] bitmap: 0/2 pages [0KB], 65536KB chunk
md6 : active raid1 sda14[2] sdb14[3] 78140056 blocks super 1.0 [2/2] [UU] bitmap: 0/150 pages [0KB], 256KB chunk
md5 : active raid1 sdb13[3] sda13[2] 1036148 blocks super 1.0 [2/2] [UU] bitmap: 0/8 pages [0KB], 64KB chunk
md2 : active raid1 sdb10[3] sda10[2] 10650988 blocks super 1.0 [2/2] [UU] bitmap: 0/163 pages [0KB], 32KB chunk
md1 : active raid1 sdb9[3] sda9[2] 10650988 blocks super 1.0 [2/2] [UU] bitmap: 0/163 pages [0KB], 32KB chunk
unused devices: <none>
[1] https://unix.stackexchange.com/questions/64889/how-to-mount-recover-data-on-...
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (3)
-
Carlos E. R.
-
Felix Miata
-
Wols Lists