#745 Issue closed: 33_find_isolinux.sh also called for OUTPUT=USB

Labels: enhancement, cleanup

schlomo opened issue at 2015-12-20 13:46:

usr/share/rear/prep/USB/Linux-i386/33_find_isolinux.sh is a symlink to ISO

Why do we need this?

gdha commented at 2015-12-29 07:26:

@schlomo 33_find_isolinux.sh sets the ISO_ISOLINUX_BIN variable (this was there from the beginning). However, since the packages were split up some modules were moved to their own sub-directory, and therefore, the script 35_find_syslinux_modules.sh was introduced to fix this. So, script 33_find_isolinux.sh is purely there for legacy purposes.

schlomo commented at 2015-12-29 09:28:

I am not sure I understand what you mean by "legacy purposes".

Can we remove this script to allow USB mode usage without installing isolinux (I know, we install it by default)?

gdha commented at 2015-12-29 18:57:

@schlomo It seems we only need:

# Define the syslinux directory for later usage
SYSLINUX_DIR=$(dirname $ISO_ISOLINUX_BIN)

Perhaps, it would be better to create a new script called 30_find_syslinux.sh and remove the link to 33_find_isolinux.sh (would make more sense I guess). Your thoughts?

gdha commented at 2016-01-13 10:30:

@schlomo Just verified it with OUTPUT=ISO and BACKUP_URL=usb:///... then the SYSLINUX_DIR is used in fact (and needed). With OUTPUT=USB the SYSLINUX_DIR is not used.
I would leave the link so that we don't break the ISO rescue image flow in combination with USB as backup destination.

schlomo commented at 2016-01-13 10:39:

@gdha Not sure I follow your thoughts. With OUTPUT=ISO IMHO prep/USB should not be called at all. So removing something from prep/USB should not have any impact for OUTPUT=ISO but only for OUTPUT=USB.

Or do we have some auto magic stuff in place that would call prep/USB if BACKUP_URL=usb://*?

gdha commented at 2016-01-13 10:58:

@schlomo I removed the link and it found no negative drawback in OUTPUT=USB nor OUTPUT=ISO. Therefore, we can remove the link. If we get complaints in the future then we should remember this issue somehow.

schlomo commented at 2016-01-13 11:00:

Thanks a lot!


[Export of Github issue for rear/rear.]