Thank you for your donation!


moOde 4.2 RPiZeroW build experience
#1
I attempted to build moode 4.2 using mosbuild on a pi zero w.
I flashed the correct raspbian lite version onto sd, and added the ssh and wpa_supplicant.conf files.
I booted the pi zero and then ran mosbuild.
The build went fine until I got this error.


Code:
** Build Auto-shuffle
Cloning into 'ashuffle'...
fatal: unable to access 'https://github.com/Joshkunz/ashuffle.git/': gnutls_handshake() failed: Error in the push function.
** Error: Git clone failed
** Error: image build exited
** Error: reboot to resume the build


Upon reboot (and several subsequent reboots) I kept getting the same error and so the build script proceeeded no further.
Not sure why this has happened or how to solve it but thought it might be useful infomation for somebody on the team.

I sucessfully cloned the ashuffle git manually so decided to proceed with the rest of the build manually as per the recipe.
Upon finishing the recipe I began to play with the new build.
I found it was slugglish to non-responsive, changes to the config were not being saved and so the build was pretty unusable.
Perhaps that is due to the build being mostly done using mosbuild.sh and finished with pasting from the build recipe?

No worries, I repeated the process but this time built moode 4.2 on a Pi3. I then slotted my sd card into the pi zero w and have a working moode player v4.2.
I used the pi zero w as I wanted to investigate the new improved bluetooth functionality. I easily paired moode with my portable bluetooth speaker and set it to output audio through bluetooth.
It works nicely and now I can now listen to music in the kitchen through my portable speaker.
The zero makes a dinky little bluetooth audio player! It may be surplus to requirements when I make the switch to 4.2 on my main player but for now I am very much digging my tiny wireless audio setup!

More great work. Thanks to Tim and all contributors.
Reply
#2
Pi zero w in a tic tac case; I use the USB audio card analog out, but bluetooth output works too: https://other2funstuff.blogspot.com/2017...-cars.html
Reply
#3
I had exactly the same problem.
I started a build process after the SD card was prepared with ssh and wpa_supplicant.conf.
Compared to the build instructions for absolute beginner I select the following:

Quote:Write OS build directly to the boot SDCard? -> y (german usb keyboard: z)
Do you have a backup of your boot SDCard? -> y (german usb keyboard: z)
Enter Current Date (YYYY-MM-DD) -> enter date (german usb keyboard ß for -)
Make corrections -> n
Use a proxy server for Internet access -> n
Use a WIFI instead of Ethernet? -> y
(I accepted the wpa_supplicant.conf wifi configuration)

Proceed with build -> y (german usb keyboard: z)
Power off the Pi -> y (german usb keyboard: z)
Wait for about 10 seconds until the green LED on Pi stops blinking. Then unplug the power cable AND keyboard (its not needed anymore).
Option 2-2: use a WiFi connection instead of Ethernet (y/n)? y

I had the same problem as "Fizzy_Tea"

Quote:////////////////////////////////////////////////////////////////
//
// COMPONENT 2 - Auto-shuffle
//
////////////////////////////////////////////////////////////////

** Build Auto-shuffle
Cloning into 'ashuffle'...
fatal: unable to access 'https://github.com/Joshkunz/ashuffle.git/': gnutls_handshake() failed: Error in the push function.
** Error: Git clone failed
** Error: image build exited
** Error: reboot to resume the build

After that I removed the power from Rpi0W and moved SD card to an Rpi3 board.
I supplied the Rpi3 and continue the build process on this board.
After an additional half an hour I got the following:

