radxa / apt

radxa debian packages repository
http://radxa.com/Rabian
35 stars 6 forks source link

Bullseye release missing libmraa - Hat install script fails looking for libmraa #39

Open stormarcher3 opened 2 years ago

stormarcher3 commented 2 years ago

Hi -

I've tried reporting this in several ways, but have not had a reply. The buster releases have the libmraa in the package and the install script worked (previously). I have a rockpi 4c and was successfully running dietpi and a penta hat. When I ran updates to the OS, an upgrade to bullseye was applied. This crashed my OS. Based on the problems I've been experiencing trying to reinstall, the lack of libmraa library in the Bullseye-stable, bullseye-testing releases is likely the problem.

In the reinstall, I have installed my original DietPI buster OS. The first boot process immediately upgrades the system to Bullseye. The penta-hat install script fails looking for libmraa. I can reconfigure my raid array, but the top hat and fan won't operate leaving the system to overheat. I'm now left with an unusable system waiting for a working script for Bullseye.

Any chance this can be added? Thank you, Storm

akgnah commented 2 years ago

DietPi has not been tested, so there may be a problem with the installation script. It looks like the package name has changed, I will test it and get back to you.

MichaIng commented 2 years ago

When I ran updates to the OS, an upgrade to bullseye was applied.

You mean you did the upgrade to Bullseye manually? This is never done automatically. Revert the /etc/apt/sources.list.d/radxa.list list to use "buster", since the "bullseye" repo is nearly empty:

There are no issues known with the Radxa Buster repo on Debian Bullseye.

stormarcher3 commented 2 years ago

Michalng -

I flashed my emmc with dietpi buster. On first boot, it apparently does an automatic upgrade to bullseye.,

In my testing, I stopped the first boot auto-update process and ran the penta-hat script. Since it was still buster, it used the correct repo and installed the drivers and everything worked, until I tried to do the update upgrade again. Updates would not work.

I tried using the buster report on a clean bullseye install. That generated errors missing prerequisites.

I tried other distros. I was able to get Ubuntu to see everything without issues, but Open Media Vault only supports debian.

Thank you for the help! Storm

MichaIng commented 2 years ago

I flashed my emmc with dietpi buster.

We do not host any Buster images. If this was really one, where did you get it from?

On first boot, it apparently does an automatic upgrade to bullseye.,

How do you know this? Can you share logs or console output about that? There is no code or mechanism in official DietPi which would perform a distribution upgrade in any case. Package upgrades and a dist-upgrade are performed, but without touching the sources.list files, i.e. whatever Debian version it was, remains.

Since it was still buster, it used the correct repo and installed the drivers and everything worked

I don't know this script, but I hope it does not get the distro version from radxa.list, since, as explained, (on our current ROCK Pi 4 and Radxa Zero images) this still points to Buster, while the main Debian lists all point to Bullseye, including the /etc/os-release and /etc/debian_version base files.

until I tried to do the update upgrade again

Either the script does not detect the Debian version correctly then, or it is not Bullseye itself but a particular package upgrade which causes an incompatibility. But to know this better, please point me to the scripts source code and paste its output here.

I tried using the buster report on a clean bullseye install. That generated errors missing prerequisites.

You mean the Radxa Buster repo on a Debian Bullseye image, just the way our ROCK Pi 4 (Bullseye) image is currently shipped? Then the script is not compatible with Bullseye yet. Note that Radxa does not provide Debian Bullseye images yet, hence the WIP Radxa Bullseye repo and that may be the reason why this script does not work on Bullseye either. But it may be easy to make it compatible by updating the dependencies.

I tried other distros. I was able to get Ubuntu to see everything without issues

Makes sense that it works with the Debian and Ubuntu versions Radxa ships, but not necessarily with newer distro versions. A little wink at this point since the Debian Bullseye feature freeze was more than a year ago 😉.

stormarcher3 commented 2 years ago

Hi -

Radxa has images and links to third party ones: https://wiki.radxa.com/Rockpi4/downloads. I've tried these, but had issues. Plus I don't need a big installation with a desktop. I have tried my older buster download and the newer bullseye download. Both have issues as buster upgrades to bullseye.

I can re-run the process and take screenshots. But after the first logon, if I don't cancel, it downloads and installs. It's also stated in the install documentation: https://dietpi.com/docs/install/

If I use the dietpi buster image and cancel the initial first run upgrade I can run curl -sL https://rock.sh/get-rockpi-penta | sudo -E bash - since it's still buster. it works buts breaks the first run process and apt-get update || apt-get upgrade processes with strange errors.

The dietpi buster I started with last year was flawless until the bullseye release.

