Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Duplicate
-
10.4.24
-
Ubuntu 20.04 aarch64
Description
On a clean install of an AWS m6gd instance, the systemd unit file appears to be missing.
I installed MariaDB 10.4.24 from an apt mirror as below:
deb [arch=ppc64el,amd64,s390x,arm64] https://mirrors.xtom.nl/mariadb/repo/10.4/ubuntu focal main
|
# deb-src [arch=ppc64el,amd64,s390x,arm64] https://mirrors.xtom.nl/mariadb/repo/10.4/ubuntu focal main
|
Then installed with:
apt install mariadb-server-10.4
|
After install, unable to start the service:
root@es6:~# systemctl start mariadb
|
Failed to start mariadb.service: Unit mariadb.service not found.
|
Inspecting, it seems like the service file is missing from /lib/systemd:
root@es6:~# ls -al /lib/systemd/system/mariadb.service
|
ls: cannot access '/lib/systemd/system/mariadb.service': No such file or directory
|
After copying the Unit file from another x86 server, it works as expected. Maybe something went wrong with the packaging and this file wasn't packaged for some reason?
Attachments
Issue Links
- duplicates
-
-
- Closed
-
Activity
Sorry mattjones, the explanation in MDEV-28259 shows what happened, and how the prevention of such re-occurrence is being addressed.
|
mariadbd library dependencies (also ubuntu focal based using same package) |
$ podman run --arch arm64 --rm -ti mariadb:10.4 bash
|
Resolved "mariadb" as an alias (/home/dan/.cache/containers/short-name-aliases.conf)
|
Trying to pull docker.io/library/mariadb:10.4...
|
Getting image source signatures
|
Copying blob 577a3a6d8179 skipped: already exists
|
Copying blob 14aeff3983d3 skipped: already exists
|
Copying blob b15d2eb0ba12 skipped: already exists
|
Copying blob 4d8127165a08 skipped: already exists
|
Copying blob e13bb612b014 skipped: already exists
|
Copying blob 550f67acd5c5 skipped: already exists
|
Copying blob 185e8a4c1005 skipped: already exists
|
Copying blob fae937f7cdd6 done
|
Copying blob d0739a94b8e3 done
|
Copying blob def5e5f2644d done
|
Copying blob 06b489aa0ef8 done
|
Copying blob ea5445c5978d done
|
Copying config 8a800c9137 done
|
Writing manifest to image destination
|
Storing signatures
|
root@15dec227c44e:/# ldd /usr/bin/mariadbd-
|
mariadbd-multi mariadbd-safe mariadbd-safe-helper
|
root@15dec227c44e:/# ldd /usr/sbin/mariadbd
|
libpcre.so.3 => /lib/aarch64-linux-gnu/libpcre.so.3 (0x00000055036ad000)
|
libcrypt.so.1 => /lib/aarch64-linux-gnu/libcrypt.so.1 (0x0000005503721000)
|
liblz4.so.1 => /lib/aarch64-linux-gnu/liblz4.so.1 (0x000000550376a000)
|
libaio.so.1 => /lib/aarch64-linux-gnu/libaio.so.1 (0x0000005503798000)
|
libsystemd.so.0 => /lib/aarch64-linux-gnu/libsystemd.so.0 (0x00000055037ab000)
|
libz.so.1 => /lib/aarch64-linux-gnu/libz.so.1 (0x0000005503867000)
|
libssl.so.1.1 => /lib/aarch64-linux-gnu/libssl.so.1.1 (0x0000005503891000)
|
libcrypto.so.1.1 => /lib/aarch64-linux-gnu/libcrypto.so.1.1 (0x000000550392d000)
|
libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000005503bbb000)
|
libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000005503beb000)
|
libstdc++.so.6 => /lib/aarch64-linux-gnu/libstdc++.so.6 (0x0000005503bff000)
|
libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000005503de4000)
|
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000005503e8e000)
|
/lib/ld-linux-aarch64.so.1 (0x0000005500000000)
|
librt.so.1 => /lib/aarch64-linux-gnu/librt.so.1 (0x0000005504003000)
|
liblzma.so.5 => /lib/aarch64-linux-gnu/liblzma.so.5 (0x000000550401b000)
|
libgcrypt.so.20 => /lib/aarch64-linux-gnu/libgcrypt.so.20 (0x000000550404f000)
|
libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1 (0x000000550411b000)
|
libgpg-error.so.0 => /lib/aarch64-linux-gnu/libgpg-error.so.0 (0x000000550413f000)
|
Thankfully the libsystemd.so was still linked into the executable to co-operate with the Type=notify service that you copied.
Coincidentally, it had just been filed as
MDEV-28259.Yes, to my understanding things went wrong with ARM packaging in the last release set.