#3383 Issue closed: False alarm in 880_check_for_mount_by_id.sh when there is no SCSI disk (e.g. only NVMe disks)¶
Labels: enhancement, cleanup, fixed / solved / done
xwhitebeltx opened issue at 2025-01-22 13:29:¶
Hello =)
i created a backup with the latest rear, restore works fine but i get this message:
- looks like you're asking for info on this system, which info would you like to get?
- should i be worried about this message? what is it indicating? =)
rear -V
cat /etc/os-release
uname -r
lsblk
cat /etc/rear/local.conf
jsmeix commented at 2025-01-22 13:54:¶
Personally I know nothing about that code
so I cannot help to actually debug this issue.
In particular I am not a Ubuntu user.
Currently we at ReaR upstream do not have an active
maintainer for Ubuntu / Debian.
So ReaR support for Ubuntu / Debian
can be only as good as voluntary contributors
who use those Linux distributions contribute
which is much appreciated!
In particular regarding Ubuntu:
It seems Canonical is not sufficiently interested in ReaR
in contrast to Red Hat and SUSE who pay developers
(like me from SUSE and e.g. @pcahyna and @lzaoral from Red Hat)
to contribute to upstream ReaR because Red Hat and SUSE
support ReaR in their enterprise Linux distributions.
Nevertheless some generic info:
That "Could not list any LUN IDs" warning comes from
usr/share/rear/finalize/default/880_check_for_mount_by_id.sh
According to
# git log -p --follow usr/share/rear/finalize/default/880_check_for_mount_by_id.sh
it was added on Nov 18 2009 via
https://github.com/rear/rear/commit/45ab5e0e8d29a182ad68fc20fb571518b72a4a6b
so that warning is there since a long time
so I assume that likely it has nothing to do
with the changes for the recent ReaR 2.8 release.
@xwhitebeltx
did you use ReaR before the current ReaR 2.8 on this system?
If yes, what older ReaR version(s) did you use?
In this case I assume you did not get that warning
with the older ReaR version(s)?
gdha commented at 2025-01-28 07:58:¶
On Ubuntu scsi_id can be found under directory /lib/udev.
# /lib/udev/scsi_id --export --whitelisted -d /dev/sda
ID_SCSI=1
ID_VENDOR=ATA
ID_VENDOR_ENC=ATA\x20\x20\x20\x20\x20
ID_MODEL=INTEL_SSDMCEAC24
ID_MODEL_ENC=INTEL\x20SSDMCEAC24
ID_REVISION=LLKi
ID_TYPE=disk
ID_SERIAL=35001517803d82e0f
ID_SERIAL_SHORT=5001517803d82e0f
ID_WWN=0x5001517803d82e0f
ID_WWN_WITH_EXTENSION=0x5001517803d82e0f
ID_SCSI_SERIAL=CVLI30130039240G
However, usr/sbin/rear:PATH=$PATH:/lib/udev:/usr/lib/udev already has
this in its PATH.
Therefore, @xwhitebeltx where is your scsi_id located on your system?
jsmeix commented at 2025-01-28 08:23:¶
In SUSE (openSUSE Leap 15.6 in my case here)
scsi_id belongs to udev and is /usr/lib/udev/scsi_id
# type -a scsi_id
-bash: type: scsi_id: not found
# find / -xdev | grep '/scsi_id'
/usr/lib/udev/scsi_id
# rpm -qf /usr/lib/udev/scsi_id
udev-254.21-150600.4.21.1.x86_64
My /usr/lib/udev/scsi_id shows
# /usr/lib/udev/scsi_id -h
Usage: scsi_id [OPTION...] DEVICE
SCSI device identification.
-h --help Print this message
--version Print version of the program
-d --device= Device node for SG_IO commands
-f --config= Location of config file
-p --page=0x80|0x83|pre-spc3-83 SCSI page (0x80, 0x83, pre-spc3-83)
-s --sg-version=3|4 Use SGv3 or SGv4
-b --denylisted Treat device as denylisted
-g --allowlisted Treat device as allowlisted
-u --replace-whitespace Replace all whitespace by underscores
-v --verbose Verbose logging
--truncated-serial truncated serial for compatibility
with systems configured with
by-id links created by udev < 184
-x --export Print values as environment keys
where - as far as I see - the current scsi_id options
do not match the rather old code from 2009 in
finalize/default/880_check_for_mount_by_id.sh
how scsi_id is called there
# apparently the usage of scsi_id changed over the times, so we try two ways to call it
eval "$(scsi_id -g -x -n -s /block/"$sysfs" -d /dev/$device 2>/dev/null || scsi_id --export --whitelisted -d /dev/$device)"
On my openSUSE Leap 15.6 workstation I don't have a built-in SCSI
device
(my NVMe disk does not belong to SCSI and 'lsscsi' shows nothing)
but with an external USB disk I get
# lsscsi
[0:0:0:0] disk TOSHIBA External USB 3.0 5438 /dev/sda
# /usr/lib/udev/scsi_id -g -x -n -d /dev/sda
/usr/lib/udev/scsi_id: invalid option -- 'n'
# /usr/lib/udev/scsi_id -g -x -d /dev/sda
ID_SCSI=1
ID_VENDOR=TOSHIBA
ID_VENDOR_ENC=TOSHIBA
ID_MODEL=External_USB_3.0
ID_MODEL_ENC=External\x20USB\x203.0
ID_REVISION=5438
ID_TYPE=disk
ID_SERIAL=1TOSHIBA
ID_SERIAL_SHORT=TOSHIBA
ID_SERIAL_COMPAT=
ID_SCSI_SERIAL=20170521000273
# /usr/lib/udev/scsi_id --export --whitelisted -d /dev/sda
ID_SCSI=1
ID_VENDOR=TOSHIBA
ID_VENDOR_ENC=TOSHIBA
ID_MODEL=External_USB_3.0
ID_MODEL_ENC=External\x20USB\x203.0
ID_REVISION=5438
ID_TYPE=disk
ID_SERIAL=1TOSHIBA
ID_SERIAL_SHORT=TOSHIBA
ID_SERIAL_COMPAT=
ID_SCSI_SERIAL=20170521000273F
So '--whitelisted' still works , I found it mentioned on
https://linux.die.net/man/8/scsi_id
But '-n' does not (or does no longer) work.
And '-s /block/...' cannot (or does no longer) work
because I don't have '/block/' but '/sys/block/...'
# ls -l /sys/block/sda
lrwxrwxrwx 1 root root 0 Jan 28 13:24 /sys/block/sda -> ../devices/pci0000:00/0000:00:08.1/0000:03:00.3/usb2/2-1/2-1:1.0/host0/target0:0:0/0:0:0:0/block/sda
jsmeix commented at 2025-01-28 08:37:¶
@xwhitebeltx
please provide us your "rear recover" log file.
Therein in particular the part while
finalize/default/880_check_for_mount_by_id.sh
is run is of interest for us.
In general:
Caution with possible secrets in a ReaR log file.
In particular in debugscript mode via the option '-D'
ReaR logs executed commands via the bash command 'set -x'
that print commands and their arguments as they are executed.
So in particular when arguments contain secret values
(e.g. something like a password or whatever else)
such secret values may appear in the log file.
jsmeix commented at 2025-01-28 12:40:¶
@xwhitebeltx
when you found the scsi_id executable on your system, cf.
https://github.com/rear/rear/issues/3383#issuecomment-2618157153
call it with the '-h' (help) option and show us the output.
jsmeix commented at 2025-01-28 13:15:¶
Some "archaeology" about 'scsi_id':
On a SLES 11 SP4 KVM/QEMU virtual machine:
# lsscsi
[0:0:0:0] disk ATA QEMU HARDDISK 2.5+ /dev/sda
[0:0:1:0] cd/dvd QEMU QEMU DVD-ROM 2.5+ /dev/sr0
# find / -xdev | grep '/scsi_id'
/lib/udev/scsi_id
/usr/share/man/man8/scsi_id.8.gz
# /lib/udev/scsi_id -h
Usage: scsi_id OPTIONS <device>
--device= device node for SG_IO commands
--config= location of config file
--page=0x80|0x83|pre-spc3-83 SCSI page (0x80, 0x83, pre-spc3-83)
--sg-version=3|4 use SGv3 or SGv4
--blacklisted threat device as blacklisted
--whitelisted threat device as whitelisted
--replace-whitespace replace all whitespaces by underscores
--verbose verbose logging
--version print version
--export print values as environment keys
--help print this help text
# /lib/udev/scsi_id --export --device=/dev/sda
[no output]
# /lib/udev/scsi_id --export --whitelisted --device=/dev/sda
ID_SCSI=1
ID_SCSI_VPD=0x83
ID_VENDOR=ATA
ID_VENDOR_ENC=ATA\x20\x20\x20\x20\x20
ID_MODEL=QEMU_HARDDISK
ID_MODEL_ENC=QEMU\x20HARDDISK\x20\x20\x20
ID_REVISION=2.5+
ID_TYPE=disk
ID_SERIAL=1ATA_QEMU_HARDDISK_QM00001
ID_SERIAL_SHORT=ATA_QEMU_HARDDISK_QM00001
ID_WWN=0xATA QEMU HAR
ID_WWN_VENDOR_EXTENSION=0xDDISK
ID_WWN_WITH_EXTENSION=0xATA QEMU HARDDISK
ID_SCSI_SERIAL=QM00001
# /lib/udev/scsi_id --version
147
# rpm -qf /lib/udev/scsi_id
udev-147-0.105.4
# ls -l /usr/lib/udev
ls: cannot access /usr/lib/udev: No such file or directory
On a SLES 12 SP5 KVM/QEMU virtual machine:
# lsscsi
[0:0:0:0] disk ATA QEMU HARDDISK 2.5+ /dev/sda
[0:0:1:0] cd/dvd QEMU QEMU DVD-ROM 2.5+ /dev/sr0
# find / -xdev | grep '/scsi_id'
/usr/lib/udev/scsi_id
# /usr/lib/udev/scsi_id -h
Usage: scsi_id [OPTION...] DEVICE
SCSI device identification.
-h --help Print this message
--version Print version of the program
-d --device= Device node for SG_IO commands
-f --config= Location of config file
-p --page=0x80|0x83|pre-spc3-83 SCSI page (0x80, 0x83, pre-spc3-83)
-s --sg-version=3|4 Use SGv3 or SGv4
-b --blacklisted Treat device as blacklisted
-g --whitelisted Treat device as whitelisted
-u --replace-whitespace Replace all whitespace by underscores
-v --verbose Verbose logging
--truncated-serial truncated serial for compatibility
with systems configured with by-id
links created by udev < 184
-x --export Print values as environment keys
# /usr/lib/udev/scsi_id -x -d /dev/sda
[no output]
# /usr/lib/udev/scsi_id -x -g -d /dev/sda
ID_SCSI=1
ID_VENDOR=ATA
ID_VENDOR_ENC=ATA\x20\x20\x20\x20\x20
ID_MODEL=QEMU_HARDDISK
ID_MODEL_ENC=QEMU\x20HARDDISK\x20\x20\x20
ID_REVISION=2.5+
ID_TYPE=disk
ID_SERIAL=1ATA_QEMU_HARDDISK_QM00001
ID_SERIAL_COMPAT=
ID_SERIAL_SHORT=ATA_QEMU_HARDDISK_QM00001
ID_SCSI_SERIAL=QM00001
# /usr/lib/udev/scsi_id --version
228
# rpm -qf /usr/lib/udev/scsi_id
udev-228-155.21.x86_64
# ls -l /lib/udev
lrwxrwxrwx 1 root root 13 Jun 4 2024 /lib/udev -> /usr/lib/udev
On a SLES 15 SP6 KVM/QEMU virtual machine:
# lsscsi
[0:0:0:0] cd/dvd QEMU QEMU DVD-ROM 2.5+ /dev/sr0
# find / -xdev | grep '/scsi_id'
/usr/lib/udev/scsi_id
# /usr/lib/udev/scsi_id -h
Usage: scsi_id [OPTION...] DEVICE
SCSI device identification.
-h --help Print this message
--version Print version of the program
-d --device= Device node for SG_IO commands
-f --config= Location of config file
-p --page=0x80|0x83|pre-spc3-83 SCSI page (0x80, 0x83, pre-spc3-83)
-s --sg-version=3|4 Use SGv3 or SGv4
-b --denylisted Treat device as denylisted
-g --allowlisted Treat device as allowlisted
-u --replace-whitespace Replace all whitespace by underscores
-v --verbose Verbose logging
--truncated-serial truncated serial for compatibility
with systems configured with by-id
links created by udev < 184
-x --export Print values as environment keys
# /usr/lib/udev/scsi_id -x -d /dev/sr0
[no output]
# /usr/lib/udev/scsi_id -x -g -d /dev/sr0
ID_SCSI=1
ID_VENDOR=QEMU
ID_VENDOR_ENC=QEMU\x20\x20\x20\x20
ID_MODEL=QEMU_DVD-ROM
ID_MODEL_ENC=QEMU\x20DVD-ROM\x20\x20\x20\x20
ID_REVISION=2.5+
ID_TYPE=cd
ID_SERIAL=1ATA_QEMU_DVD-ROM_QM00001
ID_SERIAL_SHORT=ATA_QEMU_DVD-ROM_QM00001
ID_SERIAL_COMPAT=
# /usr/lib/udev/scsi_id --version
systemd 254 (254.10+suse.84.ge8d77af424)
+PAM +AUDIT +SELINUX +APPARMOR +IMA -SMACK +SECCOMP ...
# rpm -qf /usr/lib/udev/scsi_id
udev-254.10-150600.2.3.x86_64
# ls -l /lib/udev
ls: cannot access '/lib/udev': No such file or directory
xwhitebeltx commented at 2025-01-29 11:17:¶
Hello dear people =)
thank you for your responses, i will try to address them all:
@jsmeix - i did not try with earlier versions on this system, first time was with the latest rear
@gdha - iscsi_id on my system is on the same path you mentioned
/lib/udev/scsi_id
when i execute the same command it has no output since i only have NVMe
SSDs:
@jsmeix - oddly enough my environment makes it hard to extract the log
as text, but i can screenshot the relevant part you talked about with
finalize/default/880_check_for_mount_by_id.sh, not much information
there:
@jsmeix - output of scsi_id --help:
if i only have NVMe drives then is this warning still relevant? (the "could not list any LUN IDs with scsi_id warning)
i would like to emphasize this is a realtime kernel (is it supported?)
for example - it disables EFI runtime by default, and rear fails when restoring such environment.
i had to re-enable the EFI runtime in order for rear to backup & restore properly.
(command efibootmgr returned "EFI variables are not supported on this system" and was unusable,
solution was to add "efi=runtime" to the "KERNEL_CMDLINE" variable in /etc/rear/local.conf to enable it)
you can see it in the local.conf screenshot in my initial post
my point is - maybe it's adding more layers of complexity to the environment
let me know if you require anything else, or if you think it is expected
behavior,
thanks =)
jsmeix commented at 2025-01-29 13:24:¶
@xwhitebeltx
thank you!
Now I see how things go wrong in ReaR!
The crucial information was
iscsi_id on my system is on the same path you mentioned /lib/udev/scsi_id
when i execute the same command it has no output since i only have NVMe SSDs
I never tested "rear recover" on my openSUSE Leap 15.6 workstation
where I don't have a built-in SCSI device (I have only a NVMe disk).
Now I can reproduce it on my SLES 15 SP6 KVM/QEMU virtual test machine
with the following artificial modification in the ReaR recovery system
before I run "rear recover"
--- a/usr/share/rear/finalize/default/880_check_for_mount_by_id.sh
+++ b/usr/share/rear/finalize/default/880_check_for_mount_by_id.sh
...
# Note: we ignore swap here because we treat it specially somewhere else!
-if [ -e $TARGET_FS_ROOT/etc/fstab ] && grep -v swap $TARGET_FS_ROOT/etc/fstab | grep -q by-id ; then
+if true ; then
LogPrint ""
...
# apparently the usage of scsi_id changed over the times, so we try two ways to call it
- eval "$(scsi_id -g -x -n -s /block/"$sysfs" -d /dev/$device 2>/dev/null || scsi_id --export --whitelisted -d /dev/$device)"
+ eval "$( true )"
if test "$ID_SERIAL" ; then
...
because on my SLES 15 SP6 KVM/QEMU virtual test machine
I do not mount things 'by-id' and
I like to simulate that 'scsi_id' returns nothing.
With that artificial modification I get
RESCUE localhost:~ # rear -D recover
...
WARNING ! You are mounting some devices by ID. Please be aware that the IDs
are hardware dependent and that you might have to adjust your fstab to match
the new IDs. Currently your system has the following disks with LUN IDs:
WARNING ! Could not list any LUN IDs with scsi_id. Please tell us how your
system calls scsi_id. However, some disks just don't have any LUN ID. We
would like to know more about such systems and how they look.
Note the empty output for
"Currently your system has the following disks with LUN IDs:"
and then the subsequent false alarm about
"Could not list any LUN IDs with scsi_id"
regardless that my 'scsi_id' replacement 'true' run successfully.
FYI
regarding 'WARNING' in general see
https://schlomo.schapiro.org/2015/04/warning-is-waste-of-my-time.html
;-)
So I will have to overhaul that code
to make it behave more fail-safe, cf.
"Try hard to care about possible errors" in
https://github.com/rear/rear/wiki/Coding-Style
jsmeix commented at 2025-01-29 13:34:¶
@xwhitebeltx
as far as I see from my analysis in
https://github.com/rear/rear/issues/3383#issuecomment-2621646197
I think it is also false alarm on your particular system
so you could safely ignore it.
To verify whether or not it is actually false alarm on your system
run "rear -D recover" i.e. in debugscript mode ('-D')
and inspect still inside the ReaR recovery system the log file
/var/log/rear/rear-localhost.log
therein in particular the part while
finalize/default/880_check_for_mount_by_id.sh
is run.
Furthermore inspect the recreated etc/fstab
still inside the ReaR recovery system which is there
/mnt/local/etc/fstab
whether or not it is OK as you need it and as you expect it
for your particular system.
While you are still inside the ReaR recovery system
after "rear recover" finished, you can correct things
in the recreated system which is mounted below /mnt/local/
(you may do "chroot /mnt/local/" into the recreated system)
before you call "reboot" or "poweroff" in the recovery system
to boot the recreated system (sometimes "poweroff" and then
booting the recreated system via 'power on' works better).
xwhitebeltx commented at 2025-01-29 14:02:¶
@jsmeix
thanks for the links =)
yes i now understand that this is a false alarm in my case,
after the restore system is booting fine and everything seems ok.
jsmeix commented at 2025-01-29 14:09:¶
@xwhitebeltx
could you please post here your etc/fstab
so that I could see how one looks like
when things are mounted 'by-id'?
FYI:
On my SLES 15 SP6 KVM/QEMU virtual test machine
with the SLES default btrfs subvolumes structure
things are mounted via UUID:
# cat /etc/fstab
UUID=bad9f5d9-6a37-4902-b5fc-ded16e84f357 / btrfs defaults 0 0
UUID=bad9f5d9-6a37-4902-b5fc-ded16e84f357 /var btrfs subvol=/@/var 0 0
UUID=bad9f5d9-6a37-4902-b5fc-ded16e84f357 /usr/local btrfs subvol=/@/usr/local 0 0
UUID=bad9f5d9-6a37-4902-b5fc-ded16e84f357 /tmp btrfs subvol=/@/tmp 0 0
UUID=bad9f5d9-6a37-4902-b5fc-ded16e84f357 /srv btrfs subvol=/@/srv 0 0
UUID=bad9f5d9-6a37-4902-b5fc-ded16e84f357 /root btrfs subvol=/@/root 0 0
UUID=bad9f5d9-6a37-4902-b5fc-ded16e84f357 /opt btrfs subvol=/@/opt 0 0
UUID=bad9f5d9-6a37-4902-b5fc-ded16e84f357 /home btrfs subvol=/@/home 0 0
UUID=bad9f5d9-6a37-4902-b5fc-ded16e84f357 /boot/grub2/x86_64-efi btrfs subvol=/@/boot/grub2/x86_64-efi 0 0
UUID=bad9f5d9-6a37-4902-b5fc-ded16e84f357 /boot/grub2/i386-pc btrfs subvol=/@/boot/grub2/i386-pc 0 0
UUID=1b15280b-7649-43dc-a939-2ff39d41839b swap swap defaults 0 0
UUID=bad9f5d9-6a37-4902-b5fc-ded16e84f357 /.snapshots btrfs subvol=/@/.snapshots 0 0
# lsblk -bipo NAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINTS,UUID
NAME TRAN TYPE FSTYPE SIZE MOUNTPOINTS UUID
/dev/sr0 sata rom iso9660 16442720256 2024-06-13-19-56-33-00
/dev/vda virtio disk 16106127360
|-/dev/vda1 virtio part 8388608
|-/dev/vda2 virtio part btrfs 13949206528 /var bad9f5d9-6a37-4902-b5fc-ded16e84f357
| /usr/local
| /tmp
| /root
| /srv
| /opt
| /home
| /boot/grub2/x86_64-efi
| /boot/grub2/i386-pc
| /.snapshots
| /
`-/dev/vda3 virtio part swap 2147466752 [SWAP] 1b15280b-7649-43dc-a939-2ff39d41839b
dev/vda3 virtio part swap 2147466752 [SWAP]
xwhitebeltx commented at 2025-01-29 14:27:¶
of course,
this is the fstab from my system:
this is a clean ubuntu 22.04 installation with realtime kernel and a few
minor modifications,
the only thing mounted by id is the default root partition logical group
(LVM) created by the ubuntu installer
output from the second command you sent:
jsmeix commented at 2025-01-29 16:56:¶
https://github.com/rear/rear/pull/3391
should (hopefully) fix it.
At least for me it seems to work as intended, see
https://github.com/rear/rear/pull/3391#issuecomment-2624128336
But I cannot verify (with acceptable efforts)
how various versions of scsi_id in various
Linux distribution environments may behave.
jsmeix commented at 2025-02-05 13:26:¶
With
https://github.com/rear/rear/pull/3391
merged
this issue should be solved.
jsmeix commented at 2025-02-05 13:40:¶
@xwhitebeltx
the new user info text is like this when there are SCSI devices
Automatically adjusting /dev/disk/by-id entries in etc/fstab is not supported:
Those IDs could be hardware dependent so check /mnt/local/etc/fstab
and verify all is correct or manually adjust /mnt/local/etc/fstab
to the actual values of the recreated system in /mnt/local
'scsi_id' reports '/dev/XXX' 123MiB: ID_VENDOR=VVV ID_MODEL=MMM ID_SERIAL=456
'scsi_id' reports '/dev/YYY' 234MiB: ID_VENDOR=vvv ID_MODEL=mmm ID_SERIAL=789
cf. https://github.com/rear/rear/pull/3391#issuecomment-2624433370
The new user info text is like this when there are no SCSI devices
Automatically adjusting /dev/disk/by-id entries in etc/fstab is not supported:
Those IDs could be hardware dependent so check /mnt/local/etc/fstab
and verify all is correct or manually adjust /mnt/local/etc/fstab
to the actual values of the recreated system in /mnt/local
In your case what is mounted via /dev/disk/by-id/...
is not a SCSI device so 'scsi_id' cannot show you
what SCSI devices exist on the replacement hardware.
Nevertheless automatically adjusting /dev/disk/by-id
entries in etc/fstab is also not supported in your case.
So also in your case with NVMe devices you need to
check your recreated /mnt/local/etc/fstab and verify
all is correct or manually adjust your /mnt/local/etc/fstab
to your actual values of your recreated system in /mnt/local
cf.
https://github.com/rear/rear/issues/3383#issuecomment-2621668755
(excerpt)
While you are still inside the ReaR recovery system
after "rear recover" finished, you can correct things
in the recreated system which is mounted below /mnt/local/
(you may do "chroot /mnt/local/" into the recreated system)
before you call "reboot" or "poweroff" in the recovery system
[Export of Github issue for rear/rear.]