#608 Issue closed: Unneccessary drivers started after restore?? Problem with initrd?¶
Labels: support / question, fixed / solved / done
rpasche opened issue at 2015-07-02 21:10:¶
Hi,
I just tested the todays master branch and built a rear debian package, backupd up and restored a system successful.
But the initrd is somehow different. Although the md5sum is the same, the initrd (after recovery and reboot) has a huge number of additional drivers installed (and loaded), such as Qlogic, Adaptec, Broadcom, DRBD and other stuff, that is not needed within a virtual machine (and has not been used before the restore)
Before restore (just after backup)
scsi_mod 191405 4 sg,libata,sd_mod,sr_mod
After restore (output of "lsmod | grep scsi")
vmw_pvscsi 21455 0
virtio_scsi 17816 0
virtio_ring 17513 2 virtio_blk,virtio_scsi
virtio 13058 2 virtio_blk,virtio_scsi
tmscsim 25973 0
scsi_transport_srp 18194 0
scsi_dh_rdac 16972 0
scsi_dh_hp_sw 12751 0
scsi_dh_emc 17002 0
scsi_dh_alua 16950 0
scsi_dh 13306 4 scsi_dh_alua,scsi_dh_rdac,scsi_dh_emc,scsi_dh_hp_sw
scsi_debug 77393 0
mptscsih 26657 3 mptfc,mptsas,mptspi
mptbase 73042 6 mptfc,mptctl,mptlan,mptsas,mptspi,mptscsih
iscsi_tcp 17580 0
i2o_scsi 12893 0
i2o_core 39579 5 i2o_bus,i2o_proc,i2o_scsi,i2o_config,i2o_block
libiscsi_tcp 21554 4 cxgb3i,cxgb4i,iscsi_tcp,libcxgbi
scsi_transport_fc 56119 10 bfa,csiostor,fcoe,fnic,lpfc,qla2xxx,libfc,mptfc,tcm_qla2xxx,bnx2fc
scsi_tgt 17698 3 scsi_transport_fc,scsi_transport_srp,libsrp
be2iscsi 105865 0
iscsi_boot_sysfs 12922 2 qla4xxx,be2iscsi
libiscsi 48004 8 qla4xxx,libiscsi_tcp,bnx2i,cxgb3i,cxgb4i,be2iscsi,iscsi_tcp,libcxgbi
scsi_transport_iscsi 77478 6 qla4xxx,bnx2i,be2iscsi,iscsi_tcp,libcxgbi,libiscsi
scsi_transport_sas 33531 8 isci,mvsas,mpt2sas,mpt3sas,libsas,mptsas,pm80xx,aic94xx
scsi_transport_spi 27851 6 mptspi,sym53c8xx,aic79xx,aic7xxx,aha152x_cs,dmx3191d
crc_t10dif 12431 4 lpfc,scsi_debug,target_core_mod,sd_mod
scsi_mod 191405 84 ch,sg,st,bfa,ipr,osd,ses,csiostor,fcoe,fnic,gdth,hpsa,isci,lpfc,osst,stex,qla1280,qla2xxx,qla4xxx,scsi_debug,scsi_dh_alua,scsi_dh_rdac,megaraid_mbox,scsi_transport_fc,scsi_transport_sas,scsi_transport_spi,scsi_transport_srp,cciss,bnx2i,libfc,mptfc,mvsas,mvumi,qlogicfas408,i2o_scsi,scsi_dh,scsi_transport_iscsi,sym53c500_cs,fdomain_cs,tcm_qla2xxx,arcmsr,bnx2fc,dc395x,scsi_tgt,BusLogic,tmscsim,mpt2sas,mpt3sas,hptiop,initio,scsi_dh_emc,aacraid,scsi_dh_hp_sw,libata,libsas,mptctl,mptsas,mptspi,sym53c8xx,pm80xx,target_core_mod,be2iscsi,qlogic_cs,vmw_pvscsi,aic79xx,aic94xx,aic7xxx,sd_mod,sr_mod,ufshcd,iscsi_tcp,mptscsih,aha152x_cs,advansys,atp870u,libcxgbi,libiscsi,dmx3191d,a100u2w,raid_class,megaraid,pmcraid,megaraid_sas,virtio_scsi
Can you confirm (or explain) this behavior?
dagwieers commented at 2015-07-02 22:21:¶
I think it is related to this:
So somehow it doesn't detect udev ?
Can you check ?
rpasche commented at 2015-07-05 20:23:¶
It looks like, that rear mkbackup detects, that a current systemd is
running and "systemd-udev" should be used. But the script
/usr/share/rear/skel/default/etc/scripts/system-setup.d/40-start-udev-or-load-modules.sh
seems to search for the special rear udev rule to activate udev. But
this file has not been generated, because it previously detected, that
systemd-udev should be used (this is in script
/usr/share/rear/build/GNU/Linux/60_verify_and_adjust_udev.sh.
But...anyway..if "systemd" does not work within the rescue system...this is one thing, but why does it not seem to work after a restore?
I will check again.
rpasche commented at 2015-07-05 20:39:¶
Hmm...ok. Maybe I was wrong, when I said, that the initrd file are the same....i was wrong. The original initrd is not the same initrd, that is running after a recovery. I will further check
gdha commented at 2015-07-09 07:19:¶
@rpasche I suppose this is a Debian 8 (again)? Did you try the latest rear snapshot? systemd should be working on debian8 - I'm not sure I understand the issue at this very moment... need some more coffee
rpasche commented at 2015-07-09 11:01:¶
Maybe the recover log will help you. https://gist.github.com/rpasche/38e740d25f0a882e47aa
The problem seems to be, that the magic rear udev rule 00-rules has not been created and because of that, all storage modules get loaded. Later, the loades modules get compared against the ones stored before and initrd gets patched (updated)
rpasche commented at 2015-07-09 12:16:¶
I think, this https://github.com/rear/rear/blob/master/usr/share/rear/skel/default/etc/scripts/system-setup.d/40-start-udev-or-load-modules.sh#L8 is the main reason. Because of this failing on debian 8 with systemd (00-rear rules has not been generated), the modules get loaded the normal way and thus, the modules needed on this recovery hardware are patched into initrd.
rpasche commented at 2015-07-09 12:48:¶
Ah.....just saw another issue...but this is only because of this
error. After I successfully recovered a backup with rear, I just wanted
to test the ONLY_INCLUDE_VG setting and start another backup. But
because the initrd is still poluted with all storage drivers (from
last recovery), all following rear mkbackup fail, because needed
programs are missing
Relax-and-Recover 1.17.1 / Git
Using log file: /var/log/rear/rear-deb-prod-test.log
ERROR: Cannot find required programs: drbdadm drbdsetup drbdmeta
Aborting due to an error, check /var/log/rear/rear-deb-prod-test.log for details
Terminated
root@deb-prod-test:~#
But again, as I said already, when this issue is fixed, that error mentioned in this comment should be gone.
rpasche commented at 2015-07-13 19:03:¶
Pull request https://github.com/rear/rear/pull/617 fixes this issue (for me). Tested on Debian 8 (jessie)
[Export of Github issue for rear/rear.]