RPi Z W Reboot before terminal available

[tony1tf]

I though I'd start a new thread on this problem.

Using this image https://bit.ly/haxo-rpiz that is linked to in hortense667 issues.
I have also managed to get some screen pictures before the Pi reboots. This is with the haxophone attached with HDMI and keyboard connected. No mods to any start-up files. I have managed to capture the screen when it is looking for the sound card, and then just as it is about to reboot.

Tony

[tony1tf]

Just in case there was a pcb problem caused by the tight fit of the HDMI adaptor against the 3.5mm socket, I have checked all the connections between the codec and the R Pi, and all is OK. I also checked that the dtoverlay in config.txt looks correct to enable the codec with GPIO4. I noticed that there is a mod to the software 2 days ago wrt create-midi-gadget - could that be creating a problem?
I also tried using the haxophone as a USB MIDI device with Garage Band, but the gadget never announces itself on the Mac USB, and the HDMI screen still shows exactly the same wait for the Sound Card followed by a reboot.

[jcard0na]

Hi @tony1tf,

I am not aware of any issues that could cause the RPi to reboot. How is it powered up? Could it be that not enough power is supplied? My MacBook Air can power my haxophone, but I never use it with keyboard and HDMI, which apparently can draw an additional 100 mA, which might reach the limit of a laptop USB port.

Also, regarding USB MIDI, this is only enabled on the image from https://bit.ly/haxo-rpiz. When you unzip that image, you should see two files:

$ unzip haxophone.img.zip 
Archive:  haxophone.img.zip
  inflating: haxophone-rpiz.img      
  inflating: haxophone-rpiz.img.sha256  

You can check integrity with

$ cat haxophone-rpiz.img.sha256 
86c5d0280d49609a18d64c2d12d66b8480fe293a02b37d1f14569640d265e469  haxophone-rpiz.img

$ sha256sum -c haxophone-rpiz.img.sha256
(long wait)
haxophone-rpiz.img: OK

Let me know if that helps.

[tony1tf]

Hi Javier

Thanks for getting back to me. I've been powering the Haxophone with a high quality USB battery pack that gives around 4.9V or so at the R Pi 5V pins. I've also used it with and without keyboard and monitor, and/or powered from my MacBook. Everything went wrong when I downloaded a new image, so if you have an older one, I would be happy to try it again. If you look at the first of my screen pictures, you will see that the Pi timed out while waiting for /dev/sda1, then dependency failed for /media/usb (whatever the means!). Thereafter it was just a run down to a reboot. The behaviour is always identical, although of course I can't see that without a monitor plugged in. I'll try the link you sent, but I guess that will be the same as before - confirmed - that's the image of 21 Dec 2023 @ 20:48.

Tony

[jcard0na]

Hi @tony1tf ,

If you look at the first of my screen pictures, you will see that the Pi timed out while waiting for /dev/sda1, then dependency failed for /media/usb (whatever the means!).

The image tries to mount /media/usb if a usb drive is detected. This is useful for development, and that error message is harmless. It just indicates that the drive was not found. If you look at /etc/fstab you will see that the drive is mounted with option nofail.

I do not think the image is the cause for a reboot. It is the exact image I'm using, and there have been multiple reports of people using it successfully.

In #58 you say:

I disconnected the Haxophone, in case attaching the HDMI adaptor to the Pi Zero which presses against the sound o/p socket had flexed the pcb and damaged something, but this made no difference.

Does it mean your RPi Zero reboots even if the Haxophone is not attached? Just to test, I tried booting the RPi Zero detached from the Haxophone using image 86c5d02. My RPi boots successfully:

...                                                 
[   18.187704] systemd[1]: Starting Load/Save Random Seed...                                                                                                       
[   18.307728] systemd[1]: Starting Apply Kernel Variables...                                                                                                      
[   18.418309] systemd[1]: Starting Create System Users...                                                                                                         
[   18.571990] systemd[1]: Started Journal Service.                                                                                                                
                                                                                                                                                                   
Raspbian GNU/Linux 11 haxophone ttyAMA0                                                                                                                            
                                                                                                                                                                   
