search

debian-pi / raspbian-ua-netinst

Raspbian (minimal) unattended netinstaller
Other
1.17k stars 153 forks source link

raspberrypi.org software sometimes breaks raspbian.org software (was: mpd does not work) #529

Closed oupala closed 3 years ago

oupala commented 3 years ago

After installing debian/raspbian using your image, mpd cannot start because of the following error message:

$ mpd mpd: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libavcodec.so.58: undefined symbol: vcsm_init_ex

And some more debug tests:

$ vcgencmd VCHI initialization failed $ cgencmd version VCHI initialization failed

Installing rpi-update and updating the firmware fixes the problem.

I know I found a workaround, but I think mpd should be able to work out of the box without requiring to update the firmware. Don't you think?

I'm not sure who is responsible for choosing the right kernel and the right firmware. Could you please help me triaging this issue?

I'm using raspbian-ua-netinst v1.1.5 on a raspberry pi 1.

diederikdehaas commented 3 years ago

Did you use a installer-config.txt file, iow did you customize the installation? If so, can you share it?
Any other customizations you did before you tried to run mpd?

oupala commented 3 years ago

I had no customization when intalling the system on my raspberry pi. It is the default install.

I am then installing some stuff using ansible (including mpd) but nothing that should be involved in sound management.

diederikdehaas commented 3 years ago

Did you enable sound with the solution you posted here?

I think it's useful if you could share the programs you installed via ansible. But I'm pretty sure I've already found the problem:

# apt-cache policy libavcodec58
libavcodec58:
  Installed: (none)
  Candidate: 7:4.1.6-1~deb10u1+rpt1
  Version table:
     7:4.1.6-1~deb10u1+rpt1 990
        990 http://archive.raspberrypi.org/debian buster/main armhf Packages
     7:4.1.6-1~deb10u1 990
        990 http://mirrordirector.raspbian.org/raspbian buster/main armhf Packages

So it looks like it'll install the package from raspberrypi.org (RPF) instead of raspbian.org, and that is causing the problem.

The first result when searching for undefined symbol: vcsm_init_ex lead me to https://github.com/raspberrypi/userland/blob/master/host_applications/linux/libs/sm/user-vcsm.c

The problem may not be specifically in libavcodec58, but in one of the libraries/programs that got installed from the RPF repo. If you disable the RPF repo or via apt preferences (I think) ensure that packages get only installed from raspbian.org, then the problem likely doesn't manifest itself

diederikdehaas commented 3 years ago

I disabled the RPF repo and installed mpd and added dtparam=audio=on to /boot/config.txt and after a reboot, got this:

$ systemctl status mpd.service
● mpd.service - Music Player Daemon
   Loaded: loaded (/lib/systemd/system/mpd.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2021-04-22 19:40:53 CEST; 19s ago
     Docs: man:mpd(1)
           man:mpd.conf(5)
           file:///usr/share/doc/mpd/user-manual.html
 Main PID: 330 (mpd)
    Tasks: 3 (limit: 981)
   CGroup: /system.slice/mpd.service
           └─330 /usr/bin/mpd --no-daemon
$ mpd
exception: Failed to open '/etc/mpd.conf': Permission denied

I executed the commands as me, so the exception sounds normal to me. But I didn't get the symbol lookup error error, which should've occurred before the 'Permission denied' error.

oupala commented 3 years ago

Yes @diederikdehaas, you're right, I also enabled the soundcard using the solution that you linked previously.

I have the same result as you with the apt cache command.

Can you please explain me what is the RPF repo, and what are the consequences of disabling it?

We could also try to fix the bug in the package from the RPF repo.

And you're right again, the Permission denied error is perfectly normal if you launch mpd as a normal user.

oupala commented 3 years ago

As I can read on this thread, the RPF repo is the repo that contains packages specific to raspberry pi:

7:4.1.6-1~deb10u1+rpt1 990 990 http://archive.raspberrypi.org/debian buster/main armhf Packages

While the other repository - raspbian - is just a clone to the debian repository, where each package is recompiled for raspberry pi:

7:4.1.6-1~deb10u1 990 990 http://mirrordirector.raspbian.org/raspbian buster/main armhf Packages

But why does libavcodec58 exist in both repositories?

diederikdehaas commented 3 years ago

Can you please explain me what is the RPF repo,

As you said in your last reply, the raspbian repo consists of Debian packages, but then only recompiled to take advantage of the (HW) features the RPi (1) does have. The RPi1 is HW wise between Debian's armel and armhf. Only in exceptional cases is something changed on the source or the package (to make it work/compile). You then often see the suffix +rptN.
Most packages on a raspbian or *RaspiOS* system are from the raspbian* repo (maybe RPF now mirrors it too, not sure).

Sometimes RPF makes more significant changes. The most clear example is the kernel. But audio/video (think kodi) related packages are also modified to make better use of the RPi HW features (I presume) or to fit (better) in RaspiOS. Ideally, those changes get upstreamed to the original source, so anyone can benefit. (This is not always applicable though) But (imo) that too often doesn't happen :-/ The RPF people seem to think only of people using all their software and not the wider world/free software eco-system. In any case, when the RPF people change the software, like libavcodec58, they then build a .deb package from it and host it in their repo. That's why certain packages exist in both repos. In raspbian just like in Debian (but recompiled) and in RPF repo with the more extensive changes. (I don't know what they are and don't care, but the sources should be available so one could find out what the changes are)

We could also try to fix the bug in the package from the RPF repo.

I doubt the RPF people consider it a bug, as it works when you use (all) their software as you noticed in your workaround. See also what I wrote above.

and what are the consequences of disabling it?

I think the vcgencmd program (and related ones), only exist in the RPF repo (from the userland repo I linked above IIRC). So if that repo gets disabled, a few programs can no longer be installed.

I'm seriously considering of indeed disabling that repo though. An alternative is changing the priority with pinning. I'm quite sure I have looked at that, but it's been such a long time that I don't recall why it isn't/wasn't working. My view of RPF has changed (for the worse) over time. While I previously probably didn't see any harm in the RPF things/repo, I now do. People would still have the option of adding it themselves (in post-install.txt f.e.), but no longer OOTB.

) The RPF people have finally changed their OS name to RaspiOS. Everything was called raspbian and that's very confusing. And IIRC that also made the pinning soo much harder. Normally you differentiate between repo's based on origin*

