July 10, 20241 yr Hi folks, I can really use some help getting this problem resolved. I am on 6.12.1 with 1 parity, 1 cache, and 5 data disks in a zfs hybrid array. I was actually in the process of backing up my cache disk to swap it with a larger one when we had a power outage. When the system was powered up and the array started again three of the disks in it were showing "Unmountable, Unsupported". I believe that the problem is a result of a previously reported bug. When using fdisk to view the drive info I noticed that all three of the problematic drives show the "Disklabel type" as "dos" and the "Type" as Linux". The other drives show as GPT and seem to operate as they should. Using gdisk on one of the affected drives yields this result: ***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."** So this leads me to my post here today. I believe the solution is to repair the partition table on the affected disks and import the zpools to restore everything. Testdisk has saved my butt on many occasions in the past but I am not comfortable using gdisk. Can I simply use the Format function in the GUI without destroying the data on the disks? Is gdisk a better choice and if so, what are the steps in repairing the part table? Is there something better than either of those previous two options? I would really appreciate some help and guidance with this issue. I need help. To quote Maude Flanders "Won't somebody please think about the children?" -Cheers and Thanks Greg
July 10, 20241 yr Community Expert 27 minutes ago, Sonova_BeachBum said: I believe that the problem is a result of a previously reported bug. Not aware of any bug that would cause this. 27 minutes ago, Sonova_BeachBum said: When using fdisk to view the drive info I noticed that all three of the problematic drives show the "Disklabel type" as "dos" and the "Type" as Linux". The other drives show as GPT and seem to operate as they should. MBR should be used for drives up to 2TB, are they all the same size? Please post the diagnostics.
July 10, 20241 yr Author Yes, They are all 1.2TB. They are all set to "MBR 4Kb aligned". Perhaps it is not a a noted bug. I have been up all night on this and came across several mentions of an issue involving disks formatted ZFS over a former XFS type. Diagnostics coming shortly once system boots. I should also note that one issue from the 30,000 foot view is the RAID controller. It's a legacy HP with no HBA option. The disks are all set to RAID 0 and it will not pass through driver serial numbers. It's a hassle but i've been successfully working around it for a few years.
July 10, 20241 yr Community Expert 37 minutes ago, Sonova_BeachBum said: is the RAID controller. Very possibly. Some disks are showing invalid partition, but other don't even show a valid filesystem, post the output of blkid
July 10, 20241 yr Author blkid /dev/sda1: LABEL_FATBOOT="UNRAID" LABEL="UNRAID" UUID="272B-4CE1" BLOCK_SIZE="512" TYPE="vfat" /dev/loop1: TYPE="squashfs" /dev/sdf1: LABEL="disk5" UUID="4102616346420463541" UUID_SUB="11759275404662384013" BLOCK_SIZE="4096" TYPE="zfs_member" PARTUUID="a5baf8a1-01" /dev/sdd1: LABEL="disk1" UUID="3172973332698465298" UUID_SUB="12413462718045097097" BLOCK_SIZE="4096" TYPE="zfs_member" PARTUUID="a5ba988d-01" /dev/sdb: TYPE="zfs_member" /dev/md5p1: LABEL="disk5" UUID="4102616346420463541" UUID_SUB="11759275404662384013" BLOCK_SIZE="4096" TYPE="zfs_member" /dev/md1p1: LABEL="disk1" UUID="3172973332698465298" UUID_SUB="12413462718045097097" BLOCK_SIZE="4096" TYPE="zfs_member" /dev/sdg: TYPE="zfs_member" PTUUID="16b2fbf0-f299-4bac-bc0c-51aba9ee5d7d" PTTYPE="gpt" /dev/md4p1: LABEL="disk5" UUID="14652328161973356707" UUID_SUB="13778812108514822478" BLOCK_SIZE="4096" TYPE="zfs_member" /dev/loop0: TYPE="squashfs" /dev/sde: TYPE="zfs_member" PTUUID="a073e81f-77af-4d65-9cc8-b50153f0f20a" PTTYPE="gpt" /dev/sdc: TYPE="zfs_member" PTUUID="b8860f57-0511-4e4f-a915-d178b783a598" PTTYPE="gpt" /dev/md3p1: LABEL="disk5" UUID="11974352758200759327" UUID_SUB="8033002180000953218" BLOCK_SIZE="4096" TYPE="zfs_member" /dev/sdh1: LABEL="cache" UUID="1735300694171723445" UUID_SUB="4228319297741014893" BLOCK_SIZE="4096" TYPE="zfs_member" PARTUUID="a5c0740a-01" /dev/md6p1: LABEL="disk4" UUID="528979897614096157" UUID_SUB="10279172848350455314" BLOCK_SIZE="4096" TYPE="zfs_member"
July 10, 20241 yr Author I thought this might be significant. It's the first status that pops up when launching gdisk on one of the volumes. Is this normal? ***Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT.***
July 10, 20241 yr Community Expert 59 minutes ago, Sonova_BeachBum said: Is this normal? It's not normal if the disks were completely cleared before being used with Unraid, it can happen if they were used before with a different OS and were GPT formatted. With the array stopped post the output of zpool import
July 10, 20241 yr Author root@MEDIASYNC:~# zpool import pool: cache id: 1735300694171723445 state: ONLINE action: The pool can be imported using its name or numeric identifier. config: cache ONLINE sdh1 ONLINE pool: disk5 id: 4102616346420463541 state: UNAVAIL status: One or more devices contains corrupted data. action: The pool cannot be imported due to damaged devices or data. see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E config: disk5 UNAVAIL insufficient replicas md5p1 UNAVAIL invalid label pool: disk5 id: 14652328161973356707 state: ONLINE action: The pool can be imported using its name or numeric identifier. config: disk5 ONLINE md4p1 ONLINE pool: disk1 id: 3172973332698465298 state: UNAVAIL status: One or more devices contains corrupted data. action: The pool cannot be imported due to damaged devices or data. see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E config: disk1 UNAVAIL insufficient replicas md1p1 UNAVAIL invalid label
July 10, 20241 yr Community Expert Even for the disks without the invalid partition error, the pools are corrupt, I'm afraid that they will be all gone, I would really recommend replacing that controller with a true HBA.
July 10, 20241 yr Author root@MEDIASYNC:~# zpool import pool: cache id: 1735300694171723445 state: ONLINE action: The pool can be imported using its name or numeric identifier. config: cache ONLINE sdh1 ONLINE pool: disk5 id: 4102616346420463541 state: UNAVAIL status: One or more devices contains corrupted data. action: The pool cannot be imported due to damaged devices or data. see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E config: disk5 UNAVAIL insufficient replicas md5p1 UNAVAIL invalid label pool: disk5 id: 14652328161973356707 state: ONLINE action: The pool can be imported using its name or numeric identifier. config: disk5 ONLINE md4p1 ONLINE pool: disk1 id: 3172973332698465298 state: UNAVAIL status: One or more devices contains corrupted data. action: The pool cannot be imported due to damaged devices or data. see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E config: disk1 UNAVAIL insufficient replicas md1p1 UNAVAIL invalid label Yeah, ultimately I think it's time to completely retire the server. I got three years of life out it for about $250 total. It wasn't the fastest of it's generationbut it had a lot of heavy lifting capability. Gen 9 is really the plae to start with retired HP Enterprise gear. IPMI without using Java, EFII, lower overall TDP. I can view som e of the drives in MC and will try to save what I can. One last question please, Formatting is never an advised recovery option, which wa stated by a wise man in an earlier thread I saw. In this case with few easy options available, do you have an idea if it might work to restore the partition table while leaving the data intact since it's ZFS to ZFS formatting? Just an "off hte record" guestimate? Thank you for your help with me today. I appreciate your time and effort. -Cheers!
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.