Is the zynthian connected to the internet? The raspberry pi does not have a persistent real-time clock so it’s date and time must be updated via NTP over the internet to give accurate file timestamps.
ok understood, it should be connected by wifi but the signal is poor or not stable
I am wondering if this could be a cause of error at starting.
When the Zynthian starts connected by Ethernet: till now no issues
When the Zynthian starts connected by WIFI, close to router: till now no issues
In log there are two errors:
Nov 27 14:53:10 zynthian kernel: bcm2708_fb soc@107c000000:fb: probe with driver bcm2708_fb failed with error -2
Nov 27 14:53:12 zynthian alsactl[787]: alsa-lib main.c:1541:(snd_use_case_mgr_open) error: failed to import hw:0 use case configuration -2
about this in webconf > hw-audio is written with yellow background:
Software latency: 5.3ms. (Actual latency may be higher due to soundcard hardware.)
Note: Some parameter values do not work on some soundcards.
Was that the first or the second time?
Can you provide a log from the failing boot?
When you start again, the first one gets overwritten. I think syslog is written to temporary storage.
was the second one (after regular start) because when it starts with error is not possible to connect by terminal
I’m seeing that with the Zynthian near the router I had no problems at start (cross fingers).
So it could be caused by wifi.
If it were like this how could I solve it? keep wifi off? add usb wifi pen? what else?
I use wired network connection on mine, as i did never had any good experiences with the wifi, but i also never experienced the problems you are experiencing @piattica . Of course this was one year back and the world has moved since (Zynthian in the right direction - the rest of the world im not sure of ![]()
Are you using an SSH connection or are you using the terminal in Webconf?
The teminal in Webconf will not work because Zynthian is not starting.
Can you try to connect via SSH? Using PuTTY or something like that?
Then you can see the journal from the failing session.
Linux itself is very robust, so this should work. If it doesn’t then there is little we can do here.
Well maybe it should not, but in practice it definitely does. Sometime ago I had a corrupted SD card because of this. Since then I meticulously use “power off” before switching the power off. No more corrupted card problems.
As @piattica mentions:
So it’s worth a try.
Ideally, a device like this should have a read-only file system, but I don’t think that’s feasible given all the options and capabilities of Zynthian.
when it will happen I will try to do it
Speaking of coincidences, I haven’t said it doesn’t happen anymore or my Zynthian fails to boot… ![]()
@piattica That’s another thing you can do, connect an HDMI cable and see if the RPi is starting..
EDIT:
When I check the non-working SD card with fsck, several problems are detected. If you see these, there’s no point in using the repair options. It’s better to reflash the card.
(venv) root@zynthian:~# fsck /dev/sdb1
fsck from util-linux 2.38.1
fsck.fat 4.2 (2021-01-31)
There are differences between boot sector and its backup.
This is mostly harmless. Differences: (offset:original/backup)
65:01/00
1) Copy original to backup
2) Copy backup to original
3) No action
[123?q]? 3
/config.txt
Contains a free cluster (121952). Assuming EOF.
/config.txt
File size is 2331 bytes, cluster chain length is 0 bytes.
Truncating file to 0 bytes.
/cmdline.txt
Contains a free cluster (121954). Assuming EOF.
/cmdline.txt
File size is 201 bytes, cluster chain length is 0 bytes.
Truncating file to 0 bytes.
Reclaimed 3 unused clusters (6144 bytes).
Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
1) Remove dirty bit
2) No action
[12?q]? 2
Free cluster summary wrong (227207 vs. really 227209)
1) Correct
2) Don't correct
[12?q]? 2
*** Filesystem was changed ***
The changes have not yet been written, you can still choose to leave the
filesystem unmodified:
1) Write changes
2) Leave filesystem unchanged
[12?q]? 2
/dev/sdb1: 438 files, 33906/261115 clusters
