Supercollider fail following expanding filesystem

Monome
1

I just got my Norns shield (211028 & rPI4) yesterday. I followed the instructions to write the image (220306) to the SD card (Samsung EVO Select 128GB) and it booted up fine. I configured the wifi and followed instructions for expanding the filesystem via ssh. When I finished with raspi-config, it rebooted and after a short delay started up with a “SUPERCOLLIDER FAIL” error. The same thing happens on subsequent reboots.

I repeated the fresh install process twice more with the same results. There are some guidelines for troubleshooting supercollider failures, but I wanted to ask here first because I don’t see any discussion of other people having the same experience. I think I’m following the instructions carefully, but maybe I’m missing something.

Thanks,

Larry

2

ah that sounds frustrating.

can you verify that you have the right image? based on your board (211028) and pi (pi4) you need the highlighted one:

select
select654×642 62.4 KB

3

Hello, thanks for the help. Yes, a bit frustrating, but I’m sure the destination is going to be worth the journey!

Yes, that is the image I used. same version, rpi4 and cs4271.

Larry

5

SUPERCOLLIDER FAIL is perhaps some trouble with conflicting engines – could you please share the logs generated by the system as you restart? just drop the file here :slight_smile:

6

Update: I tried a different SD card and I got the supercollider error when booting after the filesystem expansion. However, I shut down and booted again and this time I didn’t get the error (unlike before with the other SD card). Maybe it was just the Samsung SD card.

If I run into it again I’ll post logs here.

Thanks,

Larry

1 Like
8

it seems strange and i’d be curious to see the logs, or even just the output of the SC REPL if the problem ever recurs

9

Hello,

It is strange. If you are interested, here are the logs I extracted: https://drive.google.com/file/d/1yK2DSAgdTrx7hLXBNuQpx-LsFDOgnwI6/view?usp=share_link

Since then I have done a fresh install yet again and I’m trying to see if I have any remaining issues. I did notice that by default the gain on the input was set high and it caused some sort of interference on my output signal. turning the gain on the input down to the minimum fixed the problem. I haven’t yet searched to see if that is a common issue or not.

Larry

10

This might be an even better log to look at: https://drive.google.com/file/d/1RDzzI1kzqdiT3RucoLn7NPT7bDZzrrVl/view?usp=sharing

This is a log I took immediately after seeing the supercollider error after the reboot following a filesystem expansion.

Larry

11

“Supercollider fail following expanding filesystem” sounds like a headline from the 22nd Century.

1 Like
12

For what it’s worth, I’ve seen the “Supercollider Fail” notification on the first boot after expanding, every time I’ve done a reinstall.

13

Yes, there is a note in the instructions saying to ignore any errors you may get on first boot after an expansion. With the first SD card I was using I got the same error on every boot. With the second SD card I am using I get it only on the first boot (like you). Looks like that is normal behavior.

Thanks,

Larry

2 Likes
14

for what its worth, this log looks normal.

15

Thanks for looking at it! Which one did you look at? the one in my first reply linking to a log or the second one?

Larry

16

i see two links to two separate files above:

norns_export_following_supercollider_error.txt
norns_logs.txt

these files appear to be identical (diff is zero.) perhaps a transfer error.

this log shows what appears to be a normal boot of the system and a load of the awake script and its engine. supercollider has booted and successfully reports engine params to matron after script load. then logs are exported at timestamp Sun 2023-04-16 19:27:21.

the previous boot also shows SC booting successfully, but its boot msgs are interspersed with networkmanager / wlan / avahi cruft. hypothetically if some sort of system config process is doing a lot of work, SC could miss its start-up report deadline whereupon matron would consider it unresponsive and show SUPERCOLLIDER FAIL. however that again does not seem to have happened as matron does proceed to register engine commands again.

so i am not sure what happened but i have to assume it is not illustrative of anything systemic:

  • as noted, we do recommend one reboot after FS expansion.
  • i have to assume the first SD card was just not fast enough or something. (likely operating out of spec as they often do.) if disk access too slow, boot too slow, again SC misses deadline for post-boot handshake.

i’m still sort of curious. we might be showing the FAIL error spuriously so i will try and repro that.

17

Hello,

Sorry about that!. I did something wrong the second time I tried to capture logs and somehow ended up with a copy of the first set of logs. I’m not sure, but I think “maybe” I forgot to refresh maiden and ended up copy/pasting the same logs the second time.

Your analysis reminded me of something I neglected to mention. Boots where the supercollider error ultimately happened took much longer than normal boots. That aligns with what you said about the possibility that “SC could miss its start-up report deadline”.

If I understand correctly, boots after file system expansions take longer because of the expansion activity. From what you said, it seems like that could cause the supercollider error. So, that’s harmless since the instructions already say to just reboot if any errors show up when booting after the expansion. You mentioned that too.

The intention of my second attempt to capture logs (which were lost) was just to shed light on the root cause of the supercollider error happening after filesystem expansion. Seems like we have a working theory on that now: Expansion slows down the boot process. Therefore supercollider error occurs when it misses its deadline.

Furthermore, regarding the bad SD card, I’m thinking that maybe the expansion was failing on boot and so it tried and failed every time thereby causing the supercollider error every time as well. I don’t know what is wrong with that card, its specs are good, but it must be defective in some way. It doesn’t matter, it’s going in the trash.

I agree, not systemic. All indications are that this behavior is expected and understood on the first boot after a filesystem expansion and the bad SD card was responsible for the repeated failures.

So, you figured it out despite me screwing up the logs. Excellent!

Thanks a lot,

Larry