Array disks unmountable after reboot


Recommended Posts

Looking for assistance in recovering two of my data disks (all disks are xfs-encrypted) that have suddenly become "unmountable".  I was moving a bunch of small files to the array in Krusader that caused the user mount to go away.  I had seen this issue before, as this is a new server setup and I've been mass transferring files, so I made sure everything was stopped and restarted the machine.  After entering the decryption key and starting the array, two array disks with content are showing as unmountable and persists through subsequent restarts.

 

From looking at the diagnostics (attached), it appears it's related to:

 

PGVault emhttpd: error: ckmbr, 2263: No such file or directory (2): open: /dev/sdj1
...
PGVault emhttpd: error: ckmbr, 2263: No such file or directory (2): open: /dev/sdx1

 

Now into my speculations:

Somehow it appears these disks have lost their partition table?  This is my 1st time dealing with issues on encrypted disks, but I've had to conduct a similar rescue in the past.  Is it as simple as re-applying the partition table and viola, the data is accessible again?  If so, anyone have a good reference for doing so?  It's been awhile and I've got multiples of the same disk type to reference partition layout of.

 

Unraid v6.9.2

 

Spoiler

Unfortunately this was the last batch of information to move to the array before adding my parity disks (needed the raw write speed so I didn't spend 6 months transferring 205TB), so recovery via parity calculations isn't an option.

 

pgvault-diagnostics-20211116-1927.zip

Edited by Phuriousgeorge
Unraid version
Link to comment
root@PGVault:~# fdisk -l /dev/sdx
Disk /dev/sdx: 9.1 TiB, 10000831348736 bytes, 19532873728 sectors
Disk model: WDC WD100EMAZ-00
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 8881A93C-7815-4B51-BB9C-B79A125EB4A8

 

I didn't include the other disk because it consisted of easily-replaceable "Linux ISOs", so I've been experimenting with its headers...and failing.

Link to comment

So it's not partition corruption, it's completely missing, easiest way is to rebuild the disk(s), assuming parity is still valid, partition information is outside parity, and Unraid will recreate the partitions, you can easily test by unassigning one of the disks and start the array, if the emulated disk mounts correctly rebuild on top, then repeat for the other one.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.