I was not successful with the radxa debian version. Ubuntu yes, but I need debian for Open Media Vault (OMV). Having a lighter weight distro is preferred since this unit will primarily be headless.

The nas unit I'm using I bought from allchina.net. Nice unit, but to get to the emmc you have to disassemble the entire unit. after a dozen iterations of os flash and troubleshoot, I put the buster back on and reassembled. I can go through it again to grab screen shots and to show what the script is putting in if needed.

Hopefully you can test and see what I'm seeing.

Thanks you again for the assistance! Storm

MichaIng commented 2 years ago

I can re-run the process and take screenshots.

Please do so. The documentation states that "DietPi" is updated to the latest version, but not the underlying "Debian". To verify which Debian version it really is, run the following command:

cat /etc/os-release

The dietpi buster I started with last year was flawless until the bullseye release.

Again, there is no distro upgrade performed automatically, so then it must be a package upgrade on Buster.

Easiest, as always, is if you provide the logs/outputs of the script when running into the error 😉.

MichaIng commented 2 years ago

Found it for our current Bullseye image: We use the Armbian kernel for our ROCK Pi 4 Bullseye image in the meantime, since the old Radxa kernel causes more and more issues with Bullseye userland software. But we do not use the Armbian system overlay package, hence /etc/armbian-release does not exist so that the installer assumes it is a Radxa Debian image.

Please run this script on our current Bullseye image: https://cos.setf.me/rockpi/sh/penta-sata/armbian.sh

But no idea why it would fail on the old Buster image, even after upgrading to Bullseye (when done manually but without touching radxa.list) => logs/output required.

@akgnah The script could be changed to check for /boot/armbianEnv.txt instead of /etc/armbian-release for deciding whether to pull the Armbian installer or Debian installer. The first is required anyway as it is the one where the device tree overlay is added to. To include DietPi support for possibly newer images, /boot/dietpiEnv.txt could be checked for and edited the same way as /boot/armbianEnv.txt is. Like:

  if [ -f /boot/armbianEnv.txt ] || [ -f /boot/dietpiEnv.txt ]; then
    curl -sL $ARMBIAN_URL | sudo -E bash -

And in armbian.sh

ENV='/boot/armbianEnv.txt'
[ -f /boot/dietpiEnv.txt ] && ENV='/boot/dietpiEnv.txt'

...

  if grep -q '^user_overlays=' "$ENV"; then
    line=$(grep '^user_overlays=' "$ENV" | cut -d'=' -f2)
    if grep -qE "(^|[[:space:]])${fname}([[:space:]]|$)" <<< $line; then
      echo "Overlay ${fname} was already added to "$ENV", skipping"
    else
      sed -i -e "/^user_overlays=/ s/$/ ${fname}/" "$ENV"
    fi
  else
    sed -i -e "\$auser_overlays=${fname}" "$ENV"
  fi
stormarcher3 commented 2 years ago

Thank you so much! That worked and the fan/display are working. The cpu is now down into the safe temp range and I can move forward again.

I really appreciate the support! Best Regards, Storm

MichaIng commented 2 years ago

Perfect.

Just for the record: /boot/dietpiEnv.txt does not exist in our current ROCK Pi 4 image, /boot/armbianEnv.txt does instead. But we are gradually migrating all images to be built from scratch with own U-Boot configs and /boot/dietpiEnv.txt as clear identifier, keeping support for overlays= and user_overlays= for whichever kernel is used (it will always be modern/mainline kernel and U-Boot).

stormarcher3 commented 2 years ago

Question and update: I flashed dietpi-buster from last year. After the first boot process, ran the script and it worked. I had trouble installing OMV. Re-read you post and you mentioned bullseye and I re-flashed with the Dietpi bullseye but found I have a radxa dietpi bullseye also.

I'm trying the dietpi bullseye now and have a couple of issues. Which do I need to use? I ask as the dietpi bullseye (non radxa) sort of works. script above shows missing libmraa. The fan works, but the display does not.

I can move the radxa dietpi bullseye next and test. just need to get a good, stable install so I can rebuild my backup nas. Thank you!!

Storm

MichaIng commented 2 years ago

Generally I recommend to use our current Bullseye image, which is using the Armbian kernel, and then https://cos.setf.me/rockpi/sh/penta-sata/armbian.sh.

I see now armbian.sh creates /etc/apt/sources.list.d/apt-radxa-com.list with bullseye in it. This does not work yet, as shown above most packages are missing, so replace it with buster for now, until the Radxa Bullseye repo is really ready. To put it together, this should work on our current Bullseye image as well as on Armbian Bullseye images:

