@gnome666 this update copies very little and IMHO is not a likely direct cause of the issue.

more likely the filesystem was already full.

i suspect a buildup of log files as described/addressed earlier in this thread.

log into norns (screen will work for this if you can’t network), then:.
du -h /var/log to see if logfiles are big
ls -lahS /var/log to see more specifically what files are big

then you probably want, e.g.
sudo rm -rf /var/log/syslog
sudo rm -rf /var/log/kern.log

or even the big hammer
sudo rm -rf /var/log/*

… but this is ultimately a quick fix. if indeed that is the problem, we should see what is filling up the logs, and/or rotate/cull them more aggressively. (which i dn’t know how to do but maybe e.g. @simonvanderveldt does)

…i’ll check that crone isn’t printing a lot of debug junk or something

Do you mean log in with cyber duck? Or maiden? If it’s terminal level stuff it’s a bit outta my league :frowning:

its terminal level stuff but you can do it

open terminal
ssh we@norns.local
password: sleep (unless you’ve changed it, which in fact i recommend doing)

then the other stuff above

will give it a go now. if it helps, turns out that the dustv1 folder is bigger than dust folder on norns…can it be deleted? my total we folder is about 600mb

yea, back up things you want (like audio)

looks like kern.log is taking up 1.4 GB? can that be right?18%20PM

btw, i can still run all the installed scripts on my norns with no problem. it seems like its purely a storage issue of not having enough space to do the update procedure

delete the kern.log
sudo rm -rf /var/log/kern.log

(if you want to be extra helpful, see upthread for how to send us a snippet of kern.log before delting it so we can try and see what is doing that… but it will surely continue to happen so no worries there)

it’s “right” in the sense of, yes, it really is taking up that much space

it’s “wrong” in every other sense.

@tehn et al we should probably address this behavior. i can pitch in with eliminating excess logging from crone and matron. it seems like log rotation should be preventing this in any case, but i don’t know enough about it.

Thanks for all the help. I’m logged off and away from Norns, but will definitely try to get you some info before I delete the kern.log :+1:

Can someone suggest a “stress-test” script that uses lots of CPU?

I’m curious about monitoring/charting CPU% and Temperature levels with the pi 4

we actually did a ton of log reduction last time we had this problem and i haven’t seen it emerge again. i can check on kern.log on my system to see if it’s growing.

i’d suggest just doing this using stress on the command line, not via the norns software stack.

2 Likes

i attempted to search through the thread but my search-fu is weak. whats the best way for me to get you useful data before I delete it?

thnx

Could be https://github.com/monome/norns-image/issues/43 ?

Do the same thing you did before when you listed the files in /var/log only now do tail -n1000 /var/log/kern.log. That should give you the last 1000 lines of that file.
You can paste it on a paste site like https://bpaste.net

couldnt figure out bpast, kept getting size limit errors. heres what I got in a text file. thanks for all the help everyone.kern.rtf (93.1 KB) kern.pdf (90.9 KB)

Has anyone had an issue performing a fresh install?

I can’t get past about 15% on Etcher before it fails. I’m also getting multiple push notifications saying “Eject “boot” before disconnecting or turning it off” as if Norns is spontaneously turning off or losing connection to the computer - this occasionally prevents Etcher from finding the Compute Module before flashing.

***update: Seems the USB cable was the culprit. Tried a new one, flashed successfully on the first try & norns is running smooth. Leaving this here in case others fail to troubleshoot like I did :upside_down_face:

2 Likes

This has probably been asked before but I don’t recall. Apologies if so. I was wondering if it’s possible to route the tape outputs to norns inputs? Thus use the tape player as an input instrument?

2 Likes

at present, TAPE can be routed to softcut input, but not to supercollider input.

this is the current routing chart.

(there have also been requests for a softcut->supercollider route, which would alllow lots of feedback.)

it’s not hard to add routes, though it is a little tedious/finicky to add all the relevant glue. @Dewb contributed the latest additions in this PR.

adding routes does have a small impact on CPU usage of mixer client. viz., at present there is no mechanism for conditionally disabling the processing of a route when its level is zeroed.

given that eventually, every route will be requested, it might make sense to simply implement (yet another) fully modular framework within the crone mixer client. but i’m not in a hurry to do this.

not sure if this should be here or the MLR post, but its more of a general System question I suppose…

I’ve been having trouble being able to get live sound into Norns for recording purposes, either for Cranes, MLR, or other, without getting really bad distortion. I’m currently trying to get it to work with MLR and i feel like i’ve done most permutations I know of. I’m sending the stereo outs from my wmd performance mixer into Norns. Whenever i record something that sounds decent level out of the mixer, it is really distorted on playback. I’ve tried decreasing the input, both in system audio, and decrease rec level on MLR. but those seem to only result in quiter distorted sounds. I dont understand how softuct and engine affect things, but when I decrease the softcut header the overall levels out of norns are quieter.

anyway, I think I’ve read about issues matching levels elsewhere, but any tips anyone had would be appreciated…thnx

1 Like

Does this happen with the “monitor” route as well?

Is it a sort of ring-modulated sound? Like extreme aliasing : samplerate mismatch?

I just had this kind of distortion today, for the first time, out of the blue after power down and power up. took several restarts, magic wands, etc and then just went away again. It seemed to be at the ALSA / driver / kernel level as the artifact persisted with the norns stack halted and just pass through in alsamixer. Will be trying to reproduce with kernel logs under less trying circumstances.

1 Like