Upgraded from Pi Zero 2W to Pi 4, but scanning of library stops after a certain amount

Help and Support
1

Hi All. I recently upgraded from Pi Zero 2W to Pi 4, but scanning of library stops after a certain amount, and then goes back to zero–well, one artist, the first one. Which is odd, because the drive scanned perfectly fine on the Pi Zero 2W. I’ve read through the previous reports of similar issues, and I’m lead to believe it may be a corrupted file, but I’m not sure. Any help would be appreciated. Thank you! Oh, I am using a HifiBerry Dac+ Zero, where I wasn’t on the Pi Zero 2W. And I’m on the latest version of Volumio, 3.757.

Log report: http://logs.volumio.org/volumio/mRosvoJ.html

2

I expect your boot partition of the SD is broken, or the NAS has issues, looking at the log. please take a new SD and re-flash Volumio.

Nov 12 12:11:44 volumio kernel: FAT-fs (sda1): Directory bread(block 229056) failed
Nov 12 12:11:44 volumio kernel: FAT-fs (sda1): Directory bread(block 229057) failed
Nov 12 12:11:44 volumio kernel: FAT-fs (sda1): Directory bread(block 229058) failed
Nov 12 12:11:44 volumio kernel: FAT-fs (sda1): Directory bread(block 229059) failed
Nov 12 12:11:44 volumio kernel: FAT-fs (sda1): Directory bread(block 229060) failed
Nov 12 12:11:44 volumio kernel: FAT-fs (sda1): Directory bread(block 229061) failed
Nov 12 12:11:44 volumio kernel: FAT-fs (sda1): Directory bread(block 229062) failed
Nov 12 12:11:44 volumio kernel: FAT-fs (sda1): Directory bread(block 229063) failed
Nov 12 12:11:44 volumio kernel: FAT-fs (sda1): Directory bread(block 229064) failed
Nov 12 12:11:44 volumio kernel: FAT-fs (sda1): Directory bread(block 229065) failed
3

Thanks a lot for scanning my log, @Wheaten . I put a fresh install of Volumio on a brand new micro SD card, and this time it got about 90% through, instead of 40-50% like last time. So, an improvement in a way, but it still went back to zero after 90% this time. What’s interesting to me is that I never had this issue with the Pi Zero 2W. Only difference here is it’s a Pi 4, and has a HiFi Berry Dac+ on it. Anyway, here’s the log after the most recent attempt.
https://logs.volumio.org/volumio/vKaK6L5.html
thanks again!

4

The log is full of errors on sda1. Seems your USB disk is corrupted. (Possibly caused by disconnecting the drive while the system is powered)
This error is not related to your rPi.
Please try if you can repair your USB disk or considering replacing it.
(I expect you modified your opening post as it mentioned you used a NAS before???)

Nov 13 19:11:56 volumio kernel: sd 0:0:0:0: Device offlined - not ready after error recovery
Nov 13 19:11:56 volumio kernel: sd 0:0:0:0: Device offlined - not ready after error recovery
Nov 13 19:11:56 volumio kernel: device offline error, dev sda, sector 59374208 op 0x0:(READ) flags 0x80700 phys_seg 8 prio class 3
Nov 13 19:11:56 volumio kernel: device offline error, dev sda, sector 59365440 op 0x0:(READ) flags 0x80700 phys_seg 32 prio class 3
Nov 13 19:11:56 volumio kernel: device offline error, dev sda, sector 59374208 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 3
Nov 13 19:11:56 volumio kernel: device offline error, dev sda, sector 59374208 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 3
Nov 13 19:11:56 volumio kernel: device offline error, dev sda, sector 59374208 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 3
Nov 13 19:11:56 volumio kernel: device offline error, dev sda, sector 59374208 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 3
Nov 13 19:11:56 volumio kernel: device offline error, dev sda, sector 59374208 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 3
Nov 13 19:11:56 volumio kernel: device offline error, dev sda, sector 59374208 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 3
Nov 13 19:11:56 volumio kernel: device offline error, dev sda, sector 9332 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 3
Nov 13 19:11:56 volumio kernel: FAT-fs (sda1): FAT read failed (blocknr 7284)
Nov 13 19:11:56 volumio kernel: device offline error, dev sda, sector 9348 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 3
Nov 13 19:11:56 volumio kernel: FAT-fs (sda1): FAT read failed (blocknr 7300)
Nov 13 19:11:56 volumio kernel: FAT-fs (sda1): FAT read failed (blocknr 7376)
Nov 13 19:11:56 volumio kernel: FAT-fs (sda1): FAT read failed (blocknr 7403)
Nov 13 19:11:56 volumio kernel: FAT-fs (sda1): FAT read failed (blocknr 7435)
Nov 13 19:11:56 volumio kernel: FAT-fs (sda1): FAT read failed (blocknr 7798)
Nov 13 19:11:56 volumio kernel: FAT-fs (sda1): FAT read failed (blocknr 7815)
Nov 13 19:11:56 volumio kernel: FAT-fs (sda1): FAT read failed (blocknr 7847)
Nov 13 19:11:56 volumio kernel: FAT-fs (sda1): FAT read failed (blocknr 7869)
Nov 13 19:11:56 volumio kernel: FAT-fs (sda1): FAT read failed (blocknr 7893)
5

