Its a bug, if you read more of the bug reports, you'll see that things
actually don't work, and actually are a regression from older versions.
Specifically, DHCP doesn't work on virtual ethernet interfaces (such as
eth0:0), and if DHCP is on the parent interface (eth0), that when you
stop the
** Changed in: wireless-tools (Ubuntu)
Status: New = Confirmed
--
'SIOCSIFFLAGS: Cannot assign requested address' when setting up ip alias
https://bugs.launchpad.net/bugs/123773
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
Maybe if all the bug reporters try the nomination feature we can get
this looked at, or maybe someone needs to look up the maintainer info
and try and get someone working/looking at this bug.
But for now, maybe people can nominate this for hardy... I didn't see an
option for intrepid in the list
add maintainer to it
** Changed in: ifupdown (Ubuntu)
Assignee: (unassigned) = Scott James Remnant (scott)
--
'SIOCSIFFLAGS: Cannot assign requested address' when setting up ip alias
https://bugs.launchpad.net/bugs/123773
You received this bug notification because you are a member of
add maintainer to bug
** Changed in: wireless-tools (Ubuntu)
Assignee: (unassigned) = Scott James Remnant (scott)
--
'SIOCSIFFLAGS: Cannot assign requested address' when setting up ip alias
https://bugs.launchpad.net/bugs/123773
You received this bug notification because you are a member
Using Hardy updated to latest updates as of today, 32-bit, on a Quad
Xeon machine with an Intel 10/100 2-port NIC, the following
/etc/network/interfaces still causes such errors:
/etc/network/interfaces:
auto eth1 eth1:0 eth1:1
iface eth1 inet static
address 192.168.0.109
netmask
I decided to try my theory of using dhcp on the parent interface only.
It works and sends out dhcp requests as expected, if it doesn't get any
responses, the virtual interfaces have to wait for it to be backgrounded
before they are brought up (not a big deal.. 10-15 seconds or something
I think),
Okay, I tried the server kernel on the system with the nforce3 chipset
(storage2 machine), and it still produces the following output and does
not work:
[EMAIL PROTECTED]:~# smartctl --device=ata -s on /dev/sda
smartctl version 5.36 [i686-pc-linux-gnu] Copyright (C) 2002-6 Bruce Allen
Home page
This bug is still current on some systems, I just updated to the
following kernel on two feisty systems, and one works, and one still
does not.
Linux storage2 2.6.20-16-generic #2 SMP Fri Feb 1 02:59:08 UTC 2008 i686
GNU/Linux
The 'storage2' machine is using an nforce3 chipset as follows:
Smartmontools 5.37 does not 'cure' this problem on all systems (feisty
here currently), even 5.36 works on one of my systems (promise sata
controller), but not on my other system (nforce3 CK8S chipset). It
seems there still needs to be some kernel patches in this area, or some
backported kernel
I tried installing a backport of smartmontools 5.37, but it has the same
issue.
The 'blacktower' system works even with 5.36 however.. so I don't think
its smartmontools related, and still a kernel issue that may need a
backported fix if its been fixed upstream already.
--
11 matches
Mail list logo