$ apt-cache policy
Package files:
 100 /var/lib/dpkg/status
     release a=now
 990 http://archive.raspberrypi.org/debian buster/main armhf Packages
     release o=Raspberry Pi Foundation,a=testing,n=buster,l=Raspberry Pi Foundation,c=main,b=armhf
     origin archive.raspberrypi.org
 990 http://mirrordirector.raspbian.org/raspbian buster/firmware armhf Packages
     release o=Raspbian,a=stable,n=buster,l=Raspbian,c=firmware,b=armhf
     origin mirrordirector.raspbian.org
...

And it looks like they have (finally) changed that (the o= field above)

oupala commented 3 years ago

OK, thank you for this complete update of the differences between both repos. That's much more complicated that I was expected it to be. The question is also much more wider than libavcodec.

If you want to remove one repo from the default install, I am willing to make some test with you if you want to.

In the meantime, I will configure pinning to use the right libavcodec package.

diederikdehaas commented 3 years ago

Looking at https://wiki.debian.org/AptConfiguration#Prevent.2Fselective_installation_from_third-party_a_repository, it appears that things have changed for the better since the Jessie days :-) That the origin field has changed as well, should make it much more feasible and easier to accomplish.

But I've tried experimenting a bit, but without success :-/ For some reason the priority is 990 for all, which means that other fields are then the qualifiers ...

Ahh ... it looks like setting APT::Default-Release "buster"; (in /etc/apt/apt.conf.d/40default-release, which I set in my post-install.txt) is responsible for that ...

Having /etc/apt/preferences.d/01raspberrypi.pref with the following contents:

Package: *
Pin: origin "archive.raspberrypi.org"
Pin-Priority: 101

and unsetting APT::Default-Release gives what I want \o/ Pin-Priority 101 is what I use for experimental (on Debian), so it doesn't install from that unless I explicitly say so, but if a package is installed from that, it will upgrade from that ('automatically')

# apt-cache policy
Package files:
 100 /var/lib/dpkg/status
     release a=now
 101 http://archive.raspberrypi.org/debian buster/main armhf Packages
     release o=Raspberry Pi Foundation,a=testing,n=buster,l=Raspberry Pi Foundation,c=main,b=armhf
     origin archive.raspberrypi.org
 500 http://mirrordirector.raspbian.org/raspbian buster/firmware armhf Packages
     release o=Raspbian,a=stable,n=buster,l=Raspbian,c=firmware,b=armhf
     origin mirrordirector.raspbian.org
 500 http://mirrordirector.raspbian.org/raspbian buster/non-free armhf Packages
     release o=Raspbian,a=stable,n=buster,l=Raspbian,c=non-free,b=armhf
     origin mirrordirector.raspbian.org
 500 http://mirrordirector.raspbian.org/raspbian buster/contrib armhf Packages
     release o=Raspbian,a=stable,n=buster,l=Raspbian,c=contrib,b=armhf
     origin mirrordirector.raspbian.org
 500 http://mirrordirector.raspbian.org/raspbian buster/main armhf Packages
     release o=Raspbian,a=stable,n=buster,l=Raspbian,c=main,b=armhf
     origin mirrordirector.raspbian.org
Pinned packages:
     libraspberrypi-bin -> 1.20180328-1~nokernel1 with priority 800
     libraspberrypi-dev -> 1.20180328-1~nokernel1 with priority 800
     libraspberrypi-doc -> 1.20180328-1~nokernel1 with priority 800
     libraspberrypi0 -> 1.20180328-1~nokernel1 with priority 800
