https://bugzilla.suse.com/show_bug.cgi?id=1184460 https://bugzilla.suse.com/show_bug.cgi?id=1184460#c5 Knut Alejandro Anderssen Gonz�lez <kanderssen@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mail@georg-pfuetzenreuter.n | |et Flags|needinfo?(kanderssen@suse.c |needinfo?(mail@georg-pfuetz |om) |enreuter.net) --- Comment #5 from Knut Alejandro Anderssen Gonz�lez <kanderssen@suse.com> --- (In reply to Imobach Gonzalez Sosa from comment #4)

Hi,

Sorry, I overlooked that one. Knut, do you think we should adapt AutoYaST/network to behave the same way in both situations?

Thanks!

Yep, I think we should (In reply to Georg Pfuetzenreuter from comment #0)

4.11.4 Routing:

https://doc.opensuse.org/projects/autoyast/#CreateProfile-Network-Routing

Hello,

whilst the "netmask" Element is declared as deprecated, the Comment suggests a CIDR style netmask should be added to the destination Element. Having done that, I was faced with broken routing in both the installation stage one, as well as in the final install, as the system would NOT have a default route added. Only after removing the CIDR style netmask from the destination element (in order for it to only show the "pure" IP address of the gateway) a (working) default gateway would be present on the installation and final system.

Could you provide the routing section used? So, it was the default route and you provided something like: <routing> <route> <destination>0.0.0.0/0</destination> <name>eth0</name> <gateway>192.168.0.1</gateway> </route> </routing> Which could be defined as: <routing> <route> <destination>default</destination> <name>eth0</name> <gateway>192.168.0.1</gateway> </route> </routing> In that case I agree that we should explain it better in the routing section and in case of a default route using the CIDR format we should initialize the route correctly.

This makes sense, as the "ip route add" command does not take a netmask either. I assume the script fails to detect and remove the bogus netmask before trying to feed it into the routing table, and hence fails, leaving the system with no route present.

Hence I deem the documentation to be misleading, as it is suggesting the user a netmask should be added to the default routing definition. I suggest the destination Description (in particular the example address) and netmask Comment to be adjusted.

Best, Georg

-- You are receiving this mail because: You are on the CC list for the bug.