Quote:Updating DB (#1) ...
volume:  0%   repeat: off   random: off   single: off   consume: off
** Tue 7 Aug 13:11:04 EDT 2018
** Installation time : 19:52:44

////////////////////////////////////////////////////////////////
// END
////////////////////////////////////////////////////////////////

** Final reboot

This hybrid build seems to work fine but I wonder if anybody found a way to finalise the build operation without the need for an additional Rpi3 board.

Regards.
Reply
#4
@rlugli

@FizzyTea

Code:
fatal: unable to access 'https://github.com/Joshkunz/ashuffle.git/': gnutls_handshake() failed: Error in the push function.

This error suggests to me a problem with security certificates in the TLS authentication process (called for by the "s" in "https:"). If you search the Web on it, you'll find that it turns up regularly in many different contexts. It's not specifically a moOde-build "thing".

I cannot repro your problem here (in Maryland USA) with a fresh install of 2018-06-27-raspbian-stretch-lite on a RPi0W with a WiFi connection.  Cloning the ashuffle repo worked fine.

Code:
pi@raspberrypi:~ $ sudo git clone https://github.com/Joshkunz/ashuffle.git/
Cloning into 'ashuffle'...
remote: Counting objects: 259, done.
remote: Total 259 (delta 0), reused 0 (delta 0), pack-reused 259
Receiving objects: 100% (259/259), 50.10 KiB | 0 bytes/s, done.
Resolving deltas: 100% (163/163), done.

This was even before I performed the two-step apt update and upgrade procedure which upgraded 22 packages including, I note, "ca-certificates".

Cloning the ashuffle repo afresh after the upgrade worked fine too.

I confess I don't have an explanation for why you were able to complete the process on an RPi3. The only thing which comes to mind is that the RPi0W has an ARMv6 CPU and the RPi3B has an ARMv7 cpu. Possibly they exercise some different code paths in the libraries. I'm grasping at straws here. Maybe it was just the timing.

I'm curious where you are located in the world. The Internet is a complex enterprise. It's also possible we are being served files through different portals which can lead to differences at least in the short term.

Regards,
Kent
Reply
#5
(08-07-2018, 10:04 PM)TheOldPresbyope Wrote: I'm curious where you are located in the world. The Internet is a complex enterprise. It's also possible we are being served files through different portals which can lead to differences at least in the short term.
I am located in Italy.
Honestly I was also very surprised about using the Rpi3.
I think Rpi0W has an ARM1176JZF-S core while the Rpi3 a Cortex-A53 one.
I only tested it because of the post of FizzyTea but I was pleased to see the result.
Regards.

Roberto
Reply
#6
Some additional information...
After my successful build using Rpi3 the Rpi0w worked fine only for a short time and the day after I had a problem the day after.
I switched off the device and when I power it on again the wifi was disappeared.
I tried several recoveries including installing a fresh copy of  Raspbian OS as well as a new moOde build process but I was not able to recover the wifi any more.
Honestly I do not think the wifi is damaged in the Rpi0w board. It seems like something was switched off.
I wonder if there are non-volatile registers that can be configured in the SoC module of the Rpi0W and permanently disable the wifi module.
By the way, BT is still functioning as well as the rest of the Rpi0w.

After connecting an ethernet to usb adapter I started a new build process from scratch.
I used the Raspbian Stretch Lite 2018-06-27 and before starting the build script I run "sudo apt-get update" and "sudo apt-get upgrade".
I cannot say what changed from my first try but this time the build process run flawless and I did not need to use the Rpi3 to finalize it.
The Rpi0w still does not have wifi working but at least I still have the nice moOde's BT sourcing feature and my wife can stream music on a BT speaker in the kitchen.


Regards

Roberto


Attached Files Thumbnail(s)
   
Reply
#7
Hi,

Very odd.

Post the output from the cmds below.

ifconfig
cat /boot/config.txt

-Tim
Reply
#8
(08-16-2018, 08:39 PM)Tim Curtis Wrote: Hi,

Very odd.

Post the output from the cmds below.

ifconfig
cat /boot/config.txt

-Tim



Code:
pi@Rpi0w-moode:~ $ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.15  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::51cd:5f87:33a8:9857  prefixlen 64  scopeid 0x20<link>
        ether 00:e0:4d:37:f4:83  txqueuelen 1000  (Ethernet)
        RX packets 299467  bytes 426336620 (406.5 MiB)
        RX errors 0  dropped 3  overruns 0  frame 0
        TX packets 118769  bytes 18044052 (17.2 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 1911  bytes 174164 (170.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1911  bytes 174164 (170.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

pi@Rpi0w-moode:~ $ cat /boot/config.txt
disable_splash=1
hdmi_drive=2
dtparam=i2c_arm=on
dtparam=i2s=on
dtparam=audio=on
#dtoverlay=pi3-disable-wifi
#dtoverlay=pi3-disable-bt
pi@Rpi0w-moode:~ $



Code:
      M O O D E    L O G  

   20180817 141848 worker: - Start
   20180817 141848 worker: Successfully daemonized
   20180817 141849 worker: Session loaded
   20180817 141849 worker: Debug logging (off)
   20180817 141849 worker: - Platform
   20180817 141852 worker: Host (Rpi0w-moode)
   20180817 141852 worker: Hdwr (Pi-Zero W 512MB v1.1)
   20180817 141852 worker: Arch (armv6l)
   20180817 141852 worker: Rasp (9.4)
   20180817 141852 worker: Kver (4.14.54+)
   20180817 141852 worker: Ktyp (Standard)
   20180817 141852 worker: Gov  (performance)
   20180817 141853 worker: Rel  (Moode 4.2 2018-07-11)
   20180817 141853 worker: Upd  (2018-07-18)
   20180817 141853 worker: MPD  (0.20.20)
   20180817 141853 worker: USB boot not enabled yet
   20180817 141853 worker: File system not expanded yet
   20180817 141853 worker: HDMI port off
   20180817 141854 worker: File check ok
   20180817 141854 worker: - Network
   20180817 141854 worker: eth0 exists
   20180817 141854 worker: eth0 (192.168.1.15)
   20180817 141854 worker: wlan0 does not exist
   20180817 141854 worker: - Audio
   20180817 141854 worker: ALSA outputs unmuted
   20180817 141854 worker: ALSA card number (0)
   20180817 141854 worker: Audio output (On-board audio device)
   20180817 141855 worker: ALSA mixer name (PCM)
   20180817 141855 worker: MPD volume control (software)
   20180817 141855 worker: Hdwr volume controller exists
   20180817 141855 worker: - Services
   20180817 141855 worker: Reset renderer active
   20180817 141857 worker: MPD started
   20180817 141857 worker: MPD scheduler policy (time-share)
   20180817 141857 worker: Configure MPD outputs
   20180817 141859 worker: MPD output 1 ALSA default (off)
   20180817 141859 worker: MPD output 2 ALSA crossfeed (off)
   20180817 141859 worker: MPD output 3 ALSA parametric eq (off)
   20180817 141859 worker: MPD output 4 ALSA graphic eq (off)
   20180817 141859 worker: MPD output 5 ALSA bluetooth (on)
   20180817 141859 worker: MPD crossfade (off)
   20180817 141859 worker: Bluetooth controller started
   20180817 141905 worker: Bluetooth controller initialized
   20180817 141905 worker: - Music sources
   20180817 141905 worker: USB sources (none attached)
   20180817 155002 worker: NAS sources (mountall initiated)
   20180817 155002 worker: - Miscellaneous
   20180817 155004 worker: Volume level (100) restored
   20180817 155004 worker: Maintenance interval (21600)
   20180817 155004 worker: Screen saver timeout (Never)


   20180817 155004 worker: Watchdog started
   20180817 155004 worker: Ready

Regards.

Roberto
Reply
#9
The boot config looks ok but ifconfig output shows no WiFi adapter which suggests something external to moOde software for example a hardware or power supply issue.
Reply
#10
(08-17-2018, 03:42 PM)Tim Curtis Wrote: The boot config looks ok but ifconfig output shows no WiFi adapter which suggests something external to moOde software for example a hardware or power supply issue.

I definitely agree, it is something outside to moOde.
As I wrote it could be that the wifi module is damaged (not seen anymore), although I do not see any reason for that.
I supposed that somehow it would be possible to disable the module directly in the SoC. Something like accessing to non-volatile registers in a way that I cannot imagine.
As I mentioned at the beginning of the post we had a problem to finalise build process with the Rpi0w and I used a sort of mixed-build using an Rpi3 to finalise the process.
I am honestly very surprised that this way was possible because of the difference in the core between Rpi0 and Rpi3 but, as a matter of fact it worked.
I do not know if this way of proceeding had some kind of consequence and made something wrong with the wifi module.
Regards.

Roberto
Reply


Forum Jump: