Volumio Debian Buster Beta - Raspi images debugging

[mac]

I also see this error version 3.015 failed to scan the music library on the portable hard drive.

It destroyed all of my music files. frustrating!
Thanks and please check and correct!

[rawdlite]

@mac
Are you sure your files are destroyed?
Hoe did you test this?
The issue i have is that an extenal drive is not mounted.
This is why you are not seeing any files.
You could attach the drive to another computer or try mounting it manually in an ssh terminal.

[rawdlite]

The one thing i am seeing that might or might not be an issue is:

 sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=0x01 driverbyte=0x00

I will investigate further.

[rawdlite]

For comparison i inserted the USB Drive in a volumio 2.8 Device while running
journalctl -f

it shows:

   Feb 23 09:42:11 volumio-tinke kernel: usb 1-1.4: new high-speed USB device number 5 using dwc2
   Feb 23 09:42:11 volumio-tinke kernel: usb 1-1.4: New USB device found, idVendor=090c, idProduct=1000
   Feb 23 09:42:11 volumio-tinke kernel: usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3   
   Feb 23 09:42:11 volumio-tinke kernel: usb 1-1.4: Product: Flash Drive
   Feb 23 09:42:11 volumio-tinke kernel: usb 1-1.4: Manufacturer: Samsung
   Feb 23 09:42:11 volumio-tinke kernel: usb 1-1.4: SerialNumber: 0374720070005130
   Feb 23 09:42:11 volumio-tinke kernel: usb-storage 1-1.4:1.0: USB Mass Storage device detected
   Feb 23 09:42:11 volumio-tinke kernel: scsi host1: usb-storage 1-1.4:1.0
   Feb 23 09:42:15 volumio-tinke kernel: scsi 1:0:0:0: Direct-Access     Samsung  Flash Drive      1100 PQ: 0 ANSI: 6
   Feb 23 09:42:15 volumio-tinke kernel: sd 1:0:0:0: [sdb] 501253132 512-byte logical blocks: (257 GB/239 GiB)
   Feb 23 09:42:15 volumio-tinke kernel: sd 1:0:0:0: [sdb] Write Protect is off
   Feb 23 09:42:15 volumio-tinke kernel: sd 1:0:0:0: [sdb] Mode Sense: 43 00 00 00
   Feb 23 09:42:15 volumio-tinke kernel: sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
   Feb 23 09:42:15 volumio-tinke kernel:  sdb: sdb1
   Feb 23 09:42:15 volumio-tinke kernel: sd 1:0:0:0: [sdb] Attached SCSI removable disk
   Feb 23 09:42:15 volumio-tinke udisks-glue[681]: Device file /dev/sdb inserted
   Feb 23 09:42:15 volumio-tinke udisks-glue[681]: Device file /dev/sdb1 inserted
   Feb 23 09:42:15 volumio-tinke udisks-glue[681]: Trying to automount /dev/sdb1...
   Feb 23 09:42:16 volumio-tinke udisks-glue[681]: Successfully automounted /dev/sdb1 at /media/Samsung USB
   Feb 23 09:42:16 volumio-tinke udisks-glue[681]: Device file /dev/sdb1 mounted at /media/Samsung USB

Note no Synchronize Cache Error there.
So if the mount is working on 014 it could be connected to the kernel version.

[mac]

I’m sure of this because: I tried lots of different hard drives like: 32 G, 1T, 2 T and 4T.

after plugging into Pi 4 4g with VOlumio 30.015:
1- press scan and it doesn’t scan music files.
2- I took out the hard drive, put the USB into the computer, and it couldn’t recognize the USB, it forced to reformat the hard drive.

I fixed it with Windows 10, but it didn’t work. I have to reformat the USB.
Note: Volumio 3.014 does not happen this problem!
thanks

[rawdlite]

When you plug in the drive into your Pi4 did you determ it was mounted?
You can test this with an ssh session or look at your log created in /dev
in # mount --------------- section you should see a mount to /media.
When the drive is not mounted the Volumio wont do anything to your drive as it can not access it.
What filesystem was the disk?
Windows can only read NTFS, FAT32 und FAT16 AFAIK.

[mac]

you do not believe me,
Please experiment with your USB!

thạnk you very much!

[Saiyato]

It seems to me there was still a handle open when you pulled out the disk, that can definitely cause drive corruption. Just out of interest, how did you format (FAT/NTFS/other) the USB drive before plugging it in your Pi and what kind of files were on there?

I have an 8G USB drive on my desk (no need to look for another), I just imaged 3.015 on a fresh SD card for a Pi2, so I’ll test that first.

