Skip to content
View in the app

A better way to browse. Learn more.

Unraid

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Restarting the array gives "Unmountable: Unsupported partition layout"

Featured Replies

Hello, new user here !

 

I recently installed Unraid and was working great. My layout is a single 14 tb HDD (zfs) in the array and 2*2tb ssd in a zfs mirror pool. No parity drive for the moment. The 14tb spinner in the array was working fine for approx. a month. I have another 2 14tb HDD as unassigned for the time being, just lying there, recently finished pre-clearing them.

 

What happened: I stopped the array and upon restarting it I get the error "Unmountable: Unsupported partition layout" in the single 14tb HDD in the array. Disk looks fine in SMART and was working fine also until the array stop/start. The only thing changed was an array stop-start. I am attaching diagnostics and would appreciate any help !

myserver-diagnostics-20231209-1430.zip

  • Community Expert

Post the output of:

 

fdisk -l /dev/sdb

 

  • Author

this is the output:

 

root@myserver:~# fdisk -l /dev/sdb
Disk /dev/sdb: 12.73 TiB, 14000519643136 bytes, 3418095616 sectors
Disk model: ST14000NM001G-2K
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

 

for comparison, the other two (unassigned, just pre cleared) disks:

 

root@myserver:~# fdisk -l /dev/sdc
Disk /dev/sdc: 12.73 TiB, 14000519643136 bytes, 3418095616 sectors
Disk model: ST14000NM001G-2K
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot Start        End    Sectors Size Id Type
/dev/sdc1           1 4294967295 4294967295  16T  0 Empty
root@myserver:~# fdisk -l /dev/sdd
Disk /dev/sdd: 12.73 TiB, 14000519643136 bytes, 3418095616 sectors
Disk model: ST14000NM001G-2K
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot Start        End    Sectors Size Id Type
/dev/sdd1           1 4294967295 4294967295  16T  0 Empty

 

Edited by kokni

  • Community Expert

Disk1 has no partition, something likely clobbered the MBR, before rebooting it would still use in-memory structures and everything continues to work normally, any idea what could have done that? Did you run any wipefs or similar command?

  • Author

I have some understanding of the command line, and I can certainly say that I have not run any disk-related commands.

 

The only close hit that I can relate with, is that some days ago I installed the unassigned drives plugin, and using destructive mode precleared the two additional disks. But these operations were performed with the array online and the disk in question (single member of the array) was not an option anyway for me to mess with by mistake.

 

Anyway, that was a zfs formatted drive with unraid. Is there any chance to recover data (it was nearly full) or is it a write off?

 

If it matters, the disk in question was previously on a QNAP QTS 5.0 system. I removed it, installed it in a vanilla Unraid system, assigned it to the array, formatted through the GUI and used it. At that time I did not know about plugins, pre clearing etc. Could it be that the partitions from QNAP QTS were carried over and hence the problem now or am I talking nonsense?

 

  • Community Expert

You may be able to recover the old partition with testdisk or by recreating it, testdisk would be safer, recreating the Unraid default partition layout *should* also work, but cannot guarantee, you can clone the disk with dd first to play it safer, then:

 

sgdisk -o -a 8 -n 1:32K:0 /dev/sdX

 

Then re-start the array, I think a reboot won't be needed but try if it still doesn't work, if it still complains about the layout the disk should now at least be mountable with UD.

  • Community Expert
29 minutes ago, kokni said:

The only close hit that I can relate with, is that some days ago I installed the unassigned drives plugin, and using destructive mode precleared the two additional disks.

Unlikely that would have done it, but assuming no diags before the reboot no way to be certain.

  • Author

Hello Jorge, many thanks for your help.

 

while waiting for dd to finish a clone I did some testing:

 

1) I recreated with a spare disk the exact steps, the resulting EFI GPT partition table is:

 

Disk /dev/sdd - 14 TB / 12 TiB - CHS 212766 255 63
Current partition structure:
     Partition                  Start        End    Size in sectors

 1 P Linux filesys. data            8 3418095610 3418095603

 

So, this is what I should try to recreate I guess.

 

2) On the *failed* disk, testdisk shows

 

Disk /dev/sdb - 14 TB / 12 TiB - CHS 212766 255 63
Current partition structure:
     Partition                  Start        End    Size in sectors

Bad GPT partition, invalid signature.
Trying alternate GPT
 1 P Linux filesys. data            8 3418095610 3418095603

 

but the next step takes ages and more alarmingly, it fins partitions from the previous raid5 membership on a qnap system.

 

I also run gdisk. It finds the following:

 

GPT fdisk (gdisk) version 1.0.9.1

Caution: invalid main GPT header, but valid backup; regenerating main header
from backup!

Warning: Invalid CRC on main header data; loaded backup partition table.
Warning! Main and backup partition tables differ! Use the 'c' and 'e' options
on the recovery & transformation menu to examine the two tables.

