Mariadb only starts when using systemd

[theber]

I did a new, fresh install of MX-23.1. At first I was able to start mariadb using the command

Code: Select all

sudo mysql

I then ran

Code: Select all

sudo mysql_secure_installation

so that I could start mariadb as a normal user, with a password. So far, so good.
Next I set up my fstab file to bind mount my sql partition at boot. (I use different distros on this machine, and bind-mounting allows each distro to access the same databases.) After this step mariadb would not start. I checked the usual suspects like setting correct permissions, but to no avail.
Then I found a tip on this forum about booting using systemd. When I tried this, mariadb started right away.

My question: do I always have to use systemd to be able to start mariadb?

Code: Select all

System:
  Kernel: 6.1.0-13-amd64 [6.1.55-1] arch: x86_64 bits: 64 compiler: gcc v: 12.2.0
    parameters: BOOT_IMAGE=/boot/vmlinuz-6.1.0-13-amd64 root=UUID=<filter> ro quiet splash
    init=/lib/systemd/systemd
  Desktop: KDE Plasma v: 5.27.5 wm: kwin_x11 vt: 7 dm: SDDM Distro: MX-23.1_KDE_x64 Libretto
    October 15 2023 base: Debian GNU/Linux 12 (bookworm)
Machine:
  Type: Laptop System: FUJITSU product: LIFEBOOK E782 v: 10601581569 serial: <superuser required>
    Chassis: type: 10 v: LIFEBOOK E782 serial: <superuser required>
  Mobo: FUJITSU model: FJNB253 v: L3 serial: <superuser required>
    UEFI-[Legacy]: FUJITSU // Phoenix v: Version 2.17 date: 03/08/2018
Battery:
  ID-1: CMB1 charge: 35.4 Wh (63.0%) condition: 56.2/56.2 Wh (100.0%) volts: 11.2 min: 10.8
    model: Fujitsu CP345713 type: Li-ion serial: <filter> status: discharging
  Device-1: hidpp_battery_0 model: Logitech M720 Triathlon Multi-Device Mouse serial: <filter>
    charge: 55% (should be ignored) rechargeable: yes status: discharging
CPU:
  Info: model: Intel Core i5-3210M bits: 64 type: MT MCP arch: Ivy Bridge gen: core 3 level: v2
    built: 2012-15 process: Intel 22nm family: 6 model-id: 0x3A (58) stepping: 9 microcode: 0x21
  Topology: cpus: 1x cores: 2 tpc: 2 threads: 4 smt: enabled cache: L1: 128 KiB
    desc: d-2x32 KiB; i-2x32 KiB L2: 512 KiB desc: 2x256 KiB L3: 3 MiB desc: 1x3 MiB
  Speed (MHz): avg: 1245 high: 1332 min/max: 1200/3100 scaling: driver: intel_cpufreq
    governor: ondemand cores: 1: 1213 2: 1200 3: 1332 4: 1235 bogomips: 19956
  Flags: avx ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
  Vulnerabilities:
  Type: gather_data_sampling status: Not affected
  Type: itlb_multihit status: KVM: VMX disabled
  Type: l1tf mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable
  Type: mds mitigation: Clear CPU buffers; SMT vulnerable
  Type: meltdown mitigation: PTI
  Type: mmio_stale_data status: Unknown: No mitigations
  Type: retbleed status: Not affected
  Type: spec_rstack_overflow status: Not affected
  Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via prctl
  Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization
  Type: spectre_v2 mitigation: Retpolines, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB
    filling, PBRSB-eIBRS: Not affected
  Type: srbds status: Vulnerable: No microcode
  Type: tsx_async_abort status: Not affected
Graphics:
  Device-1: Intel 3rd Gen Core processor Graphics vendor: Fujitsu . LIFEBOOK E752 driver: i915
    v: kernel arch: Gen-7 process: Intel 22nm built: 2012-13 ports: active: LVDS-1 empty: DP-1,
    DP-2, DP-3, HDMI-A-1, HDMI-A-2, HDMI-A-3, VGA-1 bus-ID: 00:02.0 chip-ID: 8086:0166
    class-ID: 0300
  Device-2: Chicony FJ Camera type: USB driver: uvcvideo bus-ID: 1-1.6:7 chip-ID: 04f2:b2fc
    class-ID: 0e02
  Display: x11 server: X.Org v: 1.21.1.7 with: Xwayland v: 22.1.9 compositor: kwin_x11 driver: X:
    loaded: modesetting unloaded: fbdev,vesa dri: crocus gpu: i915 display-ID: :0 screens: 1
  Screen-1: 0 s-res: 1600x900 s-dpi: 96 s-size: 423x238mm (16.65x9.37") s-diag: 485mm (19.11")
  Monitor-1: LVDS-1 model: Lenovo 0x40b1 built: 2009 res: 1600x900 hz: 60 dpi: 118 gamma: 1.2
    size: 345x194mm (13.58x7.64") diag: 396mm (15.6") ratio: 16:9 modes: 1600x900
  API: OpenGL v: 4.2 Mesa 23.1.2-1~mx23ahs renderer: Mesa Intel HD Graphics 4000 (IVB GT2)
    direct-render: Yes