# apt-cache policy libavcodec58
libavcodec58:
  Installed: 7:4.1.6-1~deb10u1
  Candidate: 7:4.1.6-1~deb10u1
  Version table:
     7:4.1.6-1~deb10u1+rpt1 101
        101 http://archive.raspberrypi.org/debian buster/main armhf Packages
 *** 7:4.1.6-1~deb10u1 500
        500 http://mirrordirector.raspbian.org/raspbian buster/main armhf Packages
        100 /var/lib/dpkg/status
diederikdehaas commented 3 years ago

Hmm, maybe the RPF repos can be disabled:

# dpkg -S $(which vcgencmd)
libraspberrypi-bin: /usr/bin/vcgencmd
# apt-cache policy libraspberrypi-bin
libraspberrypi-bin:
  Installed: 1.20180328-1~nokernel1
  Candidate: 1.20180328-1~nokernel1
  Version table:
     1.20210303-1 101
        101 http://archive.raspberrypi.org/debian buster/main armhf Packages
 *** 1.20180328-1~nokernel1 800
        500 http://mirrordirector.raspbian.org/raspbian buster/firmware armhf Packages
        100 /var/lib/dpkg/status

The 'only', but still major, problem is that it would be considered a major change, which likely means a major upgrade version is needed. :thinking:

diederikdehaas commented 3 years ago

I am willing to make some test with you if you want to.

You can quite easily test this, because the functionality for it is already build into the installer. When you write the installer to a SD card, you have a config/apt/ directory, which already contains the 01vcgencmd.pref file. If you create (there) a 01raspberrypi.pref with the following contents:

Package: *
Pin: origin "archive.raspberrypi.org"
Pin-Priority: 101

(This is exactly the same as I posted earlier) then it will only install from raspbian.org repo, UNLESS you take specific actions to force a package from the RPF repo or you install a package that isn't available in raspbian.org (but only in the RPF repo).

oupala commented 3 years ago

I tried your solution and it is indeed fixing the problem with mpd.

Should we adopt this solution for the whole installer?

then it will only install from raspbian.org repo, UNLESS you take specific actions to force a package from the RPF repo or you install a package that isn't available in raspbian.org (but only in the RPF repo).

... seems to be reasonable!

diederikdehaas commented 3 years ago

Should we adopt this solution for the whole installer?

Yeah, but I dunno yet what the best way to do it is and whether it should be part of a next major (?) release

oupala commented 3 years ago

A minor release (1.2) would be sufficient in my opinion.

Anyway, there should be some doc to explain all that you explained in this issue, between RPF and raspbian repo, and their respective priority.

diederikdehaas commented 3 years ago

Yeah, I'm warming up to the idea for a minor release because fixing this issue didn't need any code change, just a config change. And that functionality has been deliberately part of this installer for a while. And the 'old' behavior can be reinstated by just adding back those config files.

Documentation could indeed be improved/extended.

oupala commented 3 years ago

I would advise you to release a new version of the installer before the release of the next debian bullseye release.

A new debian release is indeed sometimes the opportunity to reinstall the system. It would be cool to reinstall the system with a correct configuration of the remote repo.

diederikdehaas commented 3 years ago

I have various changes in mind and I'm thinking about the best way to go about that. And a/the next major version is planned for Bullseye, which will be a major change (but don't want to reveal that just yet).

oupala commented 3 years ago

Are you only planning to release a major version for bullseye?

Or will you also release a minor version in the next days?

diederikdehaas commented 3 years ago

I don't know. I think there will be a minor version first, but I don't know when. It isn't a high priority for me now and there's already a fix available, just not OOTB.

oupala commented 3 years ago

Hi @diederikdehaas,

Does raspbian-ua-netinst v1.1.6 include the fix of this issue?

diederikdehaas commented 3 years ago

No. I'm working on that now and that will be for a v1.2.x release

diederikdehaas commented 3 years ago

@oupala If you're willing and capable to create the installer yourself (from source), then I can push a custom branch on my personal clone/fork for you (soon).
I have updated update.sh and build.sh and am testing that now. Then I'd only have to change scripts/etc/init.d/rcS, which likely shouldn't take long.

Let me know what you want.

diederikdehaas commented 3 years ago

I haven't verified it yet, but I've uploaded the branch/fix here: https://github.com/diederikdehaas/raspbian-ua-netinst/tree/fix529-for-oupala

oupala commented 3 years ago

I'm not sure about what you want me to test:

diederikdehaas commented 3 years ago

Sorry, I must've misunderstood.
Anyway, I've committed a fix for this issue in my local repo and it should become part of a/the next minor/major release.

diederikdehaas commented 3 years ago

Apparently I used a word too much in https://github.com/debian-pi/raspbian-ua-netinst/commit/fced92f239778269621642ee98a3df0317cec79e for it to automatically close, but this issue is fixed (in both v1.2.x as master branch).