Warning! Main partition table CRC mismatch! Loaded backup partition table
instead of main partition table!

Warning! One or more CRCs don't match. You should repair the disk!
Main header: ERROR
Backup header: OK
Main partition table: ERROR
Backup partition table: OK

Partition table scan:
  MBR: not present
  BSD: not present
  APM: not present
  GPT: damaged

Found invalid MBR and corrupt GPT. What do you want to do? (Using the
GPT MAY permit recovery of GPT data.)
 1 - Use current GPT
 2 - Create blank GPT

 

Selecting "Use current GPT" I get

 

Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
Partition unique GUID: 89773B4D-0457-4CD3-AE4D-A6CE3B7B16D1
First sector: 8 (at 32.0 KiB)
Last sector: 3418095610 (at 12.7 TiB)
Partition size: 3418095603 sectors (12.7 TiB)
Attribute flags: 0000000000000000
Partition name: ''

 

Which looks the same as testdisk.

 

I do not understand well the testdisk program, and the old (raid5) partitions that appear scare me.

 

So, the question: use the command suggested by you above, or use gdisk and try to copy the backup to the main (described here) ?

  • Community Expert
33 minutes ago, kokni said:

or use gdisk and try to copy the backup to the main

I would try this first, then if still the same recreate the partition with that command.

  • Author

I worked with gdisk, I restored the backup to the main entry and everything is OK with no data loss. Thanks for your guidance !!!

 

However, at this point I have zero faith in how Unraid handled the installed disks, so as a precaution I checked my mirrored zfs pool, which seemingly works for the moment. But see below:

 

fdisk -l /dev/nvme0n1
Disk /dev/nvme0n1: 1.86 TiB, 2048408248320 bytes, 4000797360 sectors
Disk model: TEAM TM8FPD002T                         
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: 0x00000000

Device         Boot Start        End    Sectors  Size Id Type
/dev/nvme0n1p1       2048 4000797359 4000795312  1.9T 83 Linux

 

and

 

root@myserver:~# gdisk /dev/nvme0n1
GPT fdisk (gdisk) version 1.0.9.1

Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: not present


***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by
typing 'q' if you don't want to convert your MBR partitions
to GPT format!
***************************************************************


Warning! Secondary partition table overlaps the last partition by
33 blocks!
You will need to delete this partition or resize it in another utility.



Disk /dev/nvme0n1 - 2048 GB / 1907 GiB - CHS 1953514 64 32
Current partition structure:
     Partition                  Start        End    Size in sectors

No ext2, JFS, Reiser, cramfs or XFS marker
 1 P Linux                    1   0  1 1953514  21 16 4000795312
 1 P Linux                    1   0  1 1953514  21 16 4000795312

Warning: Bad starting sector (CHS and LBA don't match)
No partition is bootable

 

 

@JorgeB this was a pair of nvme's, installed and assigned as a zfs mirrored pool, formatted through the GUI and that's it. How on earth did the above happened, which is a disaster waiting to happen? I really do not understand what destroyed all the GPT/MBR entries.

  • Community Expert

The fdisk output for the pool looks normal, were these brand new devices or have they been used before elsewhere?

  • Author
45 minutes ago, JorgeB said:

The fdisk output for the pool looks normal, were these brand new devices or have they been used before elsewhere?

 

It looks deceptively normal, but please note that it is disktype=dos instead of disktype=gpt and moreover testdisk recognizes "intel" partition table type instead of "efi-gpt".

 

Indeed, all drives were previously on a QNAP QTS 5.0 system, which I believe is the root of all problems.

 

I had the (wrong?) immersion that bringing the drives into Unraid, assigning them to arrays/pools and formatting them through the GUI would also take care of the correct MBR/GPT. Apparently, this sequence causes problems with drives coming from a QNAP QTS5.0 system? 

 

 

edit: also, not sure about the 512 sector being optimal, investigating this now.

Edited by kokni

  • Community Expert
27 minutes ago, kokni said:

It looks deceptively normal, but please note that it is disktype=dos instead of disktype=gpt and moreover testdisk recognizes "intel" partition table type instead of "efi-gpt".

That's normal, Unraid only creates GPT partitions for devices >2TB.

 

 

 

 

  • Author

Ah, thanks for this clarification. How should I proceed then, leave it as is despite the warnings or destroy the pool and start over?

 

Also, I hope to upgrade to 4gb mirror soon. When I will replace the first 2tb with a 4tb, will the zfs pool resilver without problems with one disk being MBR and the new GPT?

  • Community Expert
12 hours ago, kokni said:

How should I proceed then, leave it as is despite the warnings or destroy the pool and start over?

I'd leave it, warnings might be because gdisk is to be used with GPT partitions.

 

12 hours ago, kokni said:

When I will replace the first 2tb with a 4tb, will the zfs pool resilver without problems with one disk being MBR and the new GPT?

Correct.

 

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...

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.