haxophone login: 

I use a serial console, not HDMI

It looks like you have tried to use a second RPi Zero, with same reboots, so we can rule out a defective RPi.
So far we we have:

1. RPi ✅ (tried a second unit, same reboot symptom)
2. Image ✅ (same image 86c5d02 works for others)
3. Haxophone ✅ (reboot happens without Haxophone attached)
4. Power supply ✅ (confirmed that it can supply sufficient power)
5. SD Card... ❓ Do you have a second SD card that you can try?

Running out of ideas here... 😵‍💫

[tony1tf]

Hi

Yes - the 2nd Pi Zero fails the same, and also fails when not connected to the Haxophone. I was thinking that perhaps you had changed the software so that it would not time out gracefully if the codec was not connected.
I don't have another SD card large enough. This was a 32GB because I didn't have a 16GB. Plenty of 8GB available. I'll get another couple of 16GB from Amazon tomorrow. It would be great if you could create an 8GB image, if that is big enough. The alternative is for me to use an 8GB card with the OS already there and download the code separately.

Tony

[tony1tf]

Hi Javier

No sound yet, but it must be getting closer. I have used an 8GB SD card with a previous R Pi OS on, and got linux running under the UTM emulator on my MacBook Pro. I copied the files to the correct directories, and the R Pi Zero, booted up OK with monitor and k/b attached. However, there was an error in the blink-zero code, because the modern version you used has the led called "ACT", and the old version has "led0". I edited blink-zero.service to use the old name, and it now booted without error. However, no sound yet. I'm not sure where to look - 'top' doesn't show anything like haxo running, so maybe there is another incompatibility I havn't found yet. Maybe I need to upgrade the OS to the latest Buster, or whatever it currently is called.

Tony

[jcard0na]

Can you look at the output of journalctl -u haxo?

[tony1tf]

You beat me to it! I just went to do that, having read discussion #56. It's full of errors associated with writing the midi-gadget file. Screen pic attached. BTW aplay lists the codec OK.
Tony

[tony1tf]

BTW - the R Pi Zero has a system name 'EDSACLA1' - could that be a problem?

[jcard0na]

Hi @tony1tf

The version of the create_midi_file.sh script that shipped with the released image would not allow restarting the service more than once. This was fixed here, so you might want to pick the latest version of the script from the repository.

Unfortunately your capture does not show why the service failed to start the first time around. You would need to scroll up for that. Or you can swap the script, and you'll get rid of those errors.

Regarding the hostname, I don't think EDSACLA1 will hurt.

[tony1tf]

I got the latest version of the script, but now get an execution error. Tony

…

On Fri, 5 Jan 2024 at 18:51, Javier Cardona ***@***.***> wrote: Hi @tony1tf <https://github.com/tony1tf> The version of the create_midi_file.sh script that shipped with the released image would not allow restarting the service more than once. This was fixed here <cardonabits/haxo-rs@6f11c89>, so you might want to pick the latest version of the script <https://github.com/cardonabits/haxo-rs/blob/main/scripts/systemd/create_midi_gadget.sh> from the repository. Unfortunately your capture does not show why the service failed to start the first time around. You would need to scroll up for that. Or you can swap the script, and you'll get rid of those errors. Regarding the hostname, I don't think EDSACLA1 will hurt. — Reply to this email directly, view it on GitHub <#59 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJKGTWET4JAEKPNTMFCTELYNBDS7AVCNFSM6AAAAABBJAN2YCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DAMRWGAYTK> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[tony1tf]

NOt sure whether my attachment got through from gmail - so here direct to github:

I got the latest version of the script, but now get an execution error - Permission denied
Tony

[jcard0na]

Did you make it executable? (i.e. chmod a+x /usr/local/bin/create_midi_gadget.sh)

[tony1tf]

Aha - thanks - we are getting somewhere. chmod a+x ...has stopped the Permission denied error.
However, we now seem to have run into a library problem - haxo001: error while loading shared libraries: libfluidsynth,so.2.....no such file or directory.
So it looks like I had better look at what libraries need downloading - looks like it's just that one.