Will do. Thanks again for your help. And yes, I did edit my original post. I’m still sort of an amateur with the nomenclature and realized I might have used the wrong technical term. Last night I checked the drive on a variety of programs, and didn’t find any errors. I do have a spare drive, but before I format that, I think I may reformat the drive with errors, repopulate the music, and see if I can salvage the drive that way. And you’re right, I may have removed the drive with the Pi on. Live and learn, thanks @Wheaten

6

@Wheaten so I unboxed my new ssd drive, copied over the music from the original source (not the misbehaving drive in question) and the same sort of problem is occurring. It’ll scan the drive successfully up to a certain point, and then revert back to 1. I’m still so confused as to why this never happened when I was using Volumio with a Pi Zero 2W. Anyway, if you have any other suggestions for me to investigate, I’m all ears. Thanks.

7

is the log showing the same errors?

8

New to analyzing these, so not too sure. https://logs.volumio.org/volumio/82TXv0P.html

I’m not seeing the device offline errors, but am seeing a handful of FAT read failed errors-- although not in the same sequence as in the first log I shared.

9 
Nov 24 09:53:28 music volumio[1027]: info: Partition removed: {"syspath":"/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb2/2-2/2-2:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda1","ACTION":"remove","DEVLINKS":"/dev/disk/by-partuuid/a59d1fae-01 /dev/disk/by-label/MUSIC /dev/disk/by-id/usb-KINGSTON_SA400S37480G_235678C218CA-0:0-part1 /dev/disk/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:2:1.0-scsi-0:0:0:0-part1 /dev/disk/by-uuid/D7E1-F630","DEVNAME":"/dev/sda1","DEVPATH":"/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb2/2-2/2-2:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda1","DEVTYPE":"partition","DISKSEQ":"26","ID_BUS":"usb","ID_FS_LABEL":"MUSIC","ID_FS_LABEL_ENC":"MUSIC","ID_FS_TYPE":"vfat","ID_FS_USAGE":"filesystem","ID_FS_UUID":"D7E1-F630","ID_FS_UUID_ENC":"D7E1-F630","ID_FS_VERSION":"FAT32","ID_INSTANCE":"0:0","ID_MODEL":"SA400S37480G","ID_MODEL_ENC":"\\x20SA400S37480G\\x20\\x20\\x20","ID_MODEL_ID":"a2a4","ID_PART_ENTRY_DISK":"8:0","ID_PART_ENTRY_NUMBER":"1","ID_PART_ENTRY_OFFSET":"2048","ID_PART_ENTRY_SCHEME":"dos","ID_PART_ENTRY_SIZE":"937699328","ID_PART_ENTRY_TYPE":"0xb","ID_PART_ENTRY_UUID":"a59d1fae-01","ID_PART_TABLE_TYPE":"dos","ID_PART_TABLE_UUID":"a59d1fae","ID_PATH":"platform-fd500000.pcie-pci-0000:01:00.0-usb-0:2:1.0-scsi-0:0:0:0","ID_PATH_TAG":"platform-fd500000_pcie-pci-0000_01_00_0-usb-0_2_1_0-scsi-0_0_0_0","ID_REVISION":"4101","ID_SERIAL":"KINGSTON_SA400S37480G_235678C218CA-0:0","ID_SERIAL_SHORT":"235678C218CA","ID_TYPE":"disk","ID_USB_DRIVER":"uas","ID_USB_INTERFACES":":080650:080662:","ID_USB_INTERFACE_NUM":"00","ID_VENDOR":"KINGSTON","ID_VENDOR_ENC":"KINGSTON","ID_VENDOR_ID":"7825","MAJOR":"8","MINOR":"1","PARTN":"1","SEQNUM":"2443","SUBSYSTEM":"block","TAGS":":systemd:","USEC_INITIALIZED":"3950369"}
Nov 24 09:53:28 music kernel: sd 0:0:0:0: Device offlined - not ready after error recovery
Nov 24 09:53:28 music kernel: sd 0:0:0:0: Device offlined - not ready after error recovery
Nov 24 09:53:28 music kernel: sd 0:0:0:0: Device offlined - not ready after error recovery
Nov 24 09:53:28 music kernel: sd 0:0:0:0: Device offlined - not ready after error recovery
Nov 24 09:53:28 music kernel: sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=35s
Nov 24 09:53:28 music kernel: sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 02 31 38 40 00 00 02 00
Nov 24 09:53:28 music kernel: sd 0:0:0:0: [sda] tag#1 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=35s
Nov 24 09:53:28 music kernel: sd 0:0:0:0: [sda] tag#1 CDB: opcode=0x28 28 00 02 31 38 42 00 03 fe 00
Nov 24 09:53:28 music kernel: sd 0:0:0:0: [sda] tag#2 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=35s
Nov 24 09:53:28 music kernel: sd 0:0:0:0: [sda] tag#2 CDB: opcode=0x28 28 00 02 31 3c 40 00 00 02 00
Nov 24 09:53:28 music kernel: sd 0:0:0:0: [sda] tag#3 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=35s
Nov 24 09:53:28 music kernel: sd 0:0:0:0: [sda] tag#3 CDB: opcode=0x28 28 00 02 31 34 42 00 03 fe 00
Nov 24 09:53:28 music kernel: FAT-fs (sda1): FAT read failed (blocknr 2269)
Nov 24 09:53:28 music kernel: FAT-fs (sda1): FAT read failed (blocknr 2269)
Nov 24 09:53:28 music kernel: FAT-fs (sda1): FAT read failed (blocknr 2269)
Nov 24 09:53:28 music kernel: FAT-fs (sda1): FAT read failed (blocknr 2269)
Nov 24 09:53:28 music sudo[4062]:  volumio : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/bin/umount -f /dev/sda1
Nov 24 09:53:28 music sudo[4062]: pam_unix(sudo:session): session opened for user root by (uid=0)
Nov 24 09:53:28 music sudo[4062]: pam_unix(sudo:session): session closed for user root
Nov 24 09:53:28 music volumio[1027]: umount: /media/MUSIC: target is busy.
Nov 24 09:53:28 music volumio[1027]: error: Failed to umount MUSIC: Error: Command failed: /usr/bin/sudo /bin/umount -f "/dev/sda1"
Nov 24 09:53:28 music volumio[1027]: umount: /media/MUSIC: target is busy.
Nov 24 09:53:28 music kernel: sd 0:0:0:0: [sda] Synchronizing SCSI cache
Nov 24 09:53:28 music kernel: FAT-fs (sda1): Directory bread(block 36640066) failed
Nov 24 09:53:28 music kernel: FAT-fs (sda1): Directory bread(block 36640067) failed
Nov 24 09:53:28 music kernel: FAT-fs (sda1): Directory bread(block 36640068) failed
Nov 24 09:53:28 music kernel: FAT-fs (sda1): Directory bread(block 36640069) failed
Nov 24 09:53:28 music kernel: FAT-fs (sda1): Directory bread(block 36640070) failed

