Bugzilla – Bug 1074566
rpi3: Boot failed due to library missing
Last modified: 2018-07-16 15:55:10 UTC
Created attachment 754741 [details]
I'm using a Raspberry Pi 3, and I tried the image [http://download.opensuse.org/ports/aarch64/tumbleweed/images/openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64-2017.12.04-Build2.23.raw.xz].
Once powered on, the GRUB splash appear and the boot process starts but suddenly stops with a kernel panic:
/bin/bash: error while loading shared libraries: libreadline.so.7: cannot open shared object file: No such file or directory
It seems to be similar to this old issue [https://forums.opensuse.org/showthread.php/389864-Boot-problem-libreadline-so-5].
The image is valid (sha256 checked) and the SD has no write/read issues.
I attach now a photo of what I got at the moment of the kernel panic.
Andreas, can you, please, have a look?
The initramfs failed to unpack, probably too big for the small memory in the RPi3.
The problem is not the amount of memory on the RPi3, it's that someone changed the amount of memory available in the boot config.txt file but forgot to reflect this change in the initramfs. If you want it to boot, you'll have to change the config.txt file to reduce the amount of GPU memory from 128 to 96. This is set for the lower memory amounts, but the Pi3 has 1G of memory. After this is set, you may be able to increase the amount of GPU memory available after recreating the initramfs file with the actual amount of RAM available included in the command.
In general, just change the config.txt file to reduce the amount of GPU memory to 96 instead of 128.
I've reduced the amount of CMA memory we reserve by default in the image, so that should also help.
I agree that we reserve *way* too much memory for the VPU though. Since we're not using the VPU for 3d (vc4 bypasses it), we can probably live with ~16MB of memory reserved for it.
I don't know if maybe video decoding would need more, but that's only available in the downstream kernel iiuc, so worst case the contrib project would need to override config.txt accordingly.
I've send an SR to the OpenSUSE RPI FW project to clean up config.txt and reduce GPU RAM usage to 32MB which was enough for everything I've tried so far:
Hm, I should've looked through the config.txt change first:
+Tue Sep 27 09:09:10 UTC 2016 - email@example.com
+- Increase from 64 MB to 96 MB of RAM for GPU for RPi with 256 or
+ 512 MB of RAM to be able to decode a 1080p h264 video in kodi
Apparently Guillaume has GPU accelerated graphics decoding working? In that case we may need more GPU RAM reserved...
(In reply to Alexander Graf from comment #7)
> Hm, I should've looked through the config.txt change first:
> +Tue Sep 27 09:09:10 UTC 2016 - firstname.lastname@example.org
> +- Increase from 64 MB to 96 MB of RAM for GPU for RPi with 256 or
> + 512 MB of RAM to be able to decode a 1080p h264 video in kodi
> Apparently Guillaume has GPU accelerated graphics decoding working? In that
> case we may need more GPU RAM reserved...
It is doable only with a downstream kernel. So, feel free to change it for upstream images. If needed, we can adjust it for the Contrib repo (which I did not updated since a while...).
I just want to take a moment to point out that the best solution may be to take advantage of the RPi3's ability to dynamically allocate memory between the GPU and system. While it is tricky, it can be done in the config.txt file with two or three special options. We could set the minimum to 32 and the max to 512. Would that suffice? After all, if we're using it as a compiler, the memory is important. If we're testing compilations, the GPU may need it more.
I guess you're referring to cma_lwm and friends. Those options are no longer supported in newer firmware versions (and I doubt ever worked with upstream Linux).
I think the only good solution I would have is to set it to 32MB as default and then have the downstream video decoding drivers' rpm change gpu_ram to 96MB.
Would it be possible to have it to the increased value of at least 128 for GPU with the option to decrease it? I'm working on a few game emulators and forcing it off at 96 is a bit low for even only having 1GB of shared memory. I mean, if the initramfs isn't built into the kernel, I could just build another easily, but if it is, compiling the whole kernel just to change that one value seems like overkill.
Anyway, it's your fix, just so as you like I suppose.
Can you please explain why you need more GPU RAM?
With vc4 - which is the preferred option to do 3d these days - you don't need GPU RAM, as that is only needed for the old GLES stack.
I only know of 2 situations where we may need more GPU RAM:
* Video decoding (not working upstream atm FWIW)
* Camera support (in staging upstream)
To change the GPU RAM size all you need to do is flip a variable in /boot/efi/config.txt - no need to recompile anything.
Well, I'm not 100% certain of whether it will be a problem, but OpenGL may need it for textures and for anything vc4 can't do properly. And, if video decoding is to be fixed, we need to not have memory as a road block.
And changing the available memory isn't as simple as just changing the setting if the initramfs file is set to use all available system memory.
But I'm new to compiling for aarch64, so I don't fully understand the partitioning of the memory.
(In reply to Erick Couts II from comment #13)
> And changing the available memory isn't as simple as just changing the
> setting if the initramfs file is set to use all available system memory.
Erick, I don't understand what you keep saying about initramfs here. The default kernel command line is stored in the GRUB config file, and config.txt is not part of the initrd either. What do you think needs changes in the initrd?
Isn't the reason that we had to reduce the GPU memory size because initramfs was trying to use 32Mb more than it had available due to the GPU memory setting being 128M? So, if the initramfs is still to be set to the maximum available memory size at the time, and we take system memory to use for the GPU, initramfs will fail to load into the available memory.
(In reply to Erick Couts II from comment #15)
> Isn't the reason that we had to reduce the GPU memory size because initramfs
> was trying to use 32Mb more than it had available due to the GPU memory
> setting being 128M?
The size of the initrd only really depends on its contents. The config.txt setting determines how much free memory there is overall, and the cma= argument determines how much contiguous memory to reserve for vc4 and other drivers.
It is fixed in latest images version. We just need to wait for publishing.
Then, it can be set to 'resolved'.
Latest published image (openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64-2018.04.30-Build2.8.raw.xz) which is Tumbleweed 20180502 does boot properly. So, I close this bug.