#3391 PR merged: Overhauled 880_check_for_mount_by_id.sh¶
Labels: enhancement, cleanup, fixed / solved / done
jsmeix opened issue at 2025-01-29 16:55:¶
-
Type: Enhancement / Cleanup
-
Impact: Normal
-
Reference to related issue (URL):
https://github.com/rear/rear/issues/3383 -
How was this pull request tested?
See below
https://github.com/rear/rear/pull/3391#issuecomment-2624128336 -
Description of the changes in this pull request:
Overhauled finalize/default/880_check_for_mount_by_id.sh
jsmeix commented at 2025-01-30 10:42:¶
With the current state up to
https://github.com/rear/rear/pull/3391/commits/c44018f14322af2c8c7c094673650ded6c91a2db
it seems to work as intended for me.
My original system for my test is a
SLES 15 SP6 KVM/QEMU virtual machine.
There I manually added a /dev/disk/by-id entry to /etc/fstab
for the only SCSI disk I have which is the virtual CDROM:
# lsscsi
[0:0:0:0] cd/dvd QEMU QEMU DVD-ROM 2.5+ /dev/sr0
# find /dev/disk/by-id/ -ls
355 0 drwxr-xr-x 2 root root 60 Jan 30 08:54 /dev/disk/by-id/
579 0 lrwxrwxrwx 1 root root 9 Jan 30 08:54 /dev/disk/by-id/ata-QEMU_DVD-ROM_QM00001 -> ../../sr0
# 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
/dev/disk/by-id/ata-QEMU_DVD-ROM_QM00001 /DVD iso9660 defaults 0 0
# cat /proc/partitions
major minor #blocks name
254 0 15728640 vda
254 1 8192 vda1
254 2 13622272 vda2
254 3 2097135 vda3
11 0 16057344 sr0
The /dev/sr0 is a SLES 15 SP6 installation ISO image.
With that I did "rear mkbackup".
My replacement "hardware" is another KVM/QEMU virtual machine
with same kind of virtual disk, a KVM 'VirtIO' virtual disks
and same disk size as the one of my original test system:
RESCUE localhost:~ # rear -D recover
...
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/sr0' 84MiB: ID_VENDOR='QEMU' ID_MODEL='QEMU_DVD-ROM' ID_SERIAL='1ATA_QEMU_DVD-ROM_QM00001'
...
RESCUE localhost:~ # cat /mnt/local/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
/dev/disk/by-id/ata-QEMU_DVD-ROM_QM00001 /DVD iso9660 defaults 0 0
RESCUE localhost:~ # cat /proc/partitions
major minor #blocks name
254 0 15728640 vda
254 1 8192 vda1
254 2 13622272 vda2
254 3 2097135 vda3
11 0 86704 sr0
The /dev/sr0 is the ReaR recovery system ISO image.
"rear -D recover" log file excerpts
+ source /usr/share/rear/finalize/default/880_check_for_mount_by_id.sh
...
2025-01-30 11:20:00.114442276 Automatically adjusting /dev/disk/by-id entries in etc/fstab is not supported:
2025-01-30 11:20:00.119070443 Those IDs could be hardware dependent so check /mnt/local/etc/fstab
2025-01-30 11:20:00.123974680 and verify all is correct or manually adjust /mnt/local/etc/fstab
2025-01-30 11:20:00.129424122 to the actual values of the recreated system in /mnt/local
2025-01-30 11:20:00.143412579 scsi_id: none of ID_VENDOR and ID_MODEL and ID_SERIAL is set for '/dev/vda'
2025-01-30 11:20:00.154774704 scsi_id: none of ID_VENDOR and ID_MODEL and ID_SERIAL is set for '/dev/vda1'
2025-01-30 11:20:00.166053463 scsi_id: none of ID_VENDOR and ID_MODEL and ID_SERIAL is set for '/dev/vda2'
2025-01-30 11:20:00.177271568 scsi_id: none of ID_VENDOR and ID_MODEL and ID_SERIAL is set for '/dev/vda3'
2025-01-30 11:20:00.213332139 'scsi_id' reports '/dev/sr0' 84MiB: ID_VENDOR='QEMU' ID_MODEL='QEMU_DVD-ROM' ID_SERIAL='1ATA_QEMU_DVD-ROM_QM00001'
jsmeix commented at 2025-01-30 12:04:¶
Next thing is to get rid of that possibly insecure 'eval'
which evaluates variables that are set to "foreign" values.
jsmeix commented at 2025-01-30 12:51:¶
With the current state up to
https://github.com/rear/rear/pull/3391/commits/587d6c7df5786fcdf19546958776ec1d4471738d
it still works same as for me as in my test before
https://github.com/rear/rear/pull/3391#issuecomment-2624128336
RESCUE localhost:~ # rear -D recover
...
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/sr0' 84MiB: ID_VENDOR=QEMU ID_MODEL=QEMU_DVD-ROM ID_SERIAL=1ATA_QEMU_DVD-ROM_QM00001
...
Only the formatting of the scsi_id output of ID_VENDOR ID_MODEL
ID_SERIAL
looks now a bit simpler as it was before.
jsmeix commented at 2025-02-03 13:01:¶
@rear/contributors
unless there are objections I would like to merge it
next Wednesday (Feb. 05) afternoon.
jsmeix commented at 2025-02-03 16:04:¶
For comparison how it looks on the same test system as in
https://github.com/rear/rear/pull/3391#issuecomment-2624128336
with pristine ReaR 2.9:
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:
1ATA_QEMU_DVD-ROM_QM00001 /dev/sr0 84MB
...
[Export of Github issue for rear/rear.]