#3066 Issue open: No block device nodes in recovery system on Debian Trixie (systemd errors)

Labels: bug

martinnaughton opened issue at 2023-11-05 16:24:

  • ReaR version ("/usr/sbin/rear -V"): Relax-and-Recover 2.7 / Git

  • If your ReaR version is not the current version, explain why you can't upgrade:

  • OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):

PRETTY_NAME="Debian GNU/Linux trixie/sid"
NAME="Debian GNU/Linux"
VERSION_CODENAME=trixie
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
  • ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
OUTPUT=ISO
OUTPUT_URL=file:///media/hd/227DDF392FC0ECAC/
#OUTPUT_URL=null

BACKUP=NETFS
BACKUP_URL=file:///media/hd/227DDF392FC0ECAC/
BACKUP_PROG=tar
BACKUP_PROG_EXCLUDE=("${BACKUP_PROG_EXCLUDE[@]}" '/media' '/var/tmp', '/var/lib/docker/', '/var/cache/apt/archives' )

  • Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM guest or PowerVM LPAR):
    lenovo P52

  • System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
    X86

  • Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
    BIOS
    GRUB

  • Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
    local SSD

  • Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"):

  • Description of the issue (ideally so that others can reproduce it):
    I can not see any hard drive in the list. I have a NVMe ssd 1TB that i would like to restore the back up to
    I also tried this in VMware and it does not show a basic SCSI device i added when booting
    i cant even load up the other usb stick that has the backup.tar.gz file

You can see all the is loaded here:
Screenshot from 2023-11-05 16-19-07

Am i missing something that needs to run so devices are seen an I can run the mount command? Also to see the available hard disks.

  • Workaround, if any:
    None at the moment. i have tried loading the module with modprobe but the disk to not load

I see this guy had a similar issue but they said it was the device.
https://github.com/rear/rear/issues/2118

  • Attachments, as applicable ("rear -D mkrescue/mkback!)" debug log files):

You can drag-drop log files into this editor to create an attachment
or paste verbatim text like command output or file content
by including it between a leading and a closing line of
three backticks like this:

verbatim content

martinnaughton commented at 2023-11-05 20:21:

with further investigation I just tried the default rescue and the rescue image didnt show up the disks available.

# Default backup and output targets:
BACKUP=REQUESTRESTORE
OUTPUT=ISO

jsmeix commented at 2023-11-06 14:25:

@martinnaughton

what do

lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT

and

lsmod

show on your original system?

See MODULES_LOAD in usr/share/rear/conf/default.conf
how to enforce to load modules in the recovery system
and see
usr/share/rear/conf/examples/SLE12-SP2-btrfs-example.conf
for an example how MODULES_LOAD could be used

# Have all modules of the original system in the recovery system with the
# same module loading ordering as in the original system by using the output of
#   lsmod | tail -n +2 | cut -d ' ' -f 1 | tac | tr -s '[:space:]' ' '
# as value for MODULES_LOAD (cf. https://github.com/rear/rear/issues/626):
#MODULES_LOAD=( )

jsmeix commented at 2023-11-06 14:30:

In general:
When a Linux distribution uses a special init system
(i.e. not the usual systemd as in Red Hat, SUSE, Ubuntu)
then things could get rather complicated and tricky in ReaR
(up to impossible in practice with reasonable effort),
cf. https://github.com/rear/rear/issues/2955

pcahyna commented at 2023-11-06 15:27:

In general: When a Linux distribution uses a special init system (i.e. not the usual systemd as in Red Hat, SUSE, Ubuntu) then things could get rather complicated and tricky in ReaR (up to impossible in practice with reasonable effort), cf. #2955

Debian uses systemd by default, doesn't it?

pcahyna commented at 2023-11-07 18:20:

@jsmeix, why did you mention a special init system (not systemd) ? Is there anything in the issue that indicates that anything else than systemd is in use? I don't see this.

@martinnaughton How did you get to this point, anything unusual? I see you have also filed issue #3065. Is it related? Is it on the same machine? Do you get this problem after applying the workaround mentioned in #3065 ?

jsmeix commented at 2023-11-08 07:33:

@pcahyna
Thank you for also having a look and your correction!

I simply didn't look carefully and I did not remember
https://github.com/rear/rear/issues/3017
but I did remember that there were no devices in
https://github.com/rear/rear/issues/2955
which led me into a totally wrong direction.

So this is a good example of Linus's law
(which is actually Eric S. Raymond's law):
"given enough eyeballs, all bugs are shallow".

[Export of Github issue for rear/rear.]