#3595 Issue open: no keyboard response at rescue-system login-prompt on MacBookPro¶
Labels: support / question, special hardware or VM,
old version
dasarno opened issue at 2026-03-29 13:18:¶
Requesting support or just a question¶
the rescue-system system is not configured to read the actual keyboard
Platform¶
Linux x64
Additional information¶
I run Debian 13 on a MacbookPro intel from 2015. I am new to rear. I created a rescue-usb-stick with "mkrescue". It will boot up to the login-prompt. But there is no keyboard-response which would allow me to enter a username. There is no light when I try to engage "caps-lock".
from /etc/os-release:
DEBIAN_VERSION_FULL=13.3
output from "rear --version":
Relax-and-Recover 2.7 / Git
I have made the following additions to the rear.local.conf in order to
resolve an earlier problem:
Those additions were meant to fix another problem. The bootup would stop
while trying to establish a serial terminal.
BACKUP=NETFS
BACKUP_URL=usb:///dev/disk/by-label/REAR-000
USB_DEVICE_FILESYSTEM_LABEL=REAR-000
OUTPUT=USB
UDEV_WORKFLOW=mkrescue
SECURE_BOOT_BOOTLOADER=(/boot/efi/EFI/*/shim64.efi)
USE_SERIAL_CONSOLE="no"
KERNEL_CMDLINE="console=tty1 systemd.unit=getty@tty1.service"
MODULES=('all_modules')
gdha commented at 2026-04-01 05:55:¶
You are using a "MacbookPro intel from 2015", but you're using Linux
ARM64? Are you sure?
Perhaps, carefully check the rear.log file for errors when you were
creating the rescue image? It might be there was an issue with keyboard
files? However, not sure how the Mac handles keyboards with Debian.
Perhaps, the applespi driver is missing?
dasarno commented at 2026-04-01 07:51:¶
I took out the "SECURE_BOOT_BOOTLOADER" line.
I took out the "KERNEL_CMDLINE" line.
Is it necesssary to specify a bootloader at all?
Creating the rear rescue system does display a warning or error message:
/usr/lib/x86_64-linux-gnu/systemd/libsystemd-core-257.so requires additional libraries
libsystemd-core-257.so => not found
Test with the new rescue-system:
I pick the very first boot-option after startup (no secure boot).
The process comes to a stop with the message
[DEPEND] Dependencies failed for serial-getty@tty0service - Serial Getty on ttyS0
after a Timeout trying.
dasarno commented at 2026-04-01 07:58:¶
I made a mistake "Linux ARM 64". The debian installers I use refer to intel/amd 64.
gdha commented at 2026-04-01 08:42:¶
Add USE_SERIAL_CONSOLE="no" into the local.conf file.
dasarno commented at 2026-04-01 08:47:¶
That has been in there all along with no effect at all.
gdha commented at 2026-04-01 08:52:¶
Okay, try with the following (in local.conf):
LIBS+=( /usr/lib/x86_64-linux-gnu/lib*.so* /lib64/lib*.so* )
dasarno commented at 2026-04-01 09:27:¶
Ran rear with the LIB+= addition. Previous error ."..257.so" persists.
New samba-related messages show up. From the terminal-output:
/usr/lib/x86_64-linux-gnu/samba/libasn1util-private-samba.so.0 requires additional libraries
libreplace-private-samba.so.0 => not found
libgenrand-private-samba.so.0 => not found
libsamba-debug-private-samba.so.0 => not found
/usr/lib/x86_64-linux-gnu/systemd/libsystemd-core-257.so requires additional libraries
libsystemd-shared-257.so => not found
/usr/lib/libreoffice/program/libuno_cppuhelpergcc3.so.3 requires additional libraries
libreglo.so => not found
libunoidllo.so => not found
libxmlreaderlo.so => not found
ReaR recovery system in '/var/tmp/rear.YVm2767Udl3gh3t/rootfs' needs additional libraries, check /var/log/rear/rear-macinux.log for details
Booting the rescue-system stops with the same error as before.
jsmeix commented at 2026-04-07 13:44:¶
@dasarno
FYI some generic boilerplate info:
In general I recommend to try out our latest GitHub master code
because the GitHub master code is the only place where we fix things
and if there are issues it helps when you use exactly the code
where we could fix things.
See the "QUICK START GUIDE" and "INSTALLATION" parts on
https://github.com/rear/rear
Additionally / alternatively see the section
"Testing current ReaR upstream GitHub master code" in
https://en.opensuse.org/SDB:Disaster_Recovery
how you can try out our current ReaR GitHub master code
without conflicts with your already installed ReaR version.
In general we at ReaR upstream do not support older ReaR versions.
We at ReaR upstream do not plain reject issues with older ReaR
versions
(e.g. we may answer easy to solve questions also for older ReaR
versions)
but we do not spend much time on issues with older ReaR versions
because
we do not (and cannot) fix issues in released ReaR versions.
Issues in released ReaR versions are not fixed by us (by ReaR
upstream).
Issues in released ReaR versions that got fixed in current ReaR
upstream
GitHub master code might be fixed (if the fix can be backported with
reasonable effort) by the Linux distributor wherefrom you got ReaR.
In particular regarding Debian and/or Ubuntu:
I am neither a Debian nor a Ubuntu user.
Currently we at ReaR upstream do not have an active
maintainer for Debian and/or Debian.
So ReaR support for Debian and/or Ubuntu
can be only as good as voluntary contributors
who use those Linux distributions contribute
which is much appreciated!
In particular regarding MacBook Pro (with Intel CPU):
I think this is somewhat unusual hardware
where it was not tested that ReaR "just works" on it
I assume on "usual" x86 hardware USB keyboards "just work"
in particular with the default MODULES=('all_modules')
(otherwise we should have got many such issue reports).
So I assume "something is special" with a USB keyboard
on MacBook Pro (with Intel CPU) but I have no idea
what that actually is (I cannot reproduce anything
because I don't have any Apple hardware).
A blind guess what might help:
The assumption is that USB on MacBook Pro will work
when appropriate kernel modules are loaded and perhaps
when special (Apple) firmware is additionally available.
Try setting MODULES_LOAD+=( ... ) with all kernel modules
which are loaded on your MacBook Pro - i.e. what lsmod
lists last must be first in MODULES_LOAD.
For ReaR 2.7 see
https://github.com/rear/rear/blob/rear-2.7/usr/share/rear/conf/default.conf#L1594
and
https://github.com/rear/rear/blob/rear-2.7/usr/share/rear/conf/examples/SLE12-SP1-btrfs-example.conf#L36
For current ReaR GitHub master code see
https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf#L1897
The assumption is that USB on MacBook Pro needs special
kernel modules to be loaded which does not happen
automatically within the ReaR recovery system
so you need to enforce proper kernel module loading.
Additionally you may have a look at FIRMWARE_FILES.
Perhaps USB on MacBook Pro needs special (Apple) firmware
in a special directory (i.e. not below /lib*/firmware/)?
jsmeix commented at 2026-04-07 13:55:¶
@dasarno
regarding libsystemd-shared-257.so "not found" messages:
Normally you can ignore that message.
The root cause is that this library is specially
provided by systemd in a way so that ldd cannot find it
which results that it is reported as "not found" (by ldd)
but usually this library gets automatically properly copied
into the ReaR recovery system so usually it exists
at the right place in the ReaR recovery system.
In our GitHub master code it is much improved
how that special systemd library issue gets reported by ReaR.
dasarno commented at 2026-04-07 15:18:¶
A general comment which does perhaps point the developers in the right direction regarding debian. I have been using tails Linux for 10 years on macbook pros. All versions have always booted. Tails is built on debian in a minimalistic way . The OS is entirely read-only. The setup of tails could serve as an example how to boot macbooks right.
dasarno commented at 2026-04-07 15:20:¶
Here's the inventory of kernel modules:
lsmod|wc -l
147
lsmod|egrep -i 'apple|mac'
brcmfmac_wcc 12288 0
cmac 12288 3
brcmfmac 446464 1 brcmfmac_wcc
brcmutil 16384 1 brcmfmac
cfg80211 1404928 1 brcmfmac
applesmc 32768 0
mmc_core 253952 1 brcmfmac
apple_mfi_fastcharge 16384 0
hid_apple 28672 0
hid 262144 3 usbhid,hid_apple,hid_generic
applespi 53248 0
usbcore 409600 10 xhci_hcd,usbhid,btmtk,bcm5974,apple_mfi_fastcharge,usb_storage,brcmfmac,btusb,xhci_pci,uas
crc16 12288 3 bluetooth,ext4,applespi
dw_dmac_pci 12288 0
dw_dmac 12288 0
dw_dmac_core 40960 2 dw_dmac_pci,dw_dmac
What and how do I put this into the rear-configuration.
dasarno commented at 2026-04-09 16:22:¶
I picked the applespi module to be included explicitly in the configuration. The system overview in the MacOS GUI suggests a connection between keyboard/trackpad and "spi".
MODULES=( 'loaded_modules' )
MODULES_LOAD+=( 'applespi' )
MODULES_LOAD+=( 'hid' )
MODULES_LOAD+=( 'hid_apple' )
booting ends with the same:
[DEPEND] Dependencies failed for serial-getty@tty0service - Serial Getty on ttyS0
The response of the caps-lock key changed during the boot sequence. The
light came on when I engaged the key while loading the RAM-disk. Then
there is a second step loading some "stub". This is when the light goes
out. When the boot process halted the light would no longer come on.
The caps-lock-light going out points to a step that breaks the keyboard
connection.
How can I know wether or not the "applespi" module and there others was actually included by rear?
[Export of Github issue for rear/rear.]