I thought, we were zynthianos
FYI, Minibian distro comes “out-the-box” with a root account configured with “raspbian” as password. There are no “normal” accounts.
Zynthian setup scripts and software works with this premise: root user is the only user and everything runs as root.
For an embbeded system like zynthian this is very convenient and simplifies everything
It seems like some plugins were failing.
How are you testing the image? By default PiTFT display is pre-configured, so you have to reconfigure the display using the webconf tool.
AFAIK, there is no PiTFT compilation. PiTFT drivers are precompiled an ready to use.
Could you copy the lines with this error? I can’t find it in the build log you linked. It seems incomplete.
I see a lot of errors related to “chown” command. Is it because of the lacking of a root account?
Regards … and thanks!!
Good news - when setting the sound card right AND adding a root password MOD-UI works.
My misstake , it was pffft:
You can see all 15 errors highlighted here.
make: *** [src/avtk/CMakeFiles/avtk.dir/all] Error 2
make: *** [tap_rotspeak.so] Error 1
There is also a:
/bin/mv: cannot stat '/root/.lv2/*': No such file or directory
This means we nearly got it right, and the next build with the root password might actually be usable.
Reguarding minibian and root password -
There is a good reason to add a user which is not root, beyond the security. For example, chromium-browser will not run as root, its hard-coded.
However, I don’t want to tell you how to run the project, we could also make a minibian variant. CustomPiOS supports making variants which can use different base images. For example anything that uses Armbian.
I would prefer a sudo user instead of root as well.
webconf needs to be a sudoer though.
I guess, CustomPiOS will be the next base.
When all engines, especially Pianoteq are ported.
I think the best way for now would be to try and replicate what there is on stretch. Then start thinking about changing behavor. Bahavor changes can effect users directly and might get some upset.
In OctoPi we disabled passwordless sudo. There is a talk on why there if you want to read more about it:
You can also set specific files to run as sudo. I actually use that for the setup of the build.
Looks like this:
guy@Golem2:~$ sudo cat /etc/sudoers.d/zynthianos jenkins ALL=(root) NOPASSWD: /usr/local/bin/zynthianos
Anyway, waiting to upload the next image which will have a root password. And hopefully usable but with minor things to fix.
The first SD images of zynthian used the “pi” user and used “sudo” all the time, but after thinking about it, i realized that things will be simpler if everything runs as root. And it really is
Think about it. Zynthian is not a public server. It’s not constantly exposed to Internet. It’s an embbeded system and using root as the only user has sense and simplifies everything.
If you want to expose your Zynthian, you should change the password. That’s all.
Anyway, in the worst case, if your zynthian is rooted, you burn a new SD and choose a decent password
Moreover, MOD people runs everything as root in its device, so mod-ui and mod-host must be executed as root …
Of course, i would like to hear your arguments for using a “multi-user” approach
Ok, latest image.
DId all the hostname and password fixes, also remvoed the realtime kernel for now, its now a variant.
So you can build either from the stretch light distro, or from the realtime kernel disro.
Would appreciate people testing and reporting if it works.
I looked with qemu and got a strange behavior. it kept restarting the webconf. Image attached.
I am also using at home one of the earlier builds with a realtime kernel, and using it for FX for my electric violin
Sorry - I currently have not much time to check this… perhaps at weekend…
I can also build a realtime kernel version if anyone wants to try. I mostly found that the minute you switch jack service on it lags a lot with anything related to wifi. Perhaps there is a way around that. But its amazing latency for my electric violin - Really should measure it out.
We could also open this to more adventurous users outside the staff thread.
Ok, seem to have figured out why its rebooting. The python returns “illegal instruction”. Not sure if its a configuration issue or the qemu kernel issue. I have a feeling its the latter.
Could you stop the service and run the zynthian_webconf.sh manually?
It should show log messages.
I did that, it does not get as far as the imports in the python code. I found that tornado spikes it, but also some stuff at the bottom, could not track it down.
I think there must either be something compiled there exclusively for arm7 in a way that does not work on the qemu kernel.
Anyway posted a question there: https://github.com/dhruvvyas90/qemu-rpi-kernel/issues/49
OK! Let’s open this thread to all the community … no reason to keep it closed
Ok, finally, all lv2 plugins have been fixed, in most cases by sending PRs to the projects themselves, which means they are less likely to break again.
And finally, we have a build that I see nothing that is broken in it. So now We need testers.
What is left before we release this image?
Will note we will probably build again once more because Gina from OctoPi just pushed a bunch of fixes to the build system that should go in it.
Got it and tried… had to chnage my display and wiring. Now it boots. Checking the rest soon.
What I currently found: In webconf the page “Software” does not work -> produces an error.
BTW: What is the root password for ssh?
Thanks && regards, Holger
Suggest you open an issue on github with the attached logs, so we can fix it.
The password is ‘raspberry’. Its set here (yay we have sources): https://github.com/guysoft/ZynthianOS/blob/devel/src/modules/zynthianos/start_chroot_script#L19
Sorry, my fault. Had not tried as root
Doesn’t work either… will open an issue…
[EDIT]: Ok… login as
pi and then
sudo… I got it…
Ok, will try now with logging into system…
[EDIT]: It’s a small er problem in zynthian-webconf. will fix it by myself.
and then su root to get update_zynthian.sh running