Seems the drive was unplugged from the system and causing errors.

@DED , @nerd
Any suggestions on this?

10

That’s SO odd, because I was very careful not to replicate that potential issue this time around. I did unplug the drive once, but it was after the Pi was shut down, well after many scans had failed. Thank you all for your time.

11

Hey @yelof3,

How is your Sabrent UAS USB powered? The RPi 4B USB2 ports from SBC may not provide enough power to the attached storage device. There are “literally” hundreds discussions regarding this across the net.

Nov 13 19:04:40 volumio kernel: scsi host0: uas_eh_device_reset_handler success
Nov 13 19:04:40 volumio kernel: FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

Suggests disruption whilst in use. Either connection during write (sync) or power loss. There is no other “third” option or scenario. Volumio OS can not clear FAT errors, This needs to be handled and resolved externally.

Kind Regards,

12

Thanks @nerd. Both drives are identical, Kingston A400 480gb 2.5" SSD. The original drive is connected with a Sabrent SATA to USB connector, and the recently opened reserve drive has this as a connector.
With both scenarios, I have the drive connected to the Pi 4B via the USB3 ports. I tried both the top and bottom ports, just in case. The Pi is powered via a Raspberry Pi 5v 5a power supply. Please let me know if there’s a better way for me to be connecting the drive, or if you have any other suggestions. I’m just not sure where to go from here, as far as eliminating disruption/connection issues. Thanks again.

13

Hey @yelof3,

FAT partition as such is very fragile to any interruptions. Volumio OS uses sync prior eject, still is not immune to rapid shutdown.

The Kingston A400 line-up uses 1.535W (MAX) on write, there is enough room for the downstream circuity. Of course, it depends what else is connected to the USB ports on Pi itself. As usual, this is a subject to a basic maths for the linear load, not power spikes.

There are newer versions of your SATA to USB connector, refined for light power use:

NOTICE: I am not endorsing any manufacturer, your adaptor yields UASP from the same brand.

When dealing with various USB attached storages, self powered USB hubs are clear winners here.

Kind Regards,

14

Thanks @nerd . Nothing else has been connected to the USB ports while I’m trying to scan. I suppose I’ll try buying another adapter along the lines of your suggestion, and will likely buy a self-powered USB hub like this

I still find it odd that I never ran into this issue when I was using the Pi Zero 2W. Anyway, thank you for taking the time to review things and offer suggestions. Happy Thanksgiving.

15

@nerd I wanted to circle back and say that after several more attempts before I bought anything else, I was finally able to get the full library read. I used my original drive with the adapter I had connected to the 2nd drive, the one in the ebay listing I liked previously.

1 Like