/etc/network/if-up.d/ifenslave is missing (installed under if-pre-up.d)

Looking at the source package it appears the up script is managing to find it's way into the pre-up.d directory resulting in the pre-up script being renamed to ifenslave.dpkg-new. The

Rob, your last post seems to be missing some text.

I've been trying to get bonding to work on Maverick server on amd64 too, and noticed that the /etc/network/if-up.d/ifenslave is missing even though it's listed in 'dpkg-query -L ifenslave-2.6'. Like Rob said, it seems like it's been installed in a wrong place, since doing a 'mv /etc/network/if-pre-up.d/ifenslave.dpkg-new /etc/network/if-up.d/ifenslave fixes things.

Except that the 'cat /proc/net/bonding/bond0' shows wrong bonding type for me... Bonding Mode: load balancing (round-robin) in stead of active-backup I've set it to be. But it could be that the /proc info is nowadays outdated since under /sys there is some bonding information also. I have to investigate this thing a bit more.

I forgot to mention that I'm using the same 1.1.0-15ubuntu2 version from ifenslave-2.6 than Rob. And my kernel is 2.6.35-25-server #44-Ubuntu SMP.

The info in /proc/net/bonding/bond0 wasn't actually outdated. There is some problem setting up the bonding device and it's settings. I had to take the device down with ifconfig, then put the mode manually to /sys/class/net/bond0/bonding/mode and then restart the networking to get the proper settings loaded. A reboot messes up the settings again. This smells like another bug...

I can confirm the issue with bond mode not being correct across reboots. Using the fix suggested in this bug I am able to get the bond0 device to start, but it ignores the mode on reboot and comes up mode=0 instead of mode=1. Only the gross solution of changing the mode manually and restarting the interface resolves the issue.

The message in the console is as follows:

bonding: unable to update mode of bond0 because the interface is up.

Here are the steps necessary to correct the package files after apt-get install ifenslave-2.6 results in the observed state, this solution also corrects the above mentioned issue I observed regarding the preservation of mode across reboots without any changes using the approved hotplug method.

$ /etc/network $ find . -name "*enslave*"
./if-pre-up.d/ifenslave.dpkg-new
./if-pre-up.d/ifenslave
./if-post-down.d/ifenslave

To correct the package perform the following steps:

mv /etc/network/if-pre-up.d/ifenslave /etc/network/if-up.d/ifenslave
mv /etc/network/if-pre-up.d/ifenslave.dpkg-new /etc/network/if-pre-up.d/ifenslave

As Rob Hall correctly notes the source package script is confused, however, not because it ended up in the wrong place when it attempted to write /etc/network/if-pre-up.d/ifenslave, but because there is an existing file which in fact should be /etc/network/if-up.d/ifenslave.

Since this effectively breaks bond0 and makes the correct implementation of bonding in 10.10, I feel this issue should be escalated and repaired.

I am not completely sure how this should get fixed in the end. Definitely there is something wrong with the postinst script. It looks like the intention there is to check the package version and when updating from a version <= 1.1.0-6 save the files in if-up.d and if-post-down.d as defaults by moving them into if-pre-up.d (or if-down.d) after creating backup files at the target location.

This seems to hit two problems:
1. The postinst tries to decide whether files have to be moved by comparing the value passed as $2 against the version above. However, when installing the first time $2 == "" and that is always considered a lower version number.
2. The package actually provides files in if-pre.up.d _and_ if-up.d (which are different too). So by the time the postinst is executed, any previous version in if-up.d has been replaced by the version in the package anyway. So even if the version check would work, upgrading from an older version would break.

Maybe the way to fix this would be to create backup files at preinst time, then check for those at postinst time and optionally move the backups into their final positions.

This bug was fixed in the package ifenslave-2.6 - 1.1.0-17ubuntu1