My test case will be:

• Pi2 with image 3.015
• USB drive (FAT32 formatted) with a Dire Straits album in FLAC
• No plugins

Unfortunately I only have one Pi4 and it’s running as a data node in my ELK stack, I might be able to quickly test a thing or two, given I have the right parameters

[Saiyato]

Quick test, means quick results…

The log entries I found were:

Feb 23 15:05:08 volumiotest kernel: usb 1-1.4: new high-speed USB device number 4 using dwc_otg
Feb 23 15:05:09 volumiotest kernel: usb 1-1.4: New USB device found, idVendor=0951, idProduct=1666, bcdDevice= 1.00
Feb 23 15:05:09 volumiotest kernel: usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Feb 23 15:05:09 volumiotest kernel: usb 1-1.4: Product: DataTraveler 3.0
Feb 23 15:05:09 volumiotest kernel: usb 1-1.4: Manufacturer: Kingston
Feb 23 15:05:09 volumiotest kernel: usb 1-1.4: SerialNumber: xxx
Feb 23 15:05:09 volumiotest kernel: usb-storage 1-1.4:1.0: USB Mass Storage device detected
Feb 23 15:05:09 volumiotest kernel: scsi host0: usb-storage 1-1.4:1.0
Feb 23 15:05:09 volumiotest kernel: usbcore: registered new interface driver uas

…

Feb 23 15:05:10 volumiotest kernel: scsi 0:0:0:0: Direct-Access     Kingston DataTraveler 3.0 PMAP PQ: 0 ANSI: 6
Feb 23 15:05:10 volumiotest kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
Feb 23 15:05:11 volumiotest kernel: sd 0:0:0:0: [sda] 15364416 512-byte logical blocks: (7.87 GB/7.33 GiB)
Feb 23 15:05:11 volumiotest kernel: sd 0:0:0:0: [sda] Write Protect is off
Feb 23 15:05:11 volumiotest kernel: sd 0:0:0:0: [sda] Mode Sense: 23 00 00 00
Feb 23 15:05:11 volumiotest kernel: sd 0:0:0:0: [sda] No Caching mode page found
Feb 23 15:05:11 volumiotest kernel: sd 0:0:0:0: [sda] Assuming drive cache: write through
Feb 23 15:05:11 volumiotest kernel:  sda: sda1
Feb 23 15:05:11 volumiotest kernel: sd 0:0:0:0: [sda] Attached SCSI removable disk

Nothing seemed to happen in Volumio after I rebuilt the database. I couldn’t list the dir tree on sda1

volumio@volumiotest:/media$ tree /dev/sda1
/dev/sda1 [error opening dir]

0 directories, 0 files

Nor were any directories visible for /mnt/USB

volumio@volumiotest:/media$ ll /mnt/USB/
total 2
drwxrwxrwx 2 root root    3 Dec 21 17:31 .
drwxrwxrwx 1 root root 1024 Jan  1  1970 ..

After re-inserting the drive in my Windows PC I saw the pop-up that errors were found on the disk, but I could still browse its contents:

E:\>dir
 Volume in drive E is DATA
 Volume Serial Number is xxx

 Directory of E:\

07-10-2020  08:28    <DIR>          Dire Straits - Brothers in Arms
               0 File(s)              0 bytes
               1 Dir(s)   6.837.096.448 bytes free

[Saiyato]

I see I forgot the lsblk output:

volumio@volumiotest:/media$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
loop0         7:0    0 467.3M  0 loop /static
sda           8:0    1   7.3G  0 disk
└─sda1        8:1    1   7.3G  0 part
mmcblk0     179:0    0   7.5G  0 disk
├─mmcblk0p1 179:1    0  91.6M  0 part /boot
├─mmcblk0p2 179:2    0   2.2G  0 part /imgpart
└─mmcblk0p3 179:3    0   5.1G  0 part

Update 2, when I mount the USB drive to /mnt/tmp I can actually browse its contents:

volumio@volumiotest:/mnt$ sudo mount /dev/sda1 /mnt/tmp
volumio@volumiotest:/mnt$ ls
INTERNAL  NAS  tmp  UPNP  USB
volumio@volumiotest:/mnt$ ll tmp/
total 14
drwxr-xr-x 4 root root 4096 Jan  1  1970  .
drwxrwxrwx 1 root root 1024 Feb 23 15:26  ..
drwxr-xr-x 2 root root 4096 Oct  7 08:28 'Dire Straits - Brothers in Arms'
drwxr-xr-x 2 root root 4096 Feb 23 14:26 'System Volume Information'

