mdadm - Drive has incorrect type after rebootFailed MDADM Array With Ext.4 Partition - “e2fsck: unable to...
Finding ratio of the area of triangles
What does a violin mute do?
How to push a box with physics engine by another object?
How to satisfy a player character's curiosity about another player character?
I am on the US no-fly list. What can I do in order to be allowed on flights which go through US airspace?
How should I state my MS degree in my CV when it was in practice a joint-program?
Where was Karl Mordo in Infinity War?
Has the Isbell–Freyd criterion ever been used to check that a category is concretisable?
Should I choose Itemized or Standard deduction?
Why is working on the same position for more than 15 years not a red flag?
What is the purpose of easy combat scenarios that don't need resource expenditure?
4 Spheres all touching each other??
Connecting top and bottom of adjacent circles
Crystal compensation for temp and voltage
Why is this code uniquely decodable?
Is 45 min enough time to catch my next flight in Copenhagen?
Am I a Rude Number?
Why is c4 a better move in this position?
Why does the DC-9-80 have this cusp in its fuselage?
How to approximate rolls for potions of healing using only d6's?
How would an AI self awareness kill switch work?
Using AWS Fargate as web server
Metadata API deployments are failing in Spring '19
What's the rationale behind the objections to these measures against human trafficking?
mdadm - Drive has incorrect type after reboot
Failed MDADM Array With Ext.4 Partition - “e2fsck: unable to set superblock flags on /dev/md0”mdadm raid5 failure. set wrong drive to faulty by accidentmdadm RAID 5 array stopped mountingmdadm raid1, [1/2] disks failed, safe to reboot?mdadm: drive replacement shows up as spare and refuses to syncHow to fix my broken raid10 arraymdadm, RAID5 all disks marked as spare, won't startmdadm RAID6, recover 2 disk failure during reshapeRecover MDADM compatible RAID5 arrayJBOD Failed to assemble after middle device Failed
I have a raid 6 setup with six drives using mdadm. I noticed I had a failed drive (b) that was not responding at all. Making sure all drives are properly connected I stopped the raid, unmounted and shutdown my computer. When starting it back up mdadm where unable to recreate the array. The failed drive (b) where back and working, even detected by mdadm, however two of the other drives (d & f) were not picked up by mdadm despite both functioning beforehand. They now show up as "Micsrosoft reserved". Various status command output,
Output: fdisk -l /dev/sda /dev/sdd
Disk /dev/sda: 1,8 TiB, 2000398934016 bytes, 3907029168 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
Disklabel type: dos
Disk identifier: 0x9ac08c50
Device Boot Start End Sectors Size Id Type
/dev/sda1 1 4294967295 4294967295 2T ee GPT
Disk /dev/sdd: 1,8 TiB, 2000398934016 bytes, 3907029168 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
Disklabel type: gpt
Disk identifier: D599B9D7-1648-11E7-9C1F-74D02B2AF0E1
Device Start End Sectors Size Type
/dev/sdd1 34 262177 262144 128M Microsoft reserved
Output: mdadm -E /dev/sda /dev/sdd
/dev/sda:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 0773fa22:7212c43a:5ce8bee0:6669d442
Name : server:0
Creation Time : Sat Sep 15 07:48:01 2018
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3906764976 (1862.89 GiB 2000.26 GB)
Array Size : 7813529600 (7451.56 GiB 8001.05 GB)
Used Dev Size : 3906764800 (1862.89 GiB 2000.26 GB)
Data Offset : 264192 sectors
Super Offset : 8 sectors
Unused Space : before=264112 sectors, after=176 sectors
State : clean
Device UUID : 9acb67e2:e0c688d0:092e1803:d422b511
Internal Bitmap : 8 sectors from superblock
Update Time : Tue Jan 8 00:16:14 2019
Bad Block Log : 512 entries available at offset 16 sectors
Checksum : bf1d961a - correct
Events : 32944
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 0
Array State : A.AAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdd:
MBR Magic : aa55
Partition[0] : 4294967295 sectors at 1 (type ee)
Output: mdadm -D /dev/md0
/dev/md0:
Version : 1.2
Raid Level : raid0
Total Devices : 4
Persistence : Superblock is persistent
State : inactive
Working Devices : 4
Name : server:0
UUID : 0773fa22:7212c43a:5ce8bee0:6669d442
Events : 32944
Number Major Minor RaidDevice
- 8 64 - /dev/sde
- 8 32 - /dev/sdc
- 8 0 - /dev/sda
- 8 16 - /dev/sdb
Trying to assemble the array using mdadm --assemble fails with,
mdadm: Cannot assemble mbr metadata on /dev/sdd
mdadm: /dev/sdd has no superblock - assembly aborted
Any ideas?
raid mdadm
asked Jan 8 at 14:49
ChristerChrister
1165
add a comment |
I have a raid 6 setup with six drives using mdadm. I noticed I had a failed drive (b) that was not responding at all. Making sure all drives are properly connected I stopped the raid, unmounted and shutdown my computer. When starting it back up mdadm where unable to recreate the array. The failed drive (b) where back and working, even detected by mdadm, however two of the other drives (d & f) were not picked up by mdadm despite both functioning beforehand. They now show up as "Micsrosoft reserved". Various status command output,
Output: fdisk -l /dev/sda /dev/sdd
Disk /dev/sda: 1,8 TiB, 2000398934016 bytes, 3907029168 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
Disklabel type: dos
Disk identifier: 0x9ac08c50
Device Boot Start End Sectors Size Id Type
/dev/sda1 1 4294967295 4294967295 2T ee GPT
Disk /dev/sdd: 1,8 TiB, 2000398934016 bytes, 3907029168 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
Disklabel type: gpt
Disk identifier: D599B9D7-1648-11E7-9C1F-74D02B2AF0E1
Device Start End Sectors Size Type
/dev/sdd1 34 262177 262144 128M Microsoft reserved
Output: mdadm -E /dev/sda /dev/sdd
/dev/sda:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 0773fa22:7212c43a:5ce8bee0:6669d442
Name : server:0
Creation Time : Sat Sep 15 07:48:01 2018
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3906764976 (1862.89 GiB 2000.26 GB)
Array Size : 7813529600 (7451.56 GiB 8001.05 GB)
Used Dev Size : 3906764800 (1862.89 GiB 2000.26 GB)
Data Offset : 264192 sectors
Super Offset : 8 sectors
Unused Space : before=264112 sectors, after=176 sectors
State : clean
Device UUID : 9acb67e2:e0c688d0:092e1803:d422b511
Internal Bitmap : 8 sectors from superblock
Update Time : Tue Jan 8 00:16:14 2019
Bad Block Log : 512 entries available at offset 16 sectors
Checksum : bf1d961a - correct
Events : 32944
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 0
Array State : A.AAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdd:
MBR Magic : aa55
Partition[0] : 4294967295 sectors at 1 (type ee)
Output: mdadm -D /dev/md0
/dev/md0:
Version : 1.2
Raid Level : raid0
Total Devices : 4
Persistence : Superblock is persistent
State : inactive
Working Devices : 4
Name : server:0
UUID : 0773fa22:7212c43a:5ce8bee0:6669d442
Events : 32944
Number Major Minor RaidDevice
- 8 64 - /dev/sde
- 8 32 - /dev/sdc
- 8 0 - /dev/sda
- 8 16 - /dev/sdb
Trying to assemble the array using mdadm --assemble fails with,
mdadm: Cannot assemble mbr metadata on /dev/sdd
mdadm: /dev/sdd has no superblock - assembly aborted
Any ideas?
raid mdadm
asked Jan 8 at 14:49
ChristerChrister
1165
It looks like there's a guid partition table on sda and sdd? Did you make the array out of the partitions sda1 and sdd1, etc.? If so, you'll want to assemble the array with the partitions, not with the underlying devices.
– Mike Andrews
Jan 8 at 18:20
@MikeAndrews no, I am fairly certain that I used the raw block devices themselves. Actually all six drives has a GPT on them with with the words "Micsrosoft reserved" when I look at the raw bytes on the drives. I think actually it's leftover data from previous use. The only difference I see is that sdd and sdf both have just zeros where the other ones have their RAID superblock. So the superblock does actually seem to just be done, somehow. :/
– Christer
Jan 8 at 18:47
add a comment |
I have a raid 6 setup with six drives using mdadm. I noticed I had a failed drive (b) that was not responding at all. Making sure all drives are properly connected I stopped the raid, unmounted and shutdown my computer. When starting it back up mdadm where unable to recreate the array. The failed drive (b) where back and working, even detected by mdadm, however two of the other drives (d & f) were not picked up by mdadm despite both functioning beforehand. They now show up as "Micsrosoft reserved". Various status command output,
Output: fdisk -l /dev/sda /dev/sdd
Disk /dev/sda: 1,8 TiB, 2000398934016 bytes, 3907029168 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
Disklabel type: dos
Disk identifier: 0x9ac08c50
Device Boot Start End Sectors Size Id Type
/dev/sda1 1 4294967295 4294967295 2T ee GPT
Disk /dev/sdd: 1,8 TiB, 2000398934016 bytes, 3907029168 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
Disklabel type: gpt
Disk identifier: D599B9D7-1648-11E7-9C1F-74D02B2AF0E1
Device Start End Sectors Size Type
/dev/sdd1 34 262177 262144 128M Microsoft reserved
Output: mdadm -E /dev/sda /dev/sdd
/dev/sda:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 0773fa22:7212c43a:5ce8bee0:6669d442
Name : server:0
Creation Time : Sat Sep 15 07:48:01 2018
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3906764976 (1862.89 GiB 2000.26 GB)
Array Size : 7813529600 (7451.56 GiB 8001.05 GB)
Used Dev Size : 3906764800 (1862.89 GiB 2000.26 GB)
Data Offset : 264192 sectors
Super Offset : 8 sectors
Unused Space : before=264112 sectors, after=176 sectors
State : clean
Device UUID : 9acb67e2:e0c688d0:092e1803:d422b511
Internal Bitmap : 8 sectors from superblock
Update Time : Tue Jan 8 00:16:14 2019
Bad Block Log : 512 entries available at offset 16 sectors
Checksum : bf1d961a - correct
Events : 32944
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 0
Array State : A.AAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdd:
MBR Magic : aa55
Partition[0] : 4294967295 sectors at 1 (type ee)
Output: mdadm -D /dev/md0
/dev/md0:
Version : 1.2
Raid Level : raid0
Total Devices : 4
Persistence : Superblock is persistent
State : inactive
Working Devices : 4
Name : server:0
UUID : 0773fa22:7212c43a:5ce8bee0:6669d442
Events : 32944
Number Major Minor RaidDevice
- 8 64 - /dev/sde
- 8 32 - /dev/sdc
- 8 0 - /dev/sda
- 8 16 - /dev/sdb
Trying to assemble the array using mdadm --assemble fails with,
mdadm: Cannot assemble mbr metadata on /dev/sdd
mdadm: /dev/sdd has no superblock - assembly aborted
Any ideas?
raid mdadm
asked Jan 8 at 14:49
ChristerChrister
1165
I have a raid 6 setup with six drives using mdadm. I noticed I had a failed drive (b) that was not responding at all. Making sure all drives are properly connected I stopped the raid, unmounted and shutdown my computer. When starting it back up mdadm where unable to recreate the array. The failed drive (b) where back and working, even detected by mdadm, however two of the other drives (d & f) were not picked up by mdadm despite both functioning beforehand. They now show up as "Micsrosoft reserved". Various status command output,
Output: fdisk -l /dev/sda /dev/sdd
Disk /dev/sda: 1,8 TiB, 2000398934016 bytes, 3907029168 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
Disklabel type: dos
Disk identifier: 0x9ac08c50
Device Boot Start End Sectors Size Id Type
/dev/sda1 1 4294967295 4294967295 2T ee GPT
Disk /dev/sdd: 1,8 TiB, 2000398934016 bytes, 3907029168 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
Disklabel type: gpt
Disk identifier: D599B9D7-1648-11E7-9C1F-74D02B2AF0E1
Device Start End Sectors Size Type
/dev/sdd1 34 262177 262144 128M Microsoft reserved
Output: mdadm -E /dev/sda /dev/sdd
/dev/sda:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 0773fa22:7212c43a:5ce8bee0:6669d442
Name : server:0
Creation Time : Sat Sep 15 07:48:01 2018
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3906764976 (1862.89 GiB 2000.26 GB)
Array Size : 7813529600 (7451.56 GiB 8001.05 GB)
Used Dev Size : 3906764800 (1862.89 GiB 2000.26 GB)
Data Offset : 264192 sectors
Super Offset : 8 sectors
Unused Space : before=264112 sectors, after=176 sectors
State : clean
Device UUID : 9acb67e2:e0c688d0:092e1803:d422b511
Internal Bitmap : 8 sectors from superblock
Update Time : Tue Jan 8 00:16:14 2019
Bad Block Log : 512 entries available at offset 16 sectors
Checksum : bf1d961a - correct
Events : 32944
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 0
Array State : A.AAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdd:
MBR Magic : aa55
Partition[0] : 4294967295 sectors at 1 (type ee)
Output: mdadm -D /dev/md0
/dev/md0:
Version : 1.2
Raid Level : raid0
Total Devices : 4
Persistence : Superblock is persistent
State : inactive
Working Devices : 4
Name : server:0
UUID : 0773fa22:7212c43a:5ce8bee0:6669d442
Events : 32944
Number Major Minor RaidDevice
- 8 64 - /dev/sde
- 8 32 - /dev/sdc
- 8 0 - /dev/sda
- 8 16 - /dev/sdb
Trying to assemble the array using mdadm --assemble fails with,
mdadm: Cannot assemble mbr metadata on /dev/sdd
mdadm: /dev/sdd has no superblock - assembly aborted
Any ideas?
raid mdadm
raid mdadm
asked Jan 8 at 14:49
ChristerChrister
1165
asked Jan 8 at 14:49
ChristerChrister
1165
asked Jan 8 at 14:49
ChristerChrister
1165
asked Jan 8 at 14:49
ChristerChrister
1165
asked Jan 8 at 14:49
ChristerChrister
1165
1165
It looks like there's a guid partition table on sda and sdd? Did you make the array out of the partitions sda1 and sdd1, etc.? If so, you'll want to assemble the array with the partitions, not with the underlying devices.
– Mike Andrews
Jan 8 at 18:20
@MikeAndrews no, I am fairly certain that I used the raw block devices themselves. Actually all six drives has a GPT on them with with the words "Micsrosoft reserved" when I look at the raw bytes on the drives. I think actually it's leftover data from previous use. The only difference I see is that sdd and sdf both have just zeros where the other ones have their RAID superblock. So the superblock does actually seem to just be done, somehow. :/
– Christer
Jan 8 at 18:47
add a comment |
It looks like there's a guid partition table on sda and sdd? Did you make the array out of the partitions sda1 and sdd1, etc.? If so, you'll want to assemble the array with the partitions, not with the underlying devices.
– Mike Andrews
Jan 8 at 18:20
@MikeAndrews no, I am fairly certain that I used the raw block devices themselves. Actually all six drives has a GPT on them with with the words "Micsrosoft reserved" when I look at the raw bytes on the drives. I think actually it's leftover data from previous use. The only difference I see is that sdd and sdf both have just zeros where the other ones have their RAID superblock. So the superblock does actually seem to just be done, somehow. :/
– Christer
Jan 8 at 18:47
It looks like there's a guid partition table on sda and sdd? Did you make the array out of the partitions sda1 and sdd1, etc.? If so, you'll want to assemble the array with the partitions, not with the underlying devices.
– Mike Andrews
Jan 8 at 18:20
It looks like there's a guid partition table on sda and sdd? Did you make the array out of the partitions sda1 and sdd1, etc.? If so, you'll want to assemble the array with the partitions, not with the underlying devices.
– Mike Andrews
Jan 8 at 18:20
@MikeAndrews no, I am fairly certain that I used the raw block devices themselves. Actually all six drives has a GPT on them with with the words "Micsrosoft reserved" when I look at the raw bytes on the drives. I think actually it's leftover data from previous use. The only difference I see is that sdd and sdf both have just zeros where the other ones have their RAID superblock. So the superblock does actually seem to just be done, somehow. :/
– Christer
Jan 8 at 18:47
@MikeAndrews no, I am fairly certain that I used the raw block devices themselves. Actually all six drives has a GPT on them with with the words "Micsrosoft reserved" when I look at the raw bytes on the drives. I think actually it's leftover data from previous use. The only difference I see is that sdd and sdf both have just zeros where the other ones have their RAID superblock. So the superblock does actually seem to just be done, somehow. :/
– Christer
Jan 8 at 18:47
add a comment |
1 Answer
1
active
oldest
votes
Ok, so through inspections I have come to the conclusion that the reason that it was detected as a "Microsoft reserved" partition is because those two drives somehow didn't in fact have their mdadm superblock anymore. The output of xxd -s 0x1000 -l 0x200 /dev/sdd confirmed that there was just zeroes on both d and f. No idea how this happened.
Mostly following this I eventually ended up recreating the array. Running the following command mdadm --create --assume-clean --level=6 --raid-devices=6 /dev/md0 /dev/sda missing /dev/sdc /dev/sdd /dev/sde /dev/sdf worked and after mounting as read only to check mount -o ro /dev/md0 /mnt the data were all there it seems.
Unfortunately this reset the event count among other things meaning that re-adding /dev/sdb didn't work so it's now recreating from scratch.
answered Jan 9 at 9:55
ChristerChrister
1165
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "2"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f948087%2fmdadm-drive-has-incorrect-type-after-reboot%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Ok, so through inspections I have come to the conclusion that the reason that it was detected as a "Microsoft reserved" partition is because those two drives somehow didn't in fact have their mdadm superblock anymore. The output of xxd -s 0x1000 -l 0x200 /dev/sdd confirmed that there was just zeroes on both d and f. No idea how this happened.
Mostly following this I eventually ended up recreating the array. Running the following command mdadm --create --assume-clean --level=6 --raid-devices=6 /dev/md0 /dev/sda missing /dev/sdc /dev/sdd /dev/sde /dev/sdf worked and after mounting as read only to check mount -o ro /dev/md0 /mnt the data were all there it seems.
Unfortunately this reset the event count among other things meaning that re-adding /dev/sdb didn't work so it's now recreating from scratch.
answered Jan 9 at 9:55
ChristerChrister
1165
add a comment |
Ok, so through inspections I have come to the conclusion that the reason that it was detected as a "Microsoft reserved" partition is because those two drives somehow didn't in fact have their mdadm superblock anymore. The output of xxd -s 0x1000 -l 0x200 /dev/sdd confirmed that there was just zeroes on both d and f. No idea how this happened.
Mostly following this I eventually ended up recreating the array. Running the following command mdadm --create --assume-clean --level=6 --raid-devices=6 /dev/md0 /dev/sda missing /dev/sdc /dev/sdd /dev/sde /dev/sdf worked and after mounting as read only to check mount -o ro /dev/md0 /mnt the data were all there it seems.
Unfortunately this reset the event count among other things meaning that re-adding /dev/sdb didn't work so it's now recreating from scratch.
answered Jan 9 at 9:55
ChristerChrister
1165
add a comment |
Ok, so through inspections I have come to the conclusion that the reason that it was detected as a "Microsoft reserved" partition is because those two drives somehow didn't in fact have their mdadm superblock anymore. The output of xxd -s 0x1000 -l 0x200 /dev/sdd confirmed that there was just zeroes on both d and f. No idea how this happened.
Mostly following this I eventually ended up recreating the array. Running the following command mdadm --create --assume-clean --level=6 --raid-devices=6 /dev/md0 /dev/sda missing /dev/sdc /dev/sdd /dev/sde /dev/sdf worked and after mounting as read only to check mount -o ro /dev/md0 /mnt the data were all there it seems.
Unfortunately this reset the event count among other things meaning that re-adding /dev/sdb didn't work so it's now recreating from scratch.
answered Jan 9 at 9:55
ChristerChrister
1165
Ok, so through inspections I have come to the conclusion that the reason that it was detected as a "Microsoft reserved" partition is because those two drives somehow didn't in fact have their mdadm superblock anymore. The output of xxd -s 0x1000 -l 0x200 /dev/sdd confirmed that there was just zeroes on both d and f. No idea how this happened.
Mostly following this I eventually ended up recreating the array. Running the following command mdadm --create --assume-clean --level=6 --raid-devices=6 /dev/md0 /dev/sda missing /dev/sdc /dev/sdd /dev/sde /dev/sdf worked and after mounting as read only to check mount -o ro /dev/md0 /mnt the data were all there it seems.
Unfortunately this reset the event count among other things meaning that re-adding /dev/sdb didn't work so it's now recreating from scratch.
answered Jan 9 at 9:55
ChristerChrister
1165
edited 12 hours ago
answered Jan 9 at 9:55
ChristerChrister
1165
answered Jan 9 at 9:55
ChristerChrister
1165
answered Jan 9 at 9:55
ChristerChrister
1165
1165
add a comment |
add a comment |
Thanks for contributing an answer to Server Fault!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f948087%2fmdadm-drive-has-incorrect-type-after-reboot%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
It looks like there's a guid partition table on sda and sdd? Did you make the array out of the partitions sda1 and sdd1, etc.? If so, you'll want to assemble the array with the partitions, not with the underlying devices.
– Mike Andrews
Jan 8 at 18:20
@MikeAndrews no, I am fairly certain that I used the raw block devices themselves. Actually all six drives has a GPT on them with with the words "Micsrosoft reserved" when I look at the raw bytes on the drives. I think actually it's leftover data from previous use. The only difference I see is that sdd and sdf both have just zeros where the other ones have their RAID superblock. So the superblock does actually seem to just be done, somehow. :/
– Christer
Jan 8 at 18:47