SOLVED: Big mess after ReiserFS to XFS conversion


Recommended Posts

I decided to take the long path to convert all my drives from ReiserFS to XFS after reading multiple posts here and since I upgraded to 6.6.6 (but personally never experiencing any problem with the old file system)

 

Everything ran fine or so I thought until the last weekend - I converted the drives one after another, then ran the system for a few days... We had strong winds here and I decided the shut the server overnight in a case we may have a power outage. I have a UPS but the dog really hates the alarm of it running on battery power!!!

 

Upon powering up I was presented with the messages that 3 of my disks are "Unmountable: no file system" and the following message in the syslog

 

Mar 11 08:22:26 unraid emhttpd: shcmd (209): mkdir -p /mnt/disk9

Mar 11 08:22:26 unraid emhttpd: shcmd (210): mount -t xfs -o noatime,nodiratime /dev/md9 /mnt/disk9
Mar 11 08:22:26 unraid kernel: XFS (md9): Invalid superblock magic number
Mar 11 08:22:26 unraid root: mount: /mnt/disk9: wrong fs type, bad option, bad superblock on /dev/md9, missing codepage or helper program, or other error.

 

Upon close inspection of the disks in question to see if they share a common breakout cable/power cable or for anything in common I see that all three were the very old WD green EARS models with jumper on pin1-2 (or7-8), but still running fine. I have another of these disks which was installed with no jumper a long time ago and this disk is running fine without problems after the conversion...

 

I do remember here that during the conversion I did not like the option of having disks with "MBR:unaligned" options and I ended up overwriting the first sector of the drive with zeroes using the preclear tool, but I assumed that the formatting afterwards will recreate the MBR in its proper place in the first sector (the disks are less than 2.2GB to use the GPT)

 

I stopped the array and then restarted in "maintenance mode" and tried to scan (-n) or repair (-v) the disk from the console but without success - after running for a few hours (and apr. 3,800,000 "reads") it exits with a message no secondary magic block found.

 

After another shut-down I removed the jumpers and tried another "xfs_repair" while running in maintenance mode - this time it can find the magic block and repairs the disk very fast (under 15 seconds total running time). However when I start the array I am still presented with with "Unmountable disks" but this time the message is different:

"Unmountable: unsupported partition layout" with the following in the syslog:

 

Mar 11 08:22:26 unraid emhttpd: shcmd (206): mkdir -p /mnt/disk8
Mar 11 08:22:26 unraid emhttpd: /mnt/disk8 mount error: Unsupported partition layout
Mar 11 08:22:26 unraid emhttpd: shcmd (207): umount /mnt/disk8
Mar 11 08:22:26 unraid root: umount: /mnt/disk8: not mounted.

 

I powered down the server and removed one of the problems drive and the good drive to inspect their content - specifically the first 64 sectors.

For my surprise it turned out that the MBR is in the second sector and not in the first one where it is supposed to be, The XFS partition in both cases starts at offset 64 sectors (hex address 8000)

 

So I guess I will need some Linux gurus to help me with a command to copy the drive second sector (512 bytes) over the first sector and then zero the second sector, so I do not end with garbage polluting the first 64 sectors. This will be done in array running in maintenance mode to preserve the parity - surprisingly it still shows as a valid.

 

Thank you

 

After more reading on the MBR structure I realized I will need to copy the first sector from a good 2TB hard drive over the first sector on the three problematic hard drives. The zeroing of their second sector will be only the gravy.

Attached is a picture of the good HD first sector and one of the bad ones second sectors - partition size is hex E8E08870 , corresponding to decimal 3,907,029,104 sectors of 512bytes each and starts at hex sector 00000040

 

 

NoJum_1st.jpg

Jumperless_2nd.jpg

Edited by bcbgboy13
Link to comment
11 hours ago, bcbgboy13 said:

but this time the message is different:

"Unmountable: unsupported partition layout" with the following in the syslog:

If the filesystem is now good you can fix this by having Unraid recreate the partition, unassign one of these disks, start the array, emulated disk should now mount, if yes rebuild it, then repeat the procedure for the other disks.

Link to comment

Hmm, I was thinking more of using these:

 

1. Zeroing the first two sectors of the 3 unmountable drives:

 

dd if=/dev/zero of=/dev/sdX bs=1024 count=1

 

2. Copying the first sector (MBR - the partition info) from the good 2 TB hard drive into the first sector of the other 3 drives:

 

dd if=/dev/sdX of=/dev/sdY bs=512 count=1 , where the sdX is the source with good MBR

 

3. Reboot

 

This should set me with 4 hard drives having the same volume ID (in the Microsoft sense - 4 bytes starting at location 0x1B8), but I am not sure if Linux (Unraid) uses it. If not advisable, then I will have to manually remove the drive, attach it to my Windows computer and manually change one bit of this volume IDs - which will result in three parity errors, but I can live with that - unless there is some HEX utility editor that I can use with Unraid to manually modify a bit

 

I just need need some Linux guru to confirm that the the commands above are good

 

Link to comment

Success!!!!

 

After executing the command above with the proper disks "names":

 

login as: root
root@unraid's password:
Linux 4.18.20-unRAID.
root@unraid:~# dd if=/dev/zero of=/dev/sdi bs=1024 count=1
1+0 records in
1+0 records out
1024 bytes (1.0 kB, 1.0 KiB) copied, 0.000354388 s, 2.9 MB/s
root@unraid:~# dd if=/dev/zero of=/dev/sdf bs=1024 count=1
1+0 records in
1+0 records out
1024 bytes (1.0 kB, 1.0 KiB) copied, 0.000304993 s, 3.4 MB/s
root@unraid:~# dd if=/dev/zero of=/dev/sdc bs=1024 count=1
1+0 records in
1+0 records out
1024 bytes (1.0 kB, 1.0 KiB) copied, 0.000367164 s, 2.8 MB/s
root@unraid:~# dd if=/dev/sdh of=/dev/sdi bs=512 count=1
1+0 records in
1+0 records out
512 bytes copied, 0.000388192 s, 1.3 MB/s
root@unraid:~# dd if=/dev/sdh of=/dev/sdf bs=512 count=1
1+0 records in
1+0 records out
512 bytes copied, 0.000109879 s, 4.7 MB/s
root@unraid:~# dd if=/dev/sdh of=/dev/sdc bs=512 count=1
1+0 records in
1+0 records out

512 bytes copied, 0.000107168 s, 4.8 MB/s
root@unraid:~#

 

this one was added at the very end of the syslog:

 

Mar 12 10:06:13 unraid kernel: sdi: sdi1
Mar 12 10:07:50 unraid kernel: sdf: sdf1
Mar 12 10:08:43 unraid kernel: sdc: sdc1

 

After rebooting the server everything seems to be OK. The three disks are mounted with "MBR: 4K-aligned" and parity is valid!!!!!

 

I will do a parity check just to be sure and will mark this "solved" in a day or two - waiting for someone to tell me that it is not a good idea to have four disks with identical volume identifiers...

Link to comment
  • bcbgboy13 changed the title to SOLVED: Big mess after ReiserFS to XFS conversion

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.