Amiberry wrong version

[symbios24]

Hello Im using dietpi v6 buster fully updated to latest version on an Raspberry Pi 4 and upon install of Amiberry it tries to install the 64bit version of Amiberry and of course it fails since the Dietpi is 32bit

Is this a bug?

Is there a way to fix this?

Before Amiberry v5 was released i had installed v4.1.5 without any problems,i just need it to take the 32bit version: amiberry_rpi4.deb

Thank you

[MichaIng]

You mean DietPi v8.5, don't you?

Can you show the output of the following commands:

echo $G_HW_ARCH
uname -m

[Joulinar]

Im using dietpi v6 buster

Current version of DietPi is v8.5. As well Debian Bullseye is the latest Debian version. Buster is oldstable.

since the Dietpi is 32bit

We offer images for 32bit as well as 64bit 😉

[symbios24]

First command 3 second aarch64 Im using berryboot maybe that is the problem as it has a custom kernel,before i had installed 4.1.5 version without a problem ,is there a way to install the 32bit amiberry to this? Thanks

[MichaIng]

BerryBoot uses the 64-bit kernel but then uses the 32-bit DietPi image? It is anyway a custom/community image, not an official one, AFAIK, right? Maybe you can contact the maintainer to update it, using our ARMv8 RPi image, so kernel and userland architecture match.

Until then, this workaround should do it:

sed -i '/-64-dmx/d' /boot/dietpi/dietpi-software
dietpi-software reinstall 108

[symbios24]

The maintainer never answers there are over 300 issues there unanswered,no support there. I think you guys should take berryboot and improve it, you are more experienced that anyone.will try it tomorrow and let you know

Thanks a lot

[MichaIng]

I think you guys should take berryboot and improve it

The concept itself is partly incompatible with DietPi: Boot/kernel configurations and upgrades, as well as module builds via kernel headers are all not possible with a fixed BerryBoot kernel and config on a dedicated partition. Also I don't see much reason to do multi-boot on a single drive anyway, too simple to switch SD cards/USB drives with a single OS each, respectively using a single Linux distro to run all required applications, in case using containers. You cannot run fundamentally incompatible OSes like Windows or macOS on RPi anyway, which is the only strong reason for multi-boot I can think of.

But probably you have specific reasons for using BerryBoot I was not thinking about?

[symbios24]

I dont mean include it in dietpi i mean as a separate project,it has potential i dont want to use many different cards and to write them/format etc I use raspbian and dietpi mainly to make projects

[Joulinar]

Sorry to say but we don't have the capacity to do so.

[MichaIng]

We barely have the man power to maintain and develop DietPi as fast as we want it, no chance to add another project, especially where the benefit is questionable 😉.

I use raspbian and dietpi mainly to make projects

DietPi and Raspbian are identical from their core, aside of different userland composition and pre-installed tools. You can do everything that you can do on Raspbian (Raspberry Pi OS) on DietPi as well, even all the userland tools (like raspi-config) can be installed. The other way round the DietPi scripts are not available, but main APT repo, kernel, firmware etc are all the same, so even developing is possible on each of them for both of them. So there should be really no point in using both of them concurrently, aside of probably for testing software/development with the default OS setup, but then: BerryBoot is no default OS setup.

The problem as mentioned with BerryBoot is now that all the config files in /boot are not available (many DietPi features are not functional, raspi-config isn't either, all pre-configuration ways don't work on any of them etc), the kernel is outdated, cannot be easily upgraded (at least not from the OSes) and matching kernel headers cannot be installed easily. So you have two somehow crippled distros you cannot fully use to their extend while each of them alone (without BerryBoot) would be much more mighty and functional.

There are also more critical issues, like additional kernel modules cannot be loaded, so a bunch of software cannot really run at all, like Docker, WireGuard etc. At least I remember this was the case, if it hasn't been resolved somehow by mounting the BerryBoot kernel modules into each OS filesystem. I.e. is this even available?

ls -l /lib/modules/$(uname -r)

[symbios24]

