#66 Issue closed: permit to proceed with the vlan

Labels: bug

pavoldomin opened issue at 2012-04-12 12:29:

The code exits with error on systems with vlan network:

# rear -v -D mkbackup
Relax and Recover 0.0.825 / 2012-03-16 18:37:24 +0100
Creating disk layout
Excluding RAID md2.
Excluding Volume Group lvlocal
Excluding Volume Group vgbackup
Excluding component fs:/backup
Excluding component logicaldrive:/dev/cciss/c0d0
Excluding component logicaldrive:cciss/c0d0
Creating root FS layout
ERROR: Relax and Recover does not yet support 802.1q, please sponsor it!
Aborting due to an error, check /tmp/rear-usssapl6.log for details
Finished in 26 seconds
Terminated

Would be nice if we can build the rescue image, even without vlan reconstruction ability (such that we could e.g. rescue system from the non-network targets)

schlomo commented at 2012-04-12 12:36:

In your opinion,

  1. should we just allow building a rescue system that won't have
    networking and hope that the user knew what they where doing
  2. should we try to guess if recovery needs networking or not and allow
    this only if recovery does not require networking
  3. should we add a new config option IGNORE_UNSUPPORTED_VLAN which needs
    to be set in order to convert this error into a warning

Regards,
Schlomo

On 12 April 2012 14:29, pavoldomin <
reply@reply.github.com

wrote:

The code exits with error on systems with vlan network:

rear -v -D mkbackup

Relax and Recover 0.0.825 / 2012-03-16 18:37:24 +0100
Creating disk layout
Excluding RAID md2.
Excluding Volume Group lvlocal
Excluding Volume Group vgbackup
Excluding component fs:/backup
Excluding component logicaldrive:/dev/cciss/c0d0
Excluding component logicaldrive:cciss/c0d0
Creating root FS layout
ERROR: Relax and Recover does not yet support 802.1q, please sponsor it!
Aborting due to an error, check /tmp/rear-usssapl6.log for details
Finished in 26 seconds
Terminated

Would be nice if we can build the rescue image, even without vlan
reconstruction ability (such that we could e.g. rescue system from the
non-network targets)

Reply to this email directly or view it on GitHub:
https://github.com/rear/rear/issues/66

pavoldomin commented at 2012-04-12 12:42:

well, we do it very directly :) :

(vlan_) continue ;;
#(vlan_) Error "$PRODUCT does not yet support 802.1q, please sponsor it!" ;;

cleanest probably would be indeed option 3, like IGNORE_UNSUPPORTED_FEATURE

Regards,
Pavol

dagwieers commented at 2012-04-12 13:00:

In issue #3 we already discuss how Rear can become a lot smarter in handling network-related recovery.

Obviously if it detects known MAC addresses it can assume that it is a restore to the same system and can continue with configuring the network setup exactly as it was. But in case this is not the case, there are a few things it could do (which we can do identically for VLAN tagging). After configuring an interface it could test whether the configuration in fact works (e.g. arping the gateway) if that does not work we have to ask the user to what interface to map.

Obviously with LACP this is not going to be easy, since doing a bruteforce on every combination of interfaces might be problematic (but we could opt to only test/run with a single interface for LACP. But during recovery we don't need HA.

What is needed is similar to what we implemented for the storage layout, i.e. writing out an abstraction of the configuration that is active on the system and then restoring the configuration from that abstract network configuration file. And that network configuration file should have dependencies between "interfaces" as well as support for bonding (LACP or other), VLAN tagging and possible other stuff...

[Export of Github issue for rear/rear.]