allanp81 Posted June 29, 2018 Share Posted June 29, 2018 I just noticed that my syslog has been showing the following for the last week: Jun 22 04:52:28 downloadbox kernel: blk_partition_remap: fail for partition 1 Jun 22 04:52:28 downloadbox kernel: XFS (sda1): metadata I/O error: block 0x75513e80 ("xfs_trans_read_buf_map") error 5 numblks 32 Jun 22 04:52:28 downloadbox kernel: XFS (sda1): xfs_imap_to_bp: xfs_trans_read_buf() returned error -5. My server seems ok although around midnight last night I did get a few emails claiming that my cache disk was nearly full that seems to be fine once I got up this morning and apart from the email notifications I can't see any errors relating to this in the syslog. I also can't find any references to what sda1 thinks it is, as there is no sda1 listed under system devices. downloadbox-syslog-20180629-0845.zip Quote Link to comment
JorgeB Posted June 29, 2018 Share Posted June 29, 2018 Please post your diagnostics: Tools -> Diagnostics Quote Link to comment
allanp81 Posted June 29, 2018 Author Share Posted June 29, 2018 Thanks, I meant to do that but only posted the syslog downloadbox-diagnostics-20180629-0913.zip Quote Link to comment
JorgeB Posted June 29, 2018 Share Posted June 29, 2018 Unfortunate even the complete syslog on the diags rotated and oldest entry is from July 22 but already shows the same error, we need to see the beginning of the syslog and when the error started, so reboot and if/when the error comes back grab and post new diags. Quote Link to comment
allanp81 Posted June 29, 2018 Author Share Posted June 29, 2018 Ok, that's not great, I'm almost too scared to reboot in case it doesn't come back! Quote Link to comment
JorgeB Posted June 29, 2018 Share Posted June 29, 2018 5 minutes ago, allanp81 said: I'm almost too scared to reboot in case it doesn't come back! It should comeback fine and most likely without the error Quote Link to comment
allanp81 Posted June 29, 2018 Author Share Posted June 29, 2018 10 minutes ago, johnnie.black said: It should comeback fine and most likely without the error I've rebooted and so far no errors in the log at all. Will keep an eye on it and post the full diagnostics if it errors again. Thanks for your help. Quote Link to comment
bombz Posted July 23, 2018 Share Posted July 23, 2018 (edited) Same with me, this happens every so often I have formatted my USB to clean it up thinking it was the concern, but clearly, it hasn't helped anyone know what the issue may be ? Flash DataTraveler_3.0 - 15.5 GB This has seemed to happen since I switched from my original flash drive to this one as I needed more room than my original one from Unraid Jul 23 13:43:41 UnRAID kernel: blk_partition_remap: fail for partition 1Jul 23 13:43:41 UnRAID kernel: blk_partition_remap: fail for partition 1 unraid-diagnostics-20180723-1751.zip Edited July 23, 2018 by bombz Quote Link to comment
JorgeB Posted July 24, 2018 Share Posted July 24, 2018 8 hours ago, bombz said: Same with me, this happens every so often Try a different USB port, preferably USB 2.0 Quote Link to comment
bombz Posted July 24, 2018 Share Posted July 24, 2018 I have changed USB port to 3.0 as I was on the 2.0 header I also changed the boot device which I think may have been messing it up (but we will see) I was on: UEFI - Kingston Flash Changed to: Legacy - Kingston Flash Array is in parity sync now.... again. As whenever this issue happens I have to use the 'powerdown ' command from console, which then shows 'unclean shutdown' when I boot (When this error happens). I will know in a few days I am sure if I am running into concerns. Quote Link to comment
JorgeB Posted July 24, 2018 Share Posted July 24, 2018 17 minutes ago, bombz said: I have changed USB port to 3.0 as I was on the 2.0 header USB 3.0 port is not recommended, if you were already on USB 2.0 it can be a failing flash drive (USB 3.0 flash drives are also not recommended as they usually have a much higher failure rate) Quote Link to comment
bombz Posted July 24, 2018 Share Posted July 24, 2018 Ah OK. Well, I do have other flash drives here (2.0) This was what I had handy at the time as I couldn't upgrade to 6.0 at the time. I was still using my original USB for years that I bought from UnRaid (version 4.5 era). I will get a 2.0 device going tonight and request a new key. Thank you for the heads up. Quote Link to comment
bombz Posted July 24, 2018 Share Posted July 24, 2018 (edited) [SOLVED] (so far) Interesting. Parity finished. I stopped the server to give it a fresh shutdown and reboot and saw this:Jul 24 18:06:46 UnRAID emhttpd: error: send_file, 139: Broken pipe (32): sendfile: /usr/local/emhttp/logging.htm I think I am going to swap to a USB 2.0 and re-key tonight Edit: USB 2.0 Key made bootable.... waiting on reg info (fingers crossed!) Edit: Seems the new key has been holding strong. Edited July 29, 2018 by bombz Quote Link to comment
CaryV Posted November 24, 2019 Share Posted November 24, 2019 Was a resolve for this ever found? (as posted by allanp81) Nov 24 00:11:28 Headless kernel: XFS (sdh1): metadata I/O error: block 0xeadea1f0 ("xfs_trans_read_buf_map") error 5 numblks 32 Nov 24 00:11:28 Headless kernel: XFS (sdh1): xfs_imap_to_bp: xfs_trans_read_buf() returned error -5. I have the same issue, but it's not just a matter of 'filling' the log file - this occurs with a USB hard drive and when it does, the drive goes 'offline' (unmounted) when it was mounted, shared and usable in unAssigned Devices. AND, it gets better... Not only will it not remount (as is), but if it is disconnected and reattached in hopes of getting it operational - Can't remount the drive because of the following error: Nov 24 00:31:02 Headless kernel: XFS (sdi1): Filesystem has duplicate UUID b53fdadc-8cec-4f92-b699-a4cbc510f52d - can't mount The system seems REALLY "confused" at this point - of course its the same UUID (NOT a duplicate) - IT'S THE SAME DEVICE that was mounted and working and now won't remount (because it is detected as a duplicate?). Can only get it operational again by a reboot of the system, JUST TO HAVE IT HAPPEN AGAIN! (Even tried to change the UUID at this point, but the OS wouldn't have it - says drive's log has to be cleared by mounting the drive, or risk potential 'corruption.) If I can determine what is causing the initial problem that is getting logged, can probably avoid the complications (like the following) Drive goes so far 'out the window' that in addition to the duplicate UUID, also get this: Nov 24 00:31:02 Headless unassigned.devices: Mount of '/dev/sdi1' failed. Error message: mount: /mnt/disks/WCC132184639: wrong fs type, bad option, bad superblock on /dev/sdi1, missing codepage or helper program, or other error. Which CAN'T be correct, otherwise the drive wouldn't have mounted and been usable in the first place. And, if the system is rebooted, the drive CAN be mounted and is once again usable (for however long that lasts, usually not too). Have included diagnostics that shows all of this happening, but have no idea why. Any help would be appreciated. NOTE: It is interesting that the device starts out as "sdh" (the next available designation), but after that it gets a designation of "sdi" EVEN THOUGH THERE IS NO "sdh" and that designation is available; may be the reason the system is 'confused' and issues the duplicate UUID error. headless-diagnostics-20191124-0030.zip Quote Link to comment
JorgeB Posted November 24, 2019 Share Posted November 24, 2019 this occurs with a USB hard drive and when it does, the drive goes 'offline' (unmounted) when it was mounted, shared and usable in unAssigned Devices. Possibly related to the USB bridge, USB is prone to disconnects and very bad a error handling, try connecting directly to a SATA port if possible, you can also run a filesystem check. The duplicate UUID is also related, it's because the filesystem it's not correctly unmounting. Quote Link to comment
Recommended Posts
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.