[rawdlite]

This is consistent with the behaviour i am seeing on my Pi4 with 3.015.
Filesystem is exfat.
I see no corruption on the drive though. But then i dont use Windows.
Out of curiosity: have you tried an fsck on the drive after windows showed errors?
That error might give us a clue where Node.js failed on mounting the device.

So far it seems:

• error is not Pi4 only (you tested on Pi2)
• error is not related to Synchronize Cache Error (did various tests on that)
• error is not related to filesystem (you tested FAT32, i tested exfat and ext4)
• error was introduced in 3.015 (was reported working in 3.014)

HTH

[ashthespy]

Thanks for all the debugging - a lot of these issues should (hopefully) be fixed on newer versions, but I’ve run out of space on my Google drive so would like to hand over the “official” beta images to Volumio’s servers. That should also let the OTA stuff start working so you don’t have to reflash each time.

That being said, could someone post the output of cat /etc/os-release so I can confirm what all bugs from that particular image are currently fixed?

[rawdlite]

@ashthespy

cat /etc/os-release

cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
VOLUMIO_BUILD_VERSION="ce42870b438221a1441bf386bee548a48fbdef10"
VOLUMIO_FE_VERSION="847a48ecf32d35cc502a0053d585d1a69236e391"
VOLUMIO_FE3_VERSION="9badc5270f4e77ce968c32b01c697b4bc18a7738"
VOLUMIO_BE_VERSION="a6ab2104d7bc11a3682b698ff871af03a5b71d0e"
VOLUMIO_ARCH="arm"
VOLUMIO_VARIANT="volumio"
VOLUMIO_TEST="FALSE"
VOLUMIO_BUILD_DATE="Mon Dec 21 17:36:25 UTC 2020"
VOLUMIO_VERSION="3.015"
VOLUMIO_HARDWARE="raspberry"
VOLUMIO_DEVICENAME="Raspberry Pi"
VOLUMIO_HASH="cfa0cf5b15460aed5be27126a539e744"

[Saiyato]

Exactly the same here

[Saiyato]

I’m not sure how I can make it more verbose (the -V parameter doesn’t give me much extra info).

volumio@volumiotest:~$ sudo fsck /dev/sda1
fsck from util-linux 2.33.1
fsck.fat 4.1 (2017-01-24)
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.

After retesting (repair in Windows and replug into Pi) I’m not getting the dirty bit anymore, just a summary wrong:

volumio@volumiotest:~$ sudo fsck -l -V /dev/sdb1
fsck from util-linux 2.33.1
[/sbin/fsck.vfat (1) -- /dev/sdb1] fsck.vfat /dev/sdb1
Locking disk by /run/fsck/sdb.lock ... succeeded.
fsck.fat 4.1 (2017-01-24)
Free cluster summary wrong (1915638 vs. really 1669213)
1) Correct
2) Don't correct
? 2
/dev/sdb1: 15 files, 246987/1916200 clusters
Unlocking /run/fsck/sdb.lock.

After that has been fixed I’m not getting errors on Windows or Linux anymore, it still doesn’t show up however. Now I know that /dev/sda1 is the partition, not the disk and since it’s a FAT32 partitioned disk I ran dosfsck and it gave comparable output:

volumio@volumiotest:~$ sudo dosfsck -v /dev/sda
fsck.fat 4.1 (2017-01-24)
Logical sector size (1766 bytes) is not a multiple of the physical sector size.

Something is off in determining the size I think, but tbh I’m no expert (I just sometime know how to Google )

Update 1

Learning on the job, this is the output of fsck.vfat (same as via dosfsck, but less implicit):

volumio@volumiotest:~$ sudo fsck.vfat -n /dev/sda
fsck.fat 4.1 (2017-01-24)
Logical sector size (1766 bytes) is not a multiple of the physical sector size.

[The_Raven]

“snd-bcm2835.enable_compat_alsa=1” in cmdline.txt and “libnss-mdns” are missing in 3.015.

[ashthespy]

Indeed, 3.015 is the same image from Jan 3rd Haven’t made a new image release since…

[ashthespy]

Please use the new images

Volumio 3 Buster Beta for RPi

Please use this topic to discuss errors, missing components or improvement suggestions during the Volumio 3 Buster beta test phase for Raspberry Pi. In this opening and first following post we will keep a list of beta versions, fixes, known problems and important updates. Please also refer to the general issues for Volumio 3 Buster issues, which are not platform-specific. This thread will be moderated actively. With issues, which do not appear to be RPi or Debian Buster related, you will be r…