hostedOS14 first boot broken on rPi with 256 MiB memory

Help
1

I just tested the testing channel on an original 256 MiB memory rPi 1. It runs out of memory during first boot.


    Booting up..

[*] Waiting for storage device
[*] testing:240515:125a8c:stable-0014 (first boot) on 00000002 (v6, 0)
[*] Drivers loaded
[*] Using Ethernet
[*] Mounting stage2... ok
[*] Entering stage2
[*] First boot detected
    ===================

    We have to prepare a few things. This is only done
    once and it only takes a few seconds. Stay tuned.

    Do *NOT* remove power until this setup is done.

[*] Creating system partitions
[   14.686863] Out of memory: Killed process 158 (sysfs-gpio) total-vm:1800kB, anon-rss:88kB,
file-rss:0kB, shmem-rss:244kB, UID:0, pgtables:8kB oom_score_adj:0
[   14.886940] Out of memory: Killed process 174 (init) total-vm:1288kB, anon-rss:52kB, file-rss:0kB, shmem-rss:0kB, UID:0, pgtables:6kB oom_score_adj:0
[   14.927275] Out of memory: Killed process 193 (cp) total-vm:1256kB, anon-rss:20kB, file-rss:0kB, shmem-rss:0kB, UID:0, pgtables:6kB oom_score_adj:0

I was able to work around or fix the problem. After deleting gpu_mem_256=128 and gpu_mem_512=256 from config.txt first boot was successfull.

According to https://www.raspberrypi.com/documentation/computers/legacy_config_txt.html#gpu_mem the ā€˜gpu_memā€™ settings are deprecated. Probably cause ā€œgpuā€ driver has been reworked heavily and memory is allocated dynamically nowadays. But I am not sure. Only rumours I heard.

1 Like
2

Thanks for reporting! gpu_mem is indeed deprecated when using the default kms overlay mode on one of the modern Pis. For Pis up to model 3, info-beamer still uses the older (but reliable) broadcom API. For that, gpu_mem is still relevant. Deleting the setting will use the default. Itā€™s probably not 128MB on a Pi with only 256 :slight_smile:

Iā€˜ll check what can be improved to make this work.

3

Should be fixed in the latest testing release. I found a way to reduce the temporary memory usage while doing the installation by almost 30MB[1]. If you try again, installation now works. At least on my Pi1.

I didnā€™t even notice last time, but did you actually OCR the boot screen output? Or how did you get the text output into this post?

[1] Technical details: While completely repartitioning the SD card during installation, all OS files have to temporarily move into RAM only. Previously the OS copied all files (around 70MB) to /tmp, a tmpfs filesystem. I realized that copying stage2.img isnā€™t actually needed as itā€™s already mounted as loopback, so its content is already in RAM at this point and I can copy back from /dev/loop0 instead of creating another copy. Yay :-]

4

just found this post after testing stuff with my Pi Zero W and Zero 2 W (512mb)

im still having a memory issue on either stable or testing

the memory is pinned at 95% used because its split 256/256

all its doing is playing 6 static images and 2x20sec videos with the HD video player package

its using about 20% gpu on static images and 30% gpu when the videos are playing

is the no way of setting the gpu_mem to 128MB?

this would give the pi abit more head room to breath

ive tried setting gpu_mem=128 in Custom Pi boot configuration in /config/userconfig.txt

and also gpu_mem_512=128 too but nothing works

any suggestions?

5

Not sure Iā€™m following. What exactly is the issue? Is something not working? If itā€™s just the memory being full, then: Good. Itā€™s being used for caching file access.

6

its ok now, i think i was panicing because the memory was saying 95% used!
after doing a-bit of testing, the Pi Zero W is handling things perfectly fine!
the Pi Zero W hasnt crashed once, changed whever i told it to,
even streams 9 RTSP cameras no problems!
thank you anyways!

7

I already linked a page that goes into that. But just to summarize here: Thatā€™s a good thing! The memory is used to hold loaded content in memory so it doesnā€™t have to be read from the SD card every time itā€™s being used. Thatā€™s the ā€œpage cacheā€. Any data loaded from SD it goes there. Repeated access can then avoid SD access completely and use the cache data instead. If some process really needs the memory, the cached data can be free up, but of course any followup request for the data then has to read from the SD again.

1 Like