0

I have ubuntu raid5 on 4 disks of 1tb disks which had no dirty shutdown or power issue. The bootdisk is 5th disk which is not on mdadm. I also have XP on my bootdisk which I just started today. XP cannot mount mdadm or wont touch the disk, or so i thought.

Since closing XP, ubuntu wont boot cause maybe fstab is blocking it as it cannot mount /dev/md0 after waiting. Now i cannot get into my original ubuntu install.

So I removed all my raid members and put them all in my external disk bay and started ubuntu in my macbook to do recovery.

/dev/sdh:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 05143452:9d98ca6b:c59a91b5:fda8b846
           Name : vikas-VirtualBox:0
  Creation Time : Sat Dec 31 17:31:47 2016
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 1953263024 (931.39 GiB 1000.07 GB)
     Array Size : 2929889280 (2794.16 GiB 3000.21 GB)
  Used Dev Size : 1953259520 (931.39 GiB 1000.07 GB)
    Data Offset : 259072 sectors
   Super Offset : 8 sectors
   Unused Space : before=258984 sectors, after=6576 sectors
          State : clean
    Device UUID : b0cc00bc:b20c2671:1eb062bc:28eb229b

Internal Bitmap : 8 sectors from superblock
    Update Time : Fri Aug 11 17:08:49 2017
  Bad Block Log : 512 entries available at offset 72 sectors
       Checksum : 846ac784 - correct
         Events : 18840

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 2
   Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
===============================
/dev/sdf1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 05143452:9d98ca6b:c59a91b5:fda8b846
           Name : vikas-VirtualBox:0
  Creation Time : Sat Dec 31 17:31:47 2016
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 1953259520 (931.39 GiB 1000.07 GB)
     Array Size : 2929889280 (2794.16 GiB 3000.21 GB)
    Data Offset : 259072 sectors
   Super Offset : 8 sectors
   Unused Space : before=258984 sectors, after=3072 sectors
          State : clean
    Device UUID : a36f72c1:d4ec55f0:e4a4ff8a:19a0d659

    Update Time : Fri Aug 11 17:08:49 2017
  Bad Block Log : 512 entries available at offset 72 sectors
       Checksum : 965ce69e - expected 965ce69d
         Events : 18840

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 1
   Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
===============================
/dev/sde1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 05143452:9d98ca6b:c59a91b5:fda8b846
           Name : vikas-VirtualBox:0
  Creation Time : Sat Dec 31 17:31:47 2016
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 1953259520 (931.39 GiB 1000.07 GB)
     Array Size : 2929889280 (2794.16 GiB 3000.21 GB)
    Data Offset : 259072 sectors
   Super Offset : 8 sectors
   Unused Space : before=258984 sectors, after=3072 sectors
          State : clean
    Device UUID : 04920971:8ce054dc:4756516d:07eedc84

    Update Time : Fri Aug 11 17:08:49 2017
  Bad Block Log : 512 entries available at offset 72 sectors
       Checksum : 3f4afc07 - expected 3f4afc06
         Events : 18840

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 0
   Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
===============================
/dev/sdi:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 05143452:9d98ca6b:c59a91b5:fda8b846
           Name : vikas-VirtualBox:0
  Creation Time : Sat Dec 31 17:31:47 2016
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 1953263024 (931.39 GiB 1000.07 GB)
     Array Size : 2929889280 (2794.16 GiB 3000.21 GB)
  Used Dev Size : 1953259520 (931.39 GiB 1000.07 GB)
    Data Offset : 259072 sectors
   Super Offset : 8 sectors
   Unused Space : before=258984 sectors, after=6576 sectors
          State : clean
    Device UUID : 426c61e9:ea61c2f3:cf27167c:09807918

Internal Bitmap : 8 sectors from superblock
    Update Time : Fri Aug 11 17:08:49 2017
  Bad Block Log : 512 entries available at offset 72 sectors
       Checksum : 7171c8e1 - correct
         Events : 18840

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 3
   Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)

