#626 Issue closed: module scsi_debug auto load at rhel 7.1

Labels: enhancement, support / question, fixed / solved / done

tbsky opened issue at 2015-07-25 08:58:

hi:
the situation comes with rhel 7.1 (or rhel 7.0 with recent updates). rear will load "scsi_debug" module automatically when restore. and that module will create a 8MB /sev/sda. the restore procedure will have trouble if the original system also have harddisk named /dev/sda.

I now use "EXCLUDE_MODULES" to exclude it. but I think maybe we can exclude it globally. I saw "scsi_debug" module at thel 6.6 also, but rear under rhel 6.6 won't auto load it, I don't know why rear under rhel 7.1 load it automatically.

jsmeix commented at 2015-07-27 08:30:

I had this issue some time ago on a Suse Linux machine (I guess it was a SLES11 system but I don't remember well).

But it happened only on one particular laptop that I used for a test. It did not happen in general.

In gereral I noticed at that time that in the rear recovery system I had more than 100 kernel modules loaded while in my original system I had something about 40 kernel modules loaded.

From my point of view this indicates that there is something wrong in general in the rear recovery system that it has much more kernel modules loaded than in the original system - I guess it is something in udev (nowadays included in systemd).

My generic workaround is the following (that helped me in the past for any kind of wrong kernel modules in the rear recovery system) in /etc/rear/local.conf:

# Have all modules of the original system also in the recovery system
# using the output of lsmod | tail -n +2 | cut -d ' ' -f 1 | tac | tr -s '[:space:]' ' '
MODULES_LOAD=( ... )

I.e. I run in the original system

lsmod | tail -n +2 | cut -d ' ' -f 1 | tac | tr -s '[:space:]' ' '

and have that output as value for MODULES_LOAD

tbsky commented at 2015-07-27 09:03:

hi jsmeix:

thanks for your hint! yes it is something related to systemd-udev. I don't mind if there are many modules loaded when recovery. but this module prevent the recovery process.

I saw commit which may fix the systemd-udev problem. this issue maybe fixed also. I prefer my recovery media to have many modules in case I need to restore the system in different hardware..

jsmeix commented at 2015-07-27 09:41:

I feel at least a bit usafe when the recovery system has different kernel modules loaded than the original system.

Perhaps for "normal recovery cases" it could be a safe default to load only those kernel modules that have been loaded in the original system?

With "normal recovery case" I mean that the hardware where recovery happens is fully compatible with the hardware of the original system.

With "fully compatible hardware" I mean that same kernel modules will work (e.g. one cannot have a replacement NIC in the recovery hardware that needs a different kernel module).

Obviously this restricts on what hardware recovery can work but on the other hand it could make recovery on fully compatible hardware work more reliably.

I assume the basic question is what the default use-case is for rear.

Recovery on same or fully compatible replacement hardware or recovery on "sufficiently similar" replacement hardware?

In the latter case one would need to define what "sufficiently similar" actually means.

For example replacing a single harddisk with another single harddisk with at least the original size could be sufficiently similar but replacing one traditional spinning 1TB harddisk with two SSDs where each SSD has 600GB is probably not sufficiently similar.

gdha commented at 2015-08-10 14:54:

According http://sg.danny.cz/sg/sdebug26.html it seems safe to exclude the scsi_debug module in recovery mode.

gdha commented at 2015-11-04 09:29:

@tbsky Could you see what the effect is of the new script?

tbsky commented at 2015-11-04 09:53:

hi:
the scripts seems try to unload scsi_debug if it is loaded? I have not test it, but it seems too late to unload unless the script can unload the module before loading real harddisk.

since the major problem of this module is it will occupy /dev/sda, so the real harddisk will become /dev/sdb. even the module is unloaded, I think the real harddisk will still remain /dev/sdb.

I now just exclude the module so it won't copy to recovery image hence it has no chance to load..

[Export of Github issue for rear/rear.]