control: severity +2 serious I would call this an RC bug (serious), but not critical
It would be critical if the user lost data from some unrelated application, etc It is serious because a) it makes the package and the whole system unusable for all but one very specific network configuration (users with a /24) b) using good old `xm' style Xen I never experienced any issue like this, just using a /26 subnet with xm on squeeze is fine. c) it will lead to a complete loss of connectivity for people accessing a host remotely to set up XCP http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695221#10 refers to a workaround - nothing in the bug report qualifies as a workaround (but I propose one below). The reporter simply explained that he could only make pif-reconfigure-ip work the way it should by specifying a specific network mask (/24). That in itself is not a workaround, it is just an observation about what values work and what values don't work. I can confirm observing this identical issue, I configured a /29 netmask and `ip addr' shows me that my server thinks it is on a /32. This makes the whole host unreachable. I did a `find' in /etc and /var and I located the following file: /var/lib/xcp/networkd.db which contains the value {"interface_config": ......"MY ADDRESS", 32]]] The 32 is the bad subnet mask. Using vi, I replaced it with 29 (for a /29), rebooted, and it came up OK. As I don't know XCP very well, I don't want to suggest this is a valid workaround. Could anyone with more experience confirm if that file can be modified by hand in this case? Is there something else that could come along and clobber that file? Does xcp-networkd need to be stopped before modifying the file safely? If there is a workaround (what I describe above, or something else) for this such that a /29 or some other valid netmask can be enabled, then the bug could probably be downgraded to important but certainly not normal, it is just too disruptive. To extend the scope of what may qualify as a valid workaround: a) is there some valid use case that avoids using pif-reconfigure-ip and just let /etc/network/interfaces manage the IP? b) should the user put a /24 subnet on a dummy interface and configure eth0 or xenbr0 separately from XCP? I also came across this: http://lists.xen.org/archives/html/xen-api/2012-05/msg00104.html which contradicts this: http://wiki.xen.org/wiki/XCP_toolstack_on_a_Debian-based_distribution#Setup_the_network.2Finterfaces_file Specifically, the mailing list posts suggests nothing should be in /etc/network/interfaces, but the wiki suggests that the interface should be described in /etc/network/interfaces (even though it will eventually be reconfigured by xcp-networkd later in the boot process) -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