---------------
ifenslave-2.6 (1.1.0-17ubuntu1) oneiric; urgency=low

  * Merge from Debian unstable (closes LP: #714904), remaining changes:
    - ifstate is no longer in /etc/network/run, but rather in /var/run/network.
    - Fix debian/examples/two_hotplug_ethernet to be accurate.
    - Drop broken examples (two_ethernet, ethernet+wifi) that don't work with
      upstart.
    - debian/examples/ethernet+hotplug_wifi: update to use hotplugging for
      eth0.
    - Adjust README.Debian to be consistent with the examples, not advising
      users to use interface configs that won't work reliably with upstart.

ifenslave-2.6 (1.1.0-17) unstable; urgency=low

  * Only build ifenslave on Linux.

ifenslave-2.6 (1.1.0-16) unstable; urgency=low

  * Apply patches from Vagrant Cascadian:

    - Do not try to move config files on a fresh install. Closes: #499922
    - Do not try to move config files from wireless-tools. Closes: #587992

  * Bump Standards-Version.
  * Add ${misc:Depends}.
 -- Steve Langasek <email address hidden> Thu, 05 May 2011 16:58:48 -0700

Will this fix land in the repository for natty and maverick?

I came across this issue today (and it took me quite a while to find the duplicated /etc/network/if-up.d/ifenslave).

As of today the latest version in the repository is:
ii ifenslave-2.6 1.1.0-15ubuntu2

At least i can confirm that after

mv /etc/network/if-pre-up.d/ifenslave.dpkg-new /etc/network/if-pre-up.d/ifenslave

bonding works just fine again.

So I tested the ifenslave-2.6 (1.1.0-17ubuntu1) from oneiric, compiled under natty and with natty. The installation (after removing the old package version) works now and does not remove anything. From the code I would think, the same for upgrades from higher versions. I am still not sure about the case when upgrading from that -6 version checked in the postinst. But for one I might miss something and second it should be a different bug report then.

I also checked the examples in README.debian and in the exaples directory. They seem to be consistent now but at least for me only work that way for a static ip address setup. At least when using "ifdown -a" / "ifup -a". Just checked that dhcp seems to work on boot. But again, that likely should go into another report and it is not a regression as the same was happening when I tried things before (with the old package).

Stefan's proposed fixes both build (i386 tested) on their target releases - uploaded to -proposed.

Accepted ifenslave-2.6 into maverick-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Accepted ifenslave-2.6 into natty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Not really convinced that it is "appropriate" for me to give testing feedback, so maybe someone else also affected could be so kind and add feedback. So at least for me install and update seem to work on Maverick and Natty. The message about preserving configuration files does not show up and the bonding device comes up functional.

I'm somewhat new to Ubuntu and am working on natty (11.04). I installed what I thought was the update from the proposed repository and still have to use modprobe bonding to bring up the bonding interface. The upgrade version I fount was 1.1.0-15ubuntu2.11.04.1. Is this the correct version?

Excerpts from Jim Taitt's message of Tue Jun 14 21:55:37 UTC 2011:
> I'm somewhat new to Ubuntu and am working on natty (11.04). I installed
> what I thought was the update from the proposed repository and still
> have to use modprobe bonding to bring up the bonding interface. The
> upgrade version I fount was 1.1.0-15ubuntu2.11.04.1. Is this the
> correct version?

Yes it is the correct version Jim.

Can you paste any logs that show what happened on install?

One kind of "problem" I found was that the man page was not particularly helpful. Though, at least with Natty, the files in /usr/share/doc/ifenslave-2.6/... (README.Debian and examples/) are consistent as far as I can see.

My configuration in Natty (which does not require a modprobe) looks like:

 /etc/network/interfaces:
auto bond0
iface bond0 inet static (though dhcp should work as well)
  address x
  netmask 255.255.255.0
  gateway y
  bond-slaves none
  bond-mode active-backup
  bond-miimon 100

auto eth0
iface eth0 inet manual
  bond-master bond0
  bond-primary eth0

auto eth1
iface eth1 inet manual
  bond-master bond0
  bond-primary eth0

Sorry I didn't get back to you a little sooner but I had some other things to get done first. I uninstalled Ifenslave-2.6 from the natty proposed repository and then re-installed it.The first time I just updated it, if that made a difference. But now it seems to be running fine..

I have two questions for you if you have a moment.

1. Assuming there aren't any problems found, how long does it take before the ifenslave2.6 in the proposed repository is moved into the main production repositories? Just curious...

2. The options bond-XXXX, such as bond-primary, where are they documented ? I've looked all over and have not found them. Probably just missed them.

Again many thanks for your help.
Jim Taitt

Jim, update or fresh install should not make a difference (except if the currently installed version would be way old (older than Hardy) which is unlikely). The main difference to look out for would be that neither installation nor upgrade print a line about preserving old configuration files.

About your questions:

1. I think it works similar as it did with the kernel package, that is all bug reports mentioned to be fixed by a package in proposed are checked after about one or two weeks after uploading. If there is no feedback about the bug not being fixed or new problems being introduced the package would get moved to updates. It is a bit hard to say what to do with your experience. Was bonding not working after an upgrade because of the package or some other problem? At least fresh install worked better than before and at least a working version upgrading does not get worse (what I basically did in my tests). That hopefully is acceptable enough.

2. The most documentation is in /usr/share/doc/ifenslave-2.6/README.Debian. Though it does not explain all the details. Some of the options may have a bit more help from the bonding module itself (modinfo bonding). But at least it describes a simple setup. In that doc dir there is also an examples directory that is helpful. Note that the options apparently can use underscore or hyphen, so bond-master works the same as bond_master does.

Wow, I'm so impressed with the way you have handled my questions. Not a hint of get off your a@# and figure it out yourself. Especially in an area like this which draws programmers and the like who are expected to have a lot of understanding before they ask the same old question over and over again. I'm am a programmer and have worked with openSuse a couple of years off and on as well as Mac's and Pc's. I'm now trying to learn about the Debian flavor of this distro and it is sometimes confusing to move one day from each platform to another. There are so many minute differences to keep track of.

All to say, thanks for your kindness.

I'm by no means an expert on Ubuntu Server, but I have a copy of the full desktop on a different logical drive which was added to the original Server kernel so I can play with the server only version as well as jump into the desktop to do things I can't get it to do in the server version.

In trying to fix my original issue, I did a package upgrade using the Synaptic Package Manager after adding the proposed repository to the soruces.list file. As was my first post after changing the interfaces file, it still did not work leading me to believe i got the wrong package. I then went to a command line and if I remember clearly, used apt-get remove to delete the whole package and then re-installed it with apt-get install. Then it worked fine. Hopefully this will be of some help to you if similar problem show up elsewhere. Although I suspect it was just my inexperience with Ubuntu.

One more question which would really help in my understanding of how these package managers work in the background. In a case like what I was doing here (trying to download a single package from a test repository) I expected to only have one file downloaded but got at least 7 others which when looking at the change log on a few of them I found they were also from the proposed repository. In Synaptic and/or the command line does it actually download all of these files or are just references put into a database and then a package is only downloaded when you actually install it?

I found some option in Synaptic giving you a choice how to handle something like this but when it comes to using only the command line, I know there has to be a way to download only one package and not have any others installed accidentally when using apt-get update and then followed by apt-get upgrade.

The answer is probably quite involved, so rather than having you write a book, it would be ok to just point me to some docs or link on the internals. The programmer in me just loves to know what is going on in the internals. Which at least for me it gives me an edge when real issues come up and I have to step through then logically to come up with a solution. Plus it's just plan fun to know!!!

One last comment, do you frequent the forums? I need to move my questions out of here and start posting them there where they should be.....

Thanks, Jim Taitt Huntington Beach, Ca.

No worries, we all started at some point. :)