T

[tony1tf]

Unfortunately, it looks like there are problems in the apt database for 'Buster' for libfluidsynth-dev. I had to use '--fix-missing'.
It has loaded fluid-soundfont-gm-3.1-5.1_all-deb, and unpacks qsynth.
However, this doesn't work - same problem - error while loading shared libraries: libfluidsynth.so.2............
So it looks like I am going to have to wait for an 8GB image from you, or replace the whole OS on my existing 8GB card.
Tony

[jcard0na]

Hi @tony1tf

You could also flash a fresh OS on an 8GB sd card. This is really easy with the Raspberry Pi Imager. Then, the configuration steps required to set up a haxophone image are documented here. This is the script I'm using to automate these steps.

If all seems daunting to you (not sure your level of familiarity with Linux and RPi...) you should try to get a 16GB card and flash one of the released images. (I don't have an 8GB card, and I'm already juggling with 16 GB images for 4 different Pi models, so I don't think I can add 8GB images to that list... 😞)

[tony1tf]

Tried git cloning your haxo-rs code, but 'cargo run' gives error -bash: cargo: command not found. I guess I need to install rust, but this is getting out of my comfort zone!

[tony1tf]

I've taken a different route now and used pishrink.sh from https://github.com/aikoncwd/PiShrink to compress the 16GB image to 4.9GB. I was able to burn this to an 8GB card with R Pi Imager.
It keeps the boot partition and compresses the ext4 partition in a way that booting up in the Raspberry Pi works.
However, I get the same rebooting of the Pi before I can get to a prompt. The image attached shows that it got through the sound card discovery, but fails at dphys swapfile, eventually leading to a reboot.

[jcard0na]

This is very strange. The swapfile error is benign: it shows up because the SD card is configured as read-only, and it does not create any problem, other than disabling the swap file.
I have the same error on my image and no reboots:

Jan 05 22:38:47 haxophone systemd[1]: dphys-swapfile.service: Main process exited, code=exited, status=255/EXCEPTION
Jan 05 22:38:47 haxophone systemd[1]: dphys-swapfile.service: Failed with result 'exit-code'.
Jan 05 22:38:47 haxophone systemd[1]: Failed to start dphys-swapfile - set up, mount/unmount, and delete a swap file.

The errors reported by rc.local are more troubling... failing to detect the overlay filesystem is critical. I have never tested PiShrink with overlay enabled, so you are breaking new ground.

Just to be paranoid, were you able to confirm the integrity of the image you downloaded by running?

$ unzip haxophone-rpiz.img.zip
$ sha256sum -c haxophone-rpiz.img.sha256
(long wait)
haxophone-rpiz.img: OK

[tony1tf]

Yes - it is correct. BTW - on the Mac, the command is shasum -a 256 haxophone-rpiz.img

[jcard0na]

On my Mac both options work.

[tony1tf]

I've ordered 2 16GB SD cards so I can get it working again (hopefully).
Current state of play is:
Old RPiZ16GB image on 32GB card worked
Newest RPiZ 16GB image on 32 GB card failed during boot.
2 year old working Rpi image couldn't get correct libraries to use existing Haxo code or build from scratch.
PiShrink 16GB image to c 4.9GB on 8GB failed during boot.

[jcard0na]

Hi @tony1tf,

Thanks for the update.

Old RPiZ16GB image on 32GB card worked

What do you mean by "worked". Were you able to play the haxophone?

Newest RPiZ 16GB image on 32 GB card failed during boot.

Looking carefully at the images you sent, it seems as if your RPi is doing an orderly shutdown in response to a command executed by the firstrun.sh script.

Your image is cropped, so I cannot see what that command is. But firstrun.sh is not included in the released image.

This is created by the Raspberry Pi Imager if you choose to apply custom settings.

Can you try and extract the contents of firstrun.sh and attach here? That script lives in the /boot partition, and it should be readable by inserting the SD card on your Mac.

And after that, can you retry to flash an SD card without customization settings?
If that fails, can you try to capture the full log where firstrun.sh commands are displayed?

I have a positive feeling about this... 🤞

[tony1tf]

Hi Javier "What do you mean by "worked". Were you able to play the haxophone?" - yes - I downloaded the RPi Zero image I found at Christmas to a 32GB card, and posted a video of me playing along with my friend improvising on piano, after I had learned as a complete 'Noob' to play the pentatonic scale. Initially, I was trying to get WiFi working so I could SSH to the Pi, and didn't at first realise that you had disabled WiFi. It all went wrong after that when I downloaded the later image that had the USB gadget mods, and I have never had a working saxophone since then. The 32GB SD card has 'firstrun.sh' - attached here - I have deleted my WiFi SSI psk string that appears on it. The 8GB version after the 'shrink' and boot up does not have a firstrun.sh file. I have also attached the cmdline and config files from the 32GB card. Tony

On Sun, 7 Jan 2024 at 11:23, Javier Cardona ***@***.***> wrote: Hi @tony1tf <https://github.com/tony1tf>, Thanks for the update. Old RPiZ16GB image on 32GB card worked What do you mean by "worked". Were you able to play the haxophone? Newest RPiZ 16GB image on 32 GB card failed during boot. Looking carefully at the images you sent, it seems as if your RPi is doing an orderly shutdown in response to a command executed by the firstrun.sh script. image.png (view on web) <https://github.com/cardonabits/haxo-hw/assets/676181/d63d14fc-1711-4c8a-8127-070be40eb1b4> Your image is cropped, so I cannot see what that command is. *But firstrun.sh is not included in the released image.* Screenshot.from.2024-01-07.11-08-59.png (view on web) <https://github.com/cardonabits/haxo-hw/assets/676181/ef021455-3695-40c3-ac65-7802a2d06566> This is created by the Raspberry Pi Imager if you choose to apply custom settings. Screenshot.from.2024-01-06.14-36-32.png (view on web) <https://github.com/cardonabits/haxo-hw/assets/676181/6800ca0c-ebc5-4a4e-9e3a-3d0596a067c3> Screenshot.from.2024-01-07.11-08-07.png (view on web) <https://github.com/cardonabits/haxo-hw/assets/676181/fba00199-318a-4c61-b5a8-d0ab156c28c2> Screenshot.from.2024-01-07.11-08-17.png (view on web) <https://github.com/cardonabits/haxo-hw/assets/676181/381834f9-ad70-459b-aa75-8a3c14a5d698> Can you try and extract the contents of firstrun.sh and attach here? That script lives in the /boot partition, and it should be readable by inserting the SD card on your Mac. And after that, can you retry to flash an SD card *without customization settings*? If that fails, can you try to capture the full log where firstrun.sh commands are displayed? I have a positive feeling about this... 🤞 — Reply to this email directly, view it on GitHub <#59 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJKGTX53YS2BDPBSEF7NGLYNKAULAVCNFSM6AAAAABBJAN2YCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DAMZWGI2TK> . You are receiving this because you were mentioned.Message ID: ***@***.***>

boot=overlay console=serial0,115200 console=tty1 root=PARTUUID=4c4e106f-02 rootfstype=ext4 fsck.repair=yes rootwait cfg80211.ieee80211_regdom=GB systemd.run=/boot/firstrun.sh systemd.run_success_action=reboot systemd.unit=kernel-command-line.target # For more options and information see # http://rpf.io/configtxt # Some settings may impact device functionality. See link above for details # uncomment if you get no picture on HDMI for a default "safe" mode #hdmi_safe=1 # uncomment the following to adjust overscan. Use positive numbers if console # goes off screen, and negative if there is too much border #overscan_left=16 #overscan_right=16 #overscan_top=16 #overscan_bottom=16 # uncomment to force a console size. By default it will be display's size minus # overscan. #framebuffer_width=1280 #framebuffer_height=720 # uncomment if hdmi display is not detected and composite is being output #hdmi_force_hotplug=1 # uncomment to force a specific HDMI mode (this will force VGA) #hdmi_group=1 #hdmi_mode=1 # uncomment to force a HDMI mode rather than DVI. This can make audio work in # DMT (computer monitor) modes #hdmi_drive=2 # uncomment to increase signal to HDMI, if you have interference, blanking, or # no display #config_hdmi_boost=4 # uncomment for composite PAL #sdtv_mode=2 #uncomment to overclock the arm. 700 MHz is the default. #arm_freq=800 # Uncomment some or all of these to enable the optional hardware interfaces dtparam=i2c_arm=on #dtparam=i2s=on #dtparam=spi=on # Uncomment this to enable infrared communication. #dtoverlay=gpio-ir,gpio_pin=17 #dtoverlay=gpio-ir-tx,gpio_pin=18 # Additional overlays and parameters are documented /boot/overlays/README # Enable audio (loads snd_bcm2835) # dtparam=audio=on # Enable haxophone built in sound card dtoverlay=max98357a,sdmode-pin=4 # Automatically load overlays for detected cameras camera_auto_detect=1 # Automatically load overlays for detected DSI displays display_auto_detect=1 # Enable DRM VC4 V3D driver dtoverlay=vc4-kms-v3d max_framebuffers=2 # Disable compensation for displays with overscan disable_overscan=1 [cm4] # Enable host mode on the 2711 built-in XHCI USB controller. # This line should be removed if the legacy DWC2 controller is required # (e.g. for USB device mode) or if USB support is not required. #otg_mode=1 [all] [pi4] # Run as fast as firmware / board allows arm_boost=1 [all] enable_uart=1 dtoverlay=dwc2 dtoverlay=disable-wifi dtoverlay=disable-bt dtparam=i2c_arm_baudrate=400000 initramfs initrd.img-6.1.21+-overlay

[jcard0na]

posted a video of me playing along with my friend improvising on piano

🤦 Of course! I loved that video, but I did not associate your handle (@tony1tf) with it. Sorry!

The 32GB SD card has 'firstrun.sh'

I don't think you attached firstrun.sh to your reply. That seems to be the contents of cmdline.txt instead:

boot=overlay console=serial0,115200 console=tty1 root=PARTUUID=4c4e106f-02 rootfstype=ext4 fsck.repair=yes rootwait cfg80211.ieee80211_regdom=GB systemd.run=/boot/firstrun.sh systemd.run_success_action=reboot systemd.unit=kernel-command-line.target

At any rate, the fact that you have a firstrun.shexplains why your boot failed. I'm guessing your firstrun.sh script tries to configure SSH, and that fails due to overlayfs being enabled. Normally firstrun.sh deletes itself after successful execution, but in your case I suspect it fails and it does not. That would explain your endless loop of reboots.

To fix that:

1. Either flash the released image without customizations using Raspberry Pi Imager or even dd, if you are familiar with that command
   OR
2. Delete firstrun.sh from the /boot partition

Please, try that and let me know!

PS. If you want to make modifications to the released image, you will need to disable overlay first. SSH is enabled by default, but only via Ethernet.

[tony1tf]

Hi Javier
I attached firstrun.sh to the reply I sent you from my gmail account. Not sure why it didn't appear. I'll attach here at github. Aha - I see now - it doesn't allow .sh files - I got an error message. I'll make it text - done.

What I don't understand, is that I wasn't doing any customisation initially, so I don't understand the problem. Anyway - I'm expecting a 16GB card to arrive today, so will try to put the current image on it without customisation and see if it works.
Tony

firstrun.sh.txt

[tony1tf]

Hi Javier

Thank you - even before the new 16GB card arrived, you have given me the clue to why the 32GB image wasn't working. I deleted firstrun.sh, and edited cmdline.txt to remove everything after 'rootwait' that calls firstrun. I must have unknowingly generated firstrun etc after the original success, in an effort to get WiFi working, and then subsequently I put the disable WiFi command back in the configuration file, but by that time, the damage was done. I have never had any knowledge of how R Pis boot up, so this is all quite revealing.
I have a working haxophone again.

Tony

[jcard0na]

Yay! Glad I could help. Thanks to this, I learned about RPi customizations as well. I did not know about firstrun.sh until you raised this issue. Closing it now.

Thanks!