and sorry for bothering you guys once again with a sad face loop. I have tried to find hints in the previous posts on the topic but it seems that those issues popped up after an update or an add-on installation, whereas in my case the loop starts right with the first boot from a freshly installed file system (Raspberry Pi 3A, SanDisk Edge 16GB A1 U1 Class 10, image OSMC_TGT_rbp2_20210808.img):
First everything seems normal from the rainbow screen to the message “OSMC installed successfully” and reboot, but then “[ *** ] A start job is running for Set Time using HTTP query (01s / no limit)” appears in the upper left corner, first on a black screen and after a few seconds on a blue, sad face screen, counting up to a bit more than one minute (in the meantime some screen refreshes with short blackouts) . Thereafter, the message is cleared and new status messages are displayed in the upper left corner:
[ OK ] Started Set Time using HTTP query.
Starting Network Time Service…
[ OK ] Started Network Time Service.
[ OK ] Reached target Multi-User System.
[ OK ] Reached target Graphical Interface.
Stating Update UTMP about System Runlevel Changes…
[ OK ] Started Update about System Runlevel Changes.
The screen is cleared again showing only the plain sad face which keeps getting refreshed every once in a while (again short blackouts). This state does not change anymore (I have switched off after approx. half an hour), at the next boot the sad face procedure starts over again.
Does the system wait for a network connection (which for a Raspberry 3A does not exist at this stage because it can only connect via WLAN which is not configured yet)? I could try using a USB-Ethernet adapter (just need to find a micro-USB USB-A adapter first), however, OSMC should allow a start without network connection at least for the first time, no?
Does someone know a solution (maybe it is even a small bug in the OSMC code)?
Thanks, WackyT; that’s actually where I was coming from: Had OSMC_TGT_rbp2_20201227.img installed, went for the update and ended up with sad faces, so I decided to erase the SD and start again with the most recent image… But I remember that installing the former version had not been 100% smooth either.
Update: I also installed the November image freshly (on the same SD card) which worked well. But when I tried to upgrade then, I got the same effect as for the direct installation of the most recent image: Sad face loop after succesful installation of the files!
Actually, gpu_mem_1024 did not change anything (according to vcgencmd get_mem gpu), whereas gpu_mem did, however, the sad face issue persists. Thanks anyway!
You have a Pi 3A, which has only 512 MB of RAM. Looks like it doesn’t have enough memory to operate:
Aug 23 16:12:33 melpomene mediacenter[318]: Mesa: User error: GL_OUT_OF_MEMORY in VBO allocation
Aug 23 16:12:33 melpomene mediacenter[318]: ../src/mesa/vbo/vbo_exec_api.c:1014:vbo_exec_vtx_init: Assertion `exec->vtx.buffer_ptr' failed.
Aug 23 16:12:33 melpomene kernel: [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
Aug 23 16:12:33 melpomene kernel: vc4-drm soc:gpu: [drm] dumb: 4500kb BOs (1)
Aug 23 16:12:33 melpomene kernel: vc4_v3d 3fc00000.v3d: Failed to allocate memory for tile binning: -12. You may need to enable CMA or give it more memory.
You are 101% right, I should have guessed that earlier… Seems the November version was barely running with scarce 512 MB RAM whereas the current one simply cannot. Ok, time for a new Raspi (and to find a better job for the 3A, which I still like… )!
Again many thanks to all who have answered and advised me; this forum is really great and the responsiveness is awesome!
P.S. Any chance to make the sad face a bit more talkative so it gives some hints where the major troubles lie?
)!