Audio:
  Device-1: Intel 7 Series/C216 Family High Definition Audio vendor: Fujitsu . LIFEBOOK E752
    driver: snd_hda_intel v: kernel bus-ID: 00:1b.0 chip-ID: 8086:1e20 class-ID: 0403
  API: ALSA v: k6.1.0-13-amd64 status: kernel-api tools: alsamixer,amixer
  Server-1: PipeWire v: 0.3.65 status: active with: 1: pipewire-pulse status: active
    2: wireplumber status: active 3: pipewire-alsa type: plugin 4: pw-jack type: plugin
    tools: pactl,pw-cat,pw-cli,wpctl
Network:
  Device-1: Intel 82579LM Gigabit Network vendor: Fujitsu driver: e1000e v: kernel port: 4080
    bus-ID: 00:19.0 chip-ID: 8086:1502 class-ID: 0200
  IF: eth0 state: down mac: <filter>
  Device-2: Ralink RT5372 Wireless Adapter type: USB driver: rt2800usb bus-ID: 1-1.2:3
    chip-ID: 148f:5372 class-ID: 0000
  IF: wlan0 state: up mac: <filter>
  Device-3: Sierra Wireless MC8305 Modem type: USB driver: qcserial,qmi_wwan bus-ID: 1-1.5:6
    chip-ID: 1199:9011 class-ID: 0000
  IF: wwan0 state: down mac: N/A
Bluetooth:
  Device-1: Foxconn / Hon Hai BCM20702A0 type: USB driver: btusb v: 0.8 bus-ID: 1-1.3:4
    chip-ID: 0489:e052 class-ID: fe01 serial: <filter>
  Report: hciconfig ID: hci0 rfk-id: 0 state: up address: <filter> bt-v: 2.1 lmp-v: 4.0
    sub-v: 220e hci-v: 4.0 rev: 1000
  Info: acl-mtu: 1021:8 sco-mtu: 64:1 link-policy: rswitch sniff link-mode: peripheral accept
    service-classes: rendering, capturing, object transfer, audio, telephony
Drives:
  Local Storage: total: 931.51 GiB used: 71.05 GiB (7.6%)
  SMART Message: Unable to run smartctl. Root privileges required.
  ID-1: /dev/sda maj-min: 8:0 vendor: Samsung model: SSD 860 EVO 1TB size: 931.51 GiB block-size:
    physical: 512 B logical: 512 B speed: 6.0 Gb/s type: SSD serial: <filter> rev: 4B6Q scheme: MBR
Partition:
  ID-1: / raw-size: 76 GiB size: 74.26 GiB (97.71%) used: 12.47 GiB (16.8%) fs: ext4 dev: /dev/sda9
    maj-min: 8:9
Swap:
  Kernel: swappiness: 15 (default 60) cache-pressure: 100 (default)
  ID-1: swap-1 type: partition size: 4 GiB used: 0 KiB (0.0%) priority: -2 dev: /dev/sda8
    maj-min: 8:8
Sensors:
  System Temperatures: cpu: 58.0 C mobo: N/A
  Fan Speeds (RPM): N/A
Repos:
  Packages: pm: dpkg pkgs: 2819 libs: 1660 tools: apt,apt-get,aptitude,nala pm: rpm pkgs: 0
    pm: flatpak pkgs: 0
  No active apt repos in: /etc/apt/sources.list
  Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list
    1: deb http://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware
  Active apt repos in: /etc/apt/sources.list.d/debian.list
    1: deb http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware
    2: deb http://security.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware
  Active apt repos in: /etc/apt/sources.list.d/mx.list
    1: deb http://mirror.easyname.ch/mxlinux-packages/mx/repo/ bookworm main non-free
    2: deb http://mirror.easyname.ch/mxlinux-packages/mx/repo/ bookworm ahs
Info:
  Processes: 232 Uptime: 8m wakeups: 850 Memory: 15.47 GiB used: 2.9 GiB (18.8%) Init: systemd
  v: 252 target: graphical (5) default: graphical tool: systemctl Compilers: gcc: 12.2.0 alt: 12
  Client: shell wrapper v: 5.2.15-release inxi: 3.3.26
Boot Mode: BIOS (legacy, CSM, MBR)

[CharlesV]

I use mariadb on SysVinit only and it seems to work just fine. I have never attempted to mount it with fstab though...

[theber]

Thanks for the reply.
It dawned on me that the problem is not with mariadb or SysVinit, but with the bind mount procedure. I seem to remember reading somewhere that performing a bind mount using fstab requires systemd. Or something like that.
I have to do some more homework.

[CharlesV]

Possibly mounting it as a removable media might help ?

[l0dr3]

Thanks for the reply.
It dawned on me that the problem is not with mariadb or SysVinit, but with the bind mount procedure. I seem to remember reading somewhere that performing a bind mount using fstab requires systemd. Or something like that.

Are your other installations on that system also using 'sysVinit'?

The concern is - if your fstab contains systemd-related bind mount statements, like described :here: , then with the default sysVinit powered boot of MX, such fstab-bind-mounts will fail!

kind regards

l0dr3

[theber]

Thanks for the link @l0dr3 . I think you are right.
Indeed all my computers are using distros running systemd. I might try adding a "remount" command to my fstab file, a suggestion that I found online. It will have to wait until next week though. I will report on my progress.