curl -sSfLO 'https://cos.setf.me/rockpi/sh/penta-sata/armbian.sh'
chmod +x armbian.sh
sed -i 's/\$DISTRO/buster/' armbian.sh
./armbian.sh
rm armbian.sh
stormarcher3 commented 2 years ago

I've had trouble making the radxa images work. I flash them to my emmc and the no boot or activity.

I seem to have been able to Install the Dietpi Buster release, do the post install and update. Then fun the new script. The display comes up and fan comes on. I upgraded to bullseye and installed open media vault.

There are 2 problems post upgrade:

  1. my 5th drive plugged into the external sata port is not being seen. It worked last week when I went down the ubuntu trail.
  2. the display no longer rotates between space on root and ip address. As the ip address changes, this function is needed but I can work around for now.

I'll have to try to get things to work tomorrow. Thank you again! Storm

akgnah commented 2 years ago

@MichaIng Thank you so much for your help. I updated the installation script yesterday and it seems to work well in DietPi Buster.

But Bullseye does not have libmraa at present, we are supporting it.

MichaIng commented 2 years ago

Great, many thanks. The probably best workaround for Bullseye currently is to additionally add the Radxa Buster repo before running the script:

curl -sSfL 'https://apt.radxa.com/buster-stable/public.key' | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/radxa-buster.gpg --yes
echo 'deb https://apt.radxa.com/buster-stable/ buster main' | sudo tee /etc/apt/sources.list.d/radxa-buster.list

That way all packages are available but the ones already present on the Bullseye repo are preferred (assuming being newer versions). At least I'm not aware of any dependency issues, like that any of the Radxa Buster packages would depend on an actual Debian Buster repo package, or so.

stormarcher3 commented 2 years ago

Thank you again for the help. After a few iterations, I finally have everything back up and everything working with dietpi bullseye. I'm very appreciative of the support the update the config!

73 commented 2 years ago

Hi,

I came here because I upgraded to armbian bullseye and my hat's fan is running like hell. I tried adding:

echo 'deb https://apt.radxa.com/buster-stable/ buster main' | sudo tee /etc/apt/sources.list.d/radxa-buster.list

but I cannot install libmraa because my repos are missing python 2.7 and 3.7. So I tried to force it like:

apt-get download libmraa
dpkg --force-all -i libmraa_1.6_arm64.deb

However, when I run the scripts: python3 /usr/bin/rockpi-penta/main.py, i get:

Traceback (most recent call last):
  File "/usr/bin/rockpi-penta/main.py", line 3, in <module>
    import fan
  File "/usr/bin/rockpi-penta/fan.py", line 3, in <module>
    import mraa  # pylint: disable=import-error
ModuleNotFoundError: No module named 'mraa'

Is there anything I can do?

MichaIng commented 2 years ago

Oh, I've not seen the explicit Python 2.7 and Python 3.7 dependencies: https://github.com/radxa/apt/blob/15efb9f/buster-stable/dists/buster/main/binary-arm64/Packages#L989

Hmm, I wonder whether/why Python 2 AND Python 3 are required, it works with both individually and does not require both. So the dependency could be python3.x OR python2.y to not force admins to have a Python version installed they do not use. But it makes sense that it depends on specific Python subversions since it's installed into respective directories. Can you try to copy the files into the Python 3.9 dir and test whether it then starts?

cp -a /usr/local/lib/python3.7/dist-packages/*mraa* /usr/local/lib/python3.9/dist-packages/
73 commented 2 years ago

Hi, I tried. It is linked against python3.7.

🠶  python fan.py
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/dist-packages/mraa.py", line 17, in swig_import_helper
    return importlib.import_module(mname)
  File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 666, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 565, in module_from_spec
  File "<frozen importlib._bootstrap_external>", line 1108, in create_module
  File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
ImportError: libpython3.7m.so.1.0: cannot open shared object file: No such file or directory

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/rockpi-penta/fan.py", line 3, in <module>
    import mraa  # pylint: disable=import-error
  File "/usr/local/lib/python3.9/dist-packages/mraa.py", line 20, in <module>
    _mraa = swig_import_helper()
  File "/usr/local/lib/python3.9/dist-packages/mraa.py", line 19, in swig_import_helper
    return importlib.import_module('_mraa')
  File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
ImportError: libpython3.7m.so.1.0: cannot open shared object file: No such file or directory

Is that package just a compiled version of this fork? Would compiling it myself work?

MichaIng commented 2 years ago

ImportError: libpython3.7m.so.1.0: cannot open shared object file: No such file or directory

It seems that indeed it internally looks for Python 3.7 explicitly. Compiling it yourself with python3-dev installed may work.