Basically synaptics update should have updated the package and in theory it should have worked then. I am not sure though, whether this still all works that well. Problem is that there are a lot of ways to milk a cow. From a graphical end I would use update-manager. There would be a settings button and that allows to enable proposed by clicking a button. From a cli you would add the proposed repo and then you have to run apt-get update at least once to actually pull the information (maybe that could be a missing step with synaptic).

And enabling proposed, yes that will give you _all_ the packages that are in the staging area. There is some way you can pin certain packages, but honestly I found that method too complicated to bother (One doesn't want to enable proposed on a production system for that reason).
Using update-manager you could deselect everything and then select only one package to install. And after that just deactivate proposed again.
Or packages also can be found through launchpad. For example:
https://launchpad.net/ubuntu/+source/ifenslave-2.6 which is ok as long as there are no dependencies to another proposed version.

I probably should be helping on the forums too, but I am not. Time seems to be eaten by all sorts of other things. But there certainly are many helpful people there. Or try irc. #ubuntu-server on freenode could be a good starting point for things like this.

Again, Many thanks......

Re #14: I have tested natty (apt-get purge ifenslave-2.6; apt-get install ifenslave-2.6) and bonding works now without additional up and down clauses in the /etc/network/interfaces file.

Relevant section of /etc/network/interfaces (two servers connected back-to-back with each other):

auto bond0
iface bond0 inet static
  address 192.168.111.1
  netmask 255.255.255.0
  bond-slaves eth1 eth2 eth3
  bond-mode balance-rr
  bond_arp_ip_target 192.168.111.2
  bond_arp_interval 1000
  mtu 9000

auto eth1
iface eth1 inet manual
  bond-master bond0
  mtu 9000

auto eth2
iface eth2 inet manual
  bond-master bond0
  mtu 9000

auto eth3
iface eth3 inet manual
  bond-master bond0
  mtu 9000

Note that putting the bond-slaves into the master definition is discouraged as it can cause a race. Using "bond-slaves none" should be used. The slaves will get added automatically when the slave interfaces come up.

Indeed I had read so elsewhere and have tried that but I couldn't get bond0 up then. But the second part of your second sentence woke me up just now:

Instead of just 'ifup bond0' and be done the command I have to do is 'ifup bond0 && ifup eth1 && ifup eth2 && ifup eth3' :)

Thanks!

Or "ifup -a" :)

This bug was fixed in the package ifenslave-2.6 - 1.1.0-15ubuntu2.11.04.1

---------------
ifenslave-2.6 (1.1.0-15ubuntu2.11.04.1) natty-proposed; urgency=low

  * Check for previous version to be not set (on fresh install) when
    comparing versions in postinst.
    LP: #714904
 -- Stefan Bader <email address hidden> Mon, 16 May 2011 16:34:07 +0000

Setting back to v-needed for maverick.

This bug affects Ubuntu 10.10, Maverick Meerkat. Maverick has reached end-of-life and is no longer supported, so I am closing the bugtask for Maverick. Please upgrade to a newer version of Ubuntu.
More information here: https://lists.ubuntu.com/archives/ubuntu-announce/2012-April/000158.html