The raspi-config works in berryboot I just cant make a newer version its too complicated for me,i know how to compile/build but this is bigger than me,even if a new version is been released every three months will be great,but now last version is a year old and the version for Raspberry pi 2/3 does not work with newest raspberry pi zero2 as much i tried to them for an update,they just didint bother even to say no,it really has potential as the images are squash-fs compressed saving a lot of space and the loading is not slow at all,i found a few bugs over the years of use and new features that probably nobody will implement.anyway its a shame they dont bother its a great project at least for me. Dietpi is massive (needs more games thought) I have my hotspot for years,the Christmas and the easter things you put are awesome. If anyone can do a script to build automatically berryboot will be great or just to update the kernel/modules so we dont need newer version,just update Or having two kernels one 32 and one 64bit to choose from on boot Anyway Continue the good work.

Ps: what happen to ramlog is it working? I dont see it storing any data anymore. Thank you

[symbios24]

[MichaIng]

Okay, then the BerryBoot DietPi images have improved. You got it from here, right? I had a look into the image, and there is no /lib directory, so it looks like /lib/modules is mounted from the actual BerryBoot partition. But /boot/config.txt and /boot/cmdline.txt don't have an actual effect, do they? Or are the actual BerryBoot configs somehow mounted there (while /boot/dietpi obviously is preserved).

Whether disk space is a limiting factor, especially with DietPi, or CPU and RAM I/O (additionally utilised for (de)compression), is a different question. Whenever possible I'd go with a sufficiently large USB drive on RPi.

Interesting is that uname -m now returns armv7l, as it should, while previously it reported aarch64 (which is why the 64-bit Amiberry package was installed)?

Or having two kernels one 32 and one 64bit to choose from on boot

That is btw the same with plain DietPi and Raspberry Pi OS, can be selected via config.txt, but as mentioned before, there is no point to use the 64-bit kernel when the OS userland is 32-bit 😉.

Indeed it's sad that the BerryBoot core is so rarely maintained, last commit is 1 year ago: https://github.com/maxnet/berryboot Kernel so old that RPi Zero 2 W is not supported yet. I also have some minor PRs open at the repo, which didn't receive any reply. At least the custom images are very up-to-date 👍.

[symbios24]

The custom images are updated but it needs the kernel updated also,i get many times misbehavior from the images due to the old kernel i think.the photo was from my raspberry pi 3 thats why you see a armv7 I installed dietpi to my raspberry pi 4 using the command you gave me:sed -i '/-64-dmx/d' /boot/dietpi/dietpi-software

After is finish and i run it manual: systemctl start amiberry i get a blank/black screen and dietpi hangs so i have to remove the power I did a reboot maybe it was needed after install Got the same.i did not have this issue with pre-installed older amiberry 4.1.5.

[MichaIng]

Did you use the fastboot autostart option? If so, could you try to start it manually from console?

systemctl start amiberry

Probably on BerryBoot the fast boot option starts too early.

If possible, please switch to 32-bit kernel, which would solve the kernel vs userland mismatch.

I cannot rule out that the old kernel and/or bootloader are the issue here. Usually those have not much impact on userland programs, but in case of RPi there is the libraspberrypi0 libraries for DispmanX and such, which we use for our Amiberry builds. And probably there have been some updates which depend on a matching kernel and/or bootloader. The libraspberrypi0 package is always released together with kernel and bootloader packages, but on BerryBoot those don't match anymore.

Another thing is that Amiberry requires the fake KMS driver, i.e. dtoverlay=vc4-fkms-v3d in /boot/config.txt, but if those present in the OS are not the effective ones, probably the legacy display driver or full KMS (dtoverlay=vc4-kms-v3d) are used, which doesn't work for Amiberry. This was the same with our previous Amiberry builds, but at least you should have a look into the effective config.txt, which can be done in the BerryBoot boot menu, if I'm not mistaken.

[symbios24]

You are correct the fkms was disabled from the berryboot config i do so many tests and i forgot to enable it,it was not a good day today,i have manage games like urban terror and assault cube to run in the raspberry and stuck on this detail Sorry for asking again is the ramlog working in dietpi coz i dont see it gathering data I boot from a mechanical hard disk its many times faster than the card is thats why it does not gather data? Thanks for your big help

[MichaIng]

@symbios24 Sorry, I missed your post. What do you mean by "gathering data"? You should see log files in /var/log and df /tmp should tell you that this location it's a tmpfs, i.e. a RAM disk. Amiberry however does not log to any file there but to journalctl/journalctl -u amiberry instead, respectively to STDOUT.