When I try assembly force:

sudo mdadm --assemble /dev/md0 --verbose --force --run /dev/sde1 /dev/sdf1 /dev/sdh /dev/sdi
mdadm: looking for devices for /dev/md0
mdadm: /dev/sde1 is identified as a member of /dev/md0, slot 0.
mdadm: /dev/sdf1 is identified as a member of /dev/md0, slot 1.
mdadm: /dev/sdh is identified as a member of /dev/md0, slot 2.
mdadm: /dev/sdi is identified as a member of /dev/md0, slot 3.
mdadm: added /dev/sdf1 to /dev/md0 as 1
mdadm: added /dev/sdh to /dev/md0 as 2
mdadm: added /dev/sdi to /dev/md0 as 3
mdadm: added /dev/sde1 to /dev/md0 as 0
mdadm: failed to RUN_ARRAY /dev/md0: Invalid argument

from dmesg:

[ 2208.363750] RAID conf printout:
[ 2208.363752]  --- level:5 rd:4 wd:4
[ 2208.363755]  disk 0, o:1, dev:sde1
[ 2208.363758]  disk 1, o:1, dev:sdf1
[ 2208.363760]  disk 2, o:1, dev:sdh
[ 2208.363763]  disk 3, o:1, dev:sdi
[ 2208.363994] md0: invalid bitmap file superblock: bad magic
[ 2208.363997] md0: bitmap file superblock:
[ 2208.364000]          magic: ff88ffff
[ 2208.364002]        version: 11
[ 2208.364005]           uuid: 00000000.00000000.00000000.00000000
[ 2208.364007]         events: 0
[ 2208.364009] events cleared: 0
[ 2208.364012]          state: 00000000
[ 2208.364014]      chunksize: 0 B
[ 2208.364016]   daemon sleep: 0s
[ 2208.364018]      sync size: 0 KB
[ 2208.364020] max write behind: 0
[ 2208.364023] md0: failed to create bitmap (-22)

My guess is somehow the XP boot must have touched these disk members and so magic differs.

I have seen option to --create new array but I am no sure if it will have data loss. secondly, if creating on a diff ubuntu, will it resume working on the other ubuntu?

Is there no easy way to just verify integrity and reset checksum for all members? Please suggest. Thanks.

1

I found this email thread, which seems to describe the same problem as yours.

The solution for that person was to run this command:

sudo mdadm -A --update=super-minor /dev/md0

That user wrote:

I figured this out myself through some sleuthing through the mdadm sources. It seems that mdadm clears the bitmap file automatically for an invalid bitmap when it reads the super block (The kernel does not however). So all you need to do is figure out a way for mdadm to save back that super block to the disk. The magic command for me that fixed the issue was:

mdadm -A --update=super-minor /dev/md0

The --update command forces mdadm to save back the raid super block to disk before it tries to mount the disk and hence the bitmap flag is cleared.

That user had metadata version 00.90.01, though, and according to the mdadm(8) man page:

super-minor is only relevant for v0.90 metadata

This means you should update the name of the array in your newer version 1.2 superblocks instead of the super-minor, which doesn't exist for version-1 metadata.

From the man page:

-U, --update=

Update the superblock on each device while assembling the array. The argument given to this flag can be one of sparc2.2, summaries, uuid, name, homehost, resync, byteorder, devicesize, no-bitmap, or super-minor.

The name option will change the name of the array as stored in the superblock. This is only supported for version-1 superblocks.

  • Getting mdadm: --update=super-minor not understood for 1.x metadata – thevikas Aug 11 '17 at 17:05
  • --update=name worked and I had active raid setup and got it working on my orig machine as well. thanks – thevikas Aug 11 '17 at 18:30
  • @thevikas: I've corrected my answer to apply to metadata version 1.2 – Deltik Aug 12 '17 at 8:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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