Bryan McLellan wrote: > Tom Metro wrote: >> I'll have to take a look at ubuntu-minimal to see what it is. > > It's a meta package... I figured that from the name, but I wondered what packages it pulled in, and what the consequences were for removing it were. > Uninstalling it would mean that in the future if another package was > added to to the meta package, you wouldn't get that additional > package on upgrade. Which sounds fairly low risk, but something one would ideally want to avoid. > You could also remove the dhcp3-client package with > --force-depends, which just runs the risk that it gets reinstalled > later during an upgrade. There's probably a complex pinning solution > too, but I can't fathom it. I couldn't figure out a way around it. Any combination I came up with (like putting dhcp3-client on hold, then removing it), just left the package system in a broken state. More importantly, on Hardy there are additional dependencies on dhcp3-client. dhcdbd depends on it, which provides the DBus interface to dhcp3-client that's used by network manager, which in turn Network Manager depends on, which in turn ubuntu-desktop depends on. The resolutions offered up by aptitude (supposedly the best tool for resolving dependency issues) all involved uninstalling more packages than I cared to. To work around this I ended up creating a dummy package using the equivs package. That lets me replace the real dhcp3-client with a dummy one, which uninstalled the dhcp3-client binaries and scripts. All this makes me wonder if ubuntu-minimal ought to be dependent on the generic dhcp-client (which dhcp3-client, dhcpcd, and udhcpc all provide), rather than a specific package. (Of course on Hardy that won't fix the dhcdbd dependency. I'm guessing that means dhcp3 is probably the only client Network Manager knows how to control.) I'm also wondering if uninstalling dhcp3-client was even necessary. I noticed when I installed udhcpc that it didn't cause any conflicts, even though it ought to have conflicted with another package providing dhcp-client. Either udhcpc isn't correctly tagged as providing dhcp-client, or the two can peacefully coexist. Looks like dhcpcd has dhcp-client listed as a conflict, while udhcpc doesn't. Given that they all are driven by the sane interfaces config file, I'd expect there to be conflicts. I'd like to understand better how that works. Is each overwriting the other's ifupdown scripts? Is there a common script with a bunch of -x tests to see which binaries are present? > I did test and confirm that dhcpcd=1:3.2.3-1.1 does work on alias > interfaces on intrepid. Unfortunately this doesn't work on Hardy with dhcpcd=1:3.0.17-2: # init.d/networking restart * Reconfiguring network interfaces... Error, eth0: dhcpcd not running dhcpcd.sh: interface eth0 has been configured with new IP=192.168.0.203 * Stopping NTP server ntpd ...done. * Starting NTP server ntpd ...done. Error, eth0:1: ioctl SIOCSIFFLAGS: Cannot assign requested address Failed to bring up eth0:1. [...] ...done. Looks like the usual failure, though in a bit different format than what ifconfig produces, suggesting it is making its own syscalls, and they're failing in the kernel code. At least it positively states that it failed to bring up the interface (confirmed), unlike dhcp3-client. A second look at the interfaces man page shows that the DHCP configuration directives there are supported by udhcpc in addition to dhcpcd. I hadn't noticed that before, and the udhcpc documentation omits to mention it (should probably file a bug for that). Given that udhcpc spits out warnings, but did appear to work when invoked directly on Hardy, I'm going to try that next. Hurray, it finally worked: # init.d/networking restart * Reconfiguring network interfaces... RTNETLINK answers: No such process udhcpc (v0.9.9-pre) started Sending discover... Sending select for 192.168.0.203... Lease of 192.168.0.203 obtained, lease time -1 Resetting default routes adding dns 192.168.0.35 * Stopping NTP server ntpd ...done. * Starting NTP server ntpd ...done. udhcpc (v0.9.9-pre) started SIOCSIFFLAGS: Cannot assign requested address Sending discover... Sending select for 192.168.0.238... Lease of 192.168.0.238 obtained, lease time -1 Resetting default routes adding dns 192.168.0.35 * Stopping NTP server ntpd ...done. Ignoring unknown interface eth1=eth1. Ignoring unknown interface eth2=eth2. Ignoring unknown interface ath0=ath0. Ignoring unknown interface wlan0=wlan0. [ OK ] * Starting NTP server ntpd ...done. # ifconfig eth0 Link encap:Ethernet HWaddr 00:04:...:d1:33 inet addr:192.168.0.203 Bcast:192.168.0.255 Mask:255.255.255.0 [...] eth0:1 Link encap:Ethernet HWaddr 00:04:...:d1:33 inet addr:192.168.0.238 Bcast:192.168.0.255 Mask:255.255.255.0 I did have to apply some additional tweaks to interfaces to get udhcpc to behave correctly. It apparently doesn't send the host name by default as part of the DHCP discover packet, unlike the other two clients, which resulted in a new IP address getting assigned to the primary interface (and Dnsmasq no longer knowing how to reach the machine by name). But that's easy enough to remedy with a hostname argument. I also previously determined that to force a DHCP server to issue two different IP addresses to requests coming from the same hardware address requires specifying unique client IDs for each request. (Specifying a unique host name alone is apparently not sufficient, according to the standard.) So my interfaces ended up like: [...] auto eth0 iface eth0 inet dhcp hostname mythtv client mythtv auto eth0:1 iface eth0:1 inet dhcp hostname indianpoint client indianpoint [...]