** Description changed:
Binary package hint: udev
My wifi interface is currently called "wlan0_rename", which indicates
that the interface renaming was only half-done.
This box was installed with gutsy, and upgraded to hardy every couple of
days.
-- snip --
** Description changed:
Binary package hint: udev
My wifi interface is currently called "wlan0_rename", which indicates
that the interface renaming was only half-done.
This box was installed with gutsy, and upgraded to hardy every couple of
days.
-- snip --
** Summary changed:
- [GUTSY] interface not completely renamed with iwl3945 module
+ mac80211 "master" interface matches existant persistent network rules
** Changed in: udev (Ubuntu)
Importance: Undecided => Critical
Assignee: (unassigned) => Scott James Remnant (keybuk)
Target: N
The previous persistent network rules were generated _without_
ATTR{type}=="1" so would match any device with the right MAC address.
Changing to mac80211 for many devices in 8.04 means that these devices
have gained an additional "wmaster0" control device that has the same
MAC address.
Udev will
Confirmed that deleting the old "# PCI device" entry from 70-persistant-
net.rules and removing/reinserting the module will correct the problem.
Seems to be an error that occurs when switching from ipw3945 to iwl3945
(I think this occured when upgrading Gutsy to Hardy).
Thanks wvengen for that li
For the record, the 70-persistant-net.rules diff in an automatic upgrade
test between a gutsy->hardy upgrade (+++) and a fresh install (---):
-# PCI device 0x10ec:0x8139 (8139cp)
-SUBSYSTEM=="net", ACTION=="add", ATTR{type}=="1", NAME="eth0"
+# PCI device 0x10ec:0x8139 (8139too)
+SUBSYSTEM=="net",
I am having the same problems on my Lenovo X61. But there are further
issues; Once the desktop has started the wireless does work.
However, AFTER COMING BACK FROM SUSPEND the wireless is gone! The only
way to get it back is to restart the machine. Restarting X etc. does not
do the trick.
--
mac8
Ashkay,
This is fixed by changing "/etc/udev/rules.d/70-persistent-net.rules" as
shown at http://wiki.debian.org/iwlwifi or as described above. It worked
on my Lenovo T60p and fixed both the boot delay and the problem on
resume from suspend.
--
mac80211 "master" interface matches existant persis
Confirmed on an IBM T60 and a Dell per-load E1505N both upgraded to hardy.
Both have the Intel IPW3945 chips. Known working under gutsy on same
hardware so this is a regression. Also on a T61P and an X61 both with
Atheros hardware on hardy no problems.
I believe this is critical to fix before re
This bug is broadly confirmed and is already tracked as critical for the
release, with work on resolving it already in progress. There is no
need for further confirmations of the bug.
--
mac80211 "master" interface matches existant persistent network rules
https://bugs.launchpad.net/bugs/183968
This bug was fixed in the package udev - 117-6
---
udev (117-6) hardy; urgency=low
* Automatically add ADDR{type}=="1" to 70-persistent-net.rules rules
where we can or at least add a useful comment where the user has written
their own rule that's broken in the same way. LP:
Did you follow the workaround in the bug description? The bug fix does
not help people who upgraded to Hardy before the bug was fixed. Please
try the following:
1. sudo rm /etc/udev/rules.d/70-persistent-net.rules
2. Reboot
/etc/udev/rules.d/70-persistent-net.rules should have been regenerated
The bug still happens to me on up-to-date hardy amd64!
I have an ipw3945 and have no wireless after resume!
--
mac80211 "master" interface matches existant persistent network rules
https://bugs.launchpad.net/bugs/183968
You received this bug notification because you are a member of Ubuntu
Bugs, w
Ok, works fine again. :)
Sorry about the inconvenience and thanks for the reply.
What confused me was that right after the bug was marked fixed everything was
fine on that update, then, after two small updates, it broke again! I thought
the bug I subscribed at the time wasn't a duplicate.
--
ma
I can't boot my laptop anymore. I had done the suggested workaround
*before* the update. Today morning 10:00 am pacific I updated my machine
and can't boot anymore. First, it gets stuck on "loading hardware
drivers...", then when I force it to skip that it gets stuck starting
the cups daemon.
What
Ok I do have a clue. It seems to be the new kernel update "...-16"
causing the problem. If I boot using the old kernel image "...-15"
everything works ok!
--
mac80211 "master" interface matches existant persistent network rules
https://bugs.launchpad.net/bugs/183968
You received this bug notifica
Scott,
I've already followed that advice and deleted the 70-persistent-net.rules file
by hand. Could you please tell us a little more about what effect deleting it
might have, and how one can solve that problem for those who already have done
it.
Arnab.
--
mac80211 "master" interface matches
If you deleted it, there's no way to get it back.
Deleting it will cause your interface names to change on the next
reboot; thus any manual configuration for your network will be lost or
(worse) confused between the different cards.
On a desktop machine with Network Manager, this tends not to mat
This is not fixed for me. When I resume from suspend to ram, my network is a
chaos, iwconfig shows eth0_rename as wifi, eth1 is not wifi anymore, ifdown and
ifups, /etc/init.d/network restart, nothing. I need to reboot.
ipw2200 and hardy uptodate (except kernel, version 14, could it be the
prob
Liken: if you still have problems, then you have obviously experienced a
different bug. Please file a new bug and be sure to attach output of
"ifconfig -a" and the contents of /etc/udev/rules.d/70-persistent-
net.rules
--
mac80211 "master" interface matches existant persistent network rules
http
Scott: I did it. Bug #213158
But Greg Michalec says it may be a duplicate of this. I attach in later bug the
files you indicate.
--
mac80211 "master" interface matches existant persistent network rules
https://bugs.launchpad.net/bugs/183968
You received this bug notification because you are a me
I am having the same problems on my Lenovo X61. But there are further
issues; Once the desktop has started the wireless does work.
However, AFTER COMING BACK FROM SUSPEND the wireless is gone! The only
way to get it back is to restart the machine. Restarting X etc. does not
do the trick.
--
mac8
Ashkay,
This is fixed by changing "/etc/udev/rules.d/70-persistent-net.rules" as
shown at http://wiki.debian.org/iwlwifi or as described above. It worked
on my Lenovo T60p and fixed both the boot delay and the problem on
resume from suspend.
--
mac80211 "master" interface matches existant persis
** Description changed:
Binary package hint: udev
My wifi interface is currently called "wlan0_rename", which indicates
that the interface renaming was only half-done.
This box was installed with gutsy, and upgraded to hardy every couple of
days.
-- snip --
** Description changed:
Binary package hint: udev
My wifi interface is currently called "wlan0_rename", which indicates
that the interface renaming was only half-done.
This box was installed with gutsy, and upgraded to hardy every couple of
days.
-- snip --
** Summary changed:
- [GUTSY] interface not completely renamed with iwl3945 module
+ mac80211 "master" interface matches existant persistent network rules
** Changed in: udev (Ubuntu)
Importance: Undecided => Critical
Assignee: (unassigned) => Scott James Remnant (keybuk)
Target: N
The previous persistent network rules were generated _without_
ATTR{type}=="1" so would match any device with the right MAC address.
Changing to mac80211 for many devices in 8.04 means that these devices
have gained an additional "wmaster0" control device that has the same
MAC address.
Udev will
Confirmed that deleting the old "# PCI device" entry from 70-persistant-
net.rules and removing/reinserting the module will correct the problem.
Seems to be an error that occurs when switching from ipw3945 to iwl3945
(I think this occured when upgrading Gutsy to Hardy).
Thanks wvengen for that li
For the record, the 70-persistant-net.rules diff in an automatic upgrade
test between a gutsy->hardy upgrade (+++) and a fresh install (---):
-# PCI device 0x10ec:0x8139 (8139cp)
-SUBSYSTEM=="net", ACTION=="add", ATTR{type}=="1", NAME="eth0"
+# PCI device 0x10ec:0x8139 (8139too)
+SUBSYSTEM=="net",
This is not fixed for me. When I resume from suspend to ram, my network is a
chaos, iwconfig shows eth0_rename as wifi, eth1 is not wifi anymore, ifdown and
ifups, /etc/init.d/network restart, nothing. I need to reboot.
ipw2200 and hardy uptodate (except kernel, version 14, could it be the
prob
Liken: if you still have problems, then you have obviously experienced a
different bug. Please file a new bug and be sure to attach output of
"ifconfig -a" and the contents of /etc/udev/rules.d/70-persistent-
net.rules
--
mac80211 "master" interface matches existant persistent network rules
http
Scott: I did it. Bug #213158
But Greg Michalec says it may be a duplicate of this. I attach in later bug the
files you indicate.
--
mac80211 "master" interface matches existant persistent network rules
https://bugs.launchpad.net/bugs/183968
You received this bug notification because you are a me
Confirmed on an IBM T60 and a Dell per-load E1505N both upgraded to hardy.
Both have the Intel IPW3945 chips. Known working under gutsy on same
hardware so this is a regression. Also on a T61P and an X61 both with
Atheros hardware on hardy no problems.
I believe this is critical to fix before re
This bug is broadly confirmed and is already tracked as critical for the
release, with work on resolving it already in progress. There is no
need for further confirmations of the bug.
--
mac80211 "master" interface matches existant persistent network rules
https://bugs.launchpad.net/bugs/183968
This bug was fixed in the package udev - 117-6
---
udev (117-6) hardy; urgency=low
* Automatically add ADDR{type}=="1" to 70-persistent-net.rules rules
where we can or at least add a useful comment where the user has written
their own rule that's broken in the same way. LP:
Did you follow the workaround in the bug description? The bug fix does
not help people who upgraded to Hardy before the bug was fixed. Please
try the following:
1. sudo rm /etc/udev/rules.d/70-persistent-net.rules
2. Reboot
/etc/udev/rules.d/70-persistent-net.rules should have been regenerated
The bug still happens to me on up-to-date hardy amd64!
I have an ipw3945 and have no wireless after resume!
--
mac80211 "master" interface matches existant persistent network rules
https://bugs.launchpad.net/bugs/183968
You received this bug notification because you are a member of Ubuntu
Bugs, w
Ok, works fine again. :)
Sorry about the inconvenience and thanks for the reply.
What confused me was that right after the bug was marked fixed everything was
fine on that update, then, after two small updates, it broke again! I thought
the bug I subscribed at the time wasn't a duplicate.
--
ma
I can't boot my laptop anymore. I had done the suggested workaround
*before* the update. Today morning 10:00 am pacific I updated my machine
and can't boot anymore. First, it gets stuck on "loading hardware
drivers...", then when I force it to skip that it gets stuck starting
the cups daemon.
What
Ok I do have a clue. It seems to be the new kernel update "...-16"
causing the problem. If I boot using the old kernel image "...-15"
everything works ok!
--
mac80211 "master" interface matches existant persistent network rules
https://bugs.launchpad.net/bugs/183968
You received this bug notifica
Scott,
I've already followed that advice and deleted the 70-persistent-net.rules file
by hand. Could you please tell us a little more about what effect deleting it
might have, and how one can solve that problem for those who already have done
it.
Arnab.
--
mac80211 "master" interface matches
If you deleted it, there's no way to get it back.
Deleting it will cause your interface names to change on the next
reboot; thus any manual configuration for your network will be lost or
(worse) confused between the different cards.
On a desktop machine with Network Manager, this tends not to mat
** Summary changed:
- [GUTSY] interface not completely renamed with iwl3945 module
+ mac80211 "master" interface matches existant persistent network rules
** Changed in: udev (Ubuntu)
Importance: Undecided => Critical
Assignee: (unassigned) => Scott James Remnant (keybuk)
Target: N
The previous persistent network rules were generated _without_
ATTR{type}=="1" so would match any device with the right MAC address.
Changing to mac80211 for many devices in 8.04 means that these devices
have gained an additional "wmaster0" control device that has the same
MAC address.
Udev will
Confirmed that deleting the old "# PCI device" entry from 70-persistant-
net.rules and removing/reinserting the module will correct the problem.
Seems to be an error that occurs when switching from ipw3945 to iwl3945
(I think this occured when upgrading Gutsy to Hardy).
Thanks wvengen for that li
For the record, the 70-persistant-net.rules diff in an automatic upgrade
test between a gutsy->hardy upgrade (+++) and a fresh install (---):
-# PCI device 0x10ec:0x8139 (8139cp)
-SUBSYSTEM=="net", ACTION=="add", ATTR{type}=="1", NAME="eth0"
+# PCI device 0x10ec:0x8139 (8139too)
+SUBSYSTEM=="net",
I am having the same problems on my Lenovo X61. But there are further
issues; Once the desktop has started the wireless does work.
However, AFTER COMING BACK FROM SUSPEND the wireless is gone! The only
way to get it back is to restart the machine. Restarting X etc. does not
do the trick.
--
mac8
Ashkay,
This is fixed by changing "/etc/udev/rules.d/70-persistent-net.rules" as
shown at http://wiki.debian.org/iwlwifi or as described above. It worked
on my Lenovo T60p and fixed both the boot delay and the problem on
resume from suspend.
--
mac80211 "master" interface matches existant persis
** Description changed:
Binary package hint: udev
My wifi interface is currently called "wlan0_rename", which indicates
that the interface renaming was only half-done.
This box was installed with gutsy, and upgraded to hardy every couple of
days.
-- snip --
** Description changed:
Binary package hint: udev
My wifi interface is currently called "wlan0_rename", which indicates
that the interface renaming was only half-done.
This box was installed with gutsy, and upgraded to hardy every couple of
days.
-- snip --
Confirmed on an IBM T60 and a Dell per-load E1505N both upgraded to hardy.
Both have the Intel IPW3945 chips. Known working under gutsy on same
hardware so this is a regression. Also on a T61P and an X61 both with
Atheros hardware on hardy no problems.
I believe this is critical to fix before re
This bug is broadly confirmed and is already tracked as critical for the
release, with work on resolving it already in progress. There is no
need for further confirmations of the bug.
--
mac80211 "master" interface matches existant persistent network rules
https://bugs.launchpad.net/bugs/183968
This bug was fixed in the package udev - 117-6
---
udev (117-6) hardy; urgency=low
* Automatically add ADDR{type}=="1" to 70-persistent-net.rules rules
where we can or at least add a useful comment where the user has written
their own rule that's broken in the same way. LP:
Did you follow the workaround in the bug description? The bug fix does
not help people who upgraded to Hardy before the bug was fixed. Please
try the following:
1. sudo rm /etc/udev/rules.d/70-persistent-net.rules
2. Reboot
/etc/udev/rules.d/70-persistent-net.rules should have been regenerated
The bug still happens to me on up-to-date hardy amd64!
I have an ipw3945 and have no wireless after resume!
--
mac80211 "master" interface matches existant persistent network rules
https://bugs.launchpad.net/bugs/183968
You received this bug notification because you are a member of Ubuntu
Bugs, w
Ok, works fine again. :)
Sorry about the inconvenience and thanks for the reply.
What confused me was that right after the bug was marked fixed everything was
fine on that update, then, after two small updates, it broke again! I thought
the bug I subscribed at the time wasn't a duplicate.
--
ma
I can't boot my laptop anymore. I had done the suggested workaround
*before* the update. Today morning 10:00 am pacific I updated my machine
and can't boot anymore. First, it gets stuck on "loading hardware
drivers...", then when I force it to skip that it gets stuck starting
the cups daemon.
What
Ok I do have a clue. It seems to be the new kernel update "...-16"
causing the problem. If I boot using the old kernel image "...-15"
everything works ok!
--
mac80211 "master" interface matches existant persistent network rules
https://bugs.launchpad.net/bugs/183968
You received this bug notifica
Scott,
I've already followed that advice and deleted the 70-persistent-net.rules file
by hand. Could you please tell us a little more about what effect deleting it
might have, and how one can solve that problem for those who already have done
it.
Arnab.
--
mac80211 "master" interface matches
If you deleted it, there's no way to get it back.
Deleting it will cause your interface names to change on the next
reboot; thus any manual configuration for your network will be lost or
(worse) confused between the different cards.
On a desktop machine with Network Manager, this tends not to mat
This is not fixed for me. When I resume from suspend to ram, my network is a
chaos, iwconfig shows eth0_rename as wifi, eth1 is not wifi anymore, ifdown and
ifups, /etc/init.d/network restart, nothing. I need to reboot.
ipw2200 and hardy uptodate (except kernel, version 14, could it be the
prob
Liken: if you still have problems, then you have obviously experienced a
different bug. Please file a new bug and be sure to attach output of
"ifconfig -a" and the contents of /etc/udev/rules.d/70-persistent-
net.rules
--
mac80211 "master" interface matches existant persistent network rules
http
Scott: I did it. Bug #213158
But Greg Michalec says it may be a duplicate of this. I attach in later bug the
files you indicate.
--
mac80211 "master" interface matches existant persistent network rules
https://bugs.launchpad.net/bugs/183968
You received this bug notification because you are a me
** Summary changed:
- [GUTSY] interface not completely renamed with iwl3945 module
+ mac80211 "master" interface matches existant persistent network rules
** Changed in: udev (Ubuntu)
Importance: Undecided => Critical
Assignee: (unassigned) => Scott James Remnant (keybuk)
Target: N
The previous persistent network rules were generated _without_
ATTR{type}=="1" so would match any device with the right MAC address.
Changing to mac80211 for many devices in 8.04 means that these devices
have gained an additional "wmaster0" control device that has the same
MAC address.
Udev will
Confirmed that deleting the old "# PCI device" entry from 70-persistant-
net.rules and removing/reinserting the module will correct the problem.
Seems to be an error that occurs when switching from ipw3945 to iwl3945
(I think this occured when upgrading Gutsy to Hardy).
Thanks wvengen for that li
For the record, the 70-persistant-net.rules diff in an automatic upgrade
test between a gutsy->hardy upgrade (+++) and a fresh install (---):
-# PCI device 0x10ec:0x8139 (8139cp)
-SUBSYSTEM=="net", ACTION=="add", ATTR{type}=="1", NAME="eth0"
+# PCI device 0x10ec:0x8139 (8139too)
+SUBSYSTEM=="net",
I am having the same problems on my Lenovo X61. But there are further
issues; Once the desktop has started the wireless does work.
However, AFTER COMING BACK FROM SUSPEND the wireless is gone! The only
way to get it back is to restart the machine. Restarting X etc. does not
do the trick.
--
mac8
Ashkay,
This is fixed by changing "/etc/udev/rules.d/70-persistent-net.rules" as
shown at http://wiki.debian.org/iwlwifi or as described above. It worked
on my Lenovo T60p and fixed both the boot delay and the problem on
resume from suspend.
--
mac80211 "master" interface matches existant persis
** Description changed:
Binary package hint: udev
My wifi interface is currently called "wlan0_rename", which indicates
that the interface renaming was only half-done.
This box was installed with gutsy, and upgraded to hardy every couple of
days.
-- snip --
** Description changed:
Binary package hint: udev
My wifi interface is currently called "wlan0_rename", which indicates
that the interface renaming was only half-done.
This box was installed with gutsy, and upgraded to hardy every couple of
days.
-- snip --
Confirmed on an IBM T60 and a Dell per-load E1505N both upgraded to hardy.
Both have the Intel IPW3945 chips. Known working under gutsy on same
hardware so this is a regression. Also on a T61P and an X61 both with
Atheros hardware on hardy no problems.
I believe this is critical to fix before re
This bug is broadly confirmed and is already tracked as critical for the
release, with work on resolving it already in progress. There is no
need for further confirmations of the bug.
--
mac80211 "master" interface matches existant persistent network rules
https://bugs.launchpad.net/bugs/183968
This bug was fixed in the package udev - 117-6
---
udev (117-6) hardy; urgency=low
* Automatically add ADDR{type}=="1" to 70-persistent-net.rules rules
where we can or at least add a useful comment where the user has written
their own rule that's broken in the same way. LP:
Did you follow the workaround in the bug description? The bug fix does
not help people who upgraded to Hardy before the bug was fixed. Please
try the following:
1. sudo rm /etc/udev/rules.d/70-persistent-net.rules
2. Reboot
/etc/udev/rules.d/70-persistent-net.rules should have been regenerated
The bug still happens to me on up-to-date hardy amd64!
I have an ipw3945 and have no wireless after resume!
--
mac80211 "master" interface matches existant persistent network rules
https://bugs.launchpad.net/bugs/183968
You received this bug notification because you are a member of Ubuntu
Bugs, w
Ok, works fine again. :)
Sorry about the inconvenience and thanks for the reply.
What confused me was that right after the bug was marked fixed everything was
fine on that update, then, after two small updates, it broke again! I thought
the bug I subscribed at the time wasn't a duplicate.
--
ma
I can't boot my laptop anymore. I had done the suggested workaround
*before* the update. Today morning 10:00 am pacific I updated my machine
and can't boot anymore. First, it gets stuck on "loading hardware
drivers...", then when I force it to skip that it gets stuck starting
the cups daemon.
What
Ok I do have a clue. It seems to be the new kernel update "...-16"
causing the problem. If I boot using the old kernel image "...-15"
everything works ok!
--
mac80211 "master" interface matches existant persistent network rules
https://bugs.launchpad.net/bugs/183968
You received this bug notifica
Scott,
I've already followed that advice and deleted the 70-persistent-net.rules file
by hand. Could you please tell us a little more about what effect deleting it
might have, and how one can solve that problem for those who already have done
it.
Arnab.
--
mac80211 "master" interface matches
If you deleted it, there's no way to get it back.
Deleting it will cause your interface names to change on the next
reboot; thus any manual configuration for your network will be lost or
(worse) confused between the different cards.
On a desktop machine with Network Manager, this tends not to mat
This is not fixed for me. When I resume from suspend to ram, my network is a
chaos, iwconfig shows eth0_rename as wifi, eth1 is not wifi anymore, ifdown and
ifups, /etc/init.d/network restart, nothing. I need to reboot.
ipw2200 and hardy uptodate (except kernel, version 14, could it be the
prob
Liken: if you still have problems, then you have obviously experienced a
different bug. Please file a new bug and be sure to attach output of
"ifconfig -a" and the contents of /etc/udev/rules.d/70-persistent-
net.rules
--
mac80211 "master" interface matches existant persistent network rules
http
Scott: I did it. Bug #213158
But Greg Michalec says it may be a duplicate of this. I attach in later bug the
files you indicate.
--
mac80211 "master" interface matches existant persistent network rules
https://bugs.launchpad.net/bugs/183968
You received this bug notification because you are a me
** Summary changed:
- [GUTSY] interface not completely renamed with iwl3945 module
+ mac80211 "master" interface matches existant persistent network rules
** Changed in: udev (Ubuntu)
Importance: Undecided => Critical
Assignee: (unassigned) => Scott James Remnant (keybuk)
Target: N
The previous persistent network rules were generated _without_
ATTR{type}=="1" so would match any device with the right MAC address.
Changing to mac80211 for many devices in 8.04 means that these devices
have gained an additional "wmaster0" control device that has the same
MAC address.
Udev will
Confirmed that deleting the old "# PCI device" entry from 70-persistant-
net.rules and removing/reinserting the module will correct the problem.
Seems to be an error that occurs when switching from ipw3945 to iwl3945
(I think this occured when upgrading Gutsy to Hardy).
Thanks wvengen for that li
For the record, the 70-persistant-net.rules diff in an automatic upgrade
test between a gutsy->hardy upgrade (+++) and a fresh install (---):
-# PCI device 0x10ec:0x8139 (8139cp)
-SUBSYSTEM=="net", ACTION=="add", ATTR{type}=="1", NAME="eth0"
+# PCI device 0x10ec:0x8139 (8139too)
+SUBSYSTEM=="net",
I am having the same problems on my Lenovo X61. But there are further
issues; Once the desktop has started the wireless does work.
However, AFTER COMING BACK FROM SUSPEND the wireless is gone! The only
way to get it back is to restart the machine. Restarting X etc. does not
do the trick.
--
mac8
Ashkay,
This is fixed by changing "/etc/udev/rules.d/70-persistent-net.rules" as
shown at http://wiki.debian.org/iwlwifi or as described above. It worked
on my Lenovo T60p and fixed both the boot delay and the problem on
resume from suspend.
--
mac80211 "master" interface matches existant persis
** Description changed:
Binary package hint: udev
My wifi interface is currently called "wlan0_rename", which indicates
that the interface renaming was only half-done.
This box was installed with gutsy, and upgraded to hardy every couple of
days.
-- snip --
** Description changed:
Binary package hint: udev
My wifi interface is currently called "wlan0_rename", which indicates
that the interface renaming was only half-done.
This box was installed with gutsy, and upgraded to hardy every couple of
days.
-- snip --
Confirmed on an IBM T60 and a Dell per-load E1505N both upgraded to hardy.
Both have the Intel IPW3945 chips. Known working under gutsy on same
hardware so this is a regression. Also on a T61P and an X61 both with
Atheros hardware on hardy no problems.
I believe this is critical to fix before re
This bug is broadly confirmed and is already tracked as critical for the
release, with work on resolving it already in progress. There is no
need for further confirmations of the bug.
--
mac80211 "master" interface matches existant persistent network rules
https://bugs.launchpad.net/bugs/183968
This bug was fixed in the package udev - 117-6
---
udev (117-6) hardy; urgency=low
* Automatically add ADDR{type}=="1" to 70-persistent-net.rules rules
where we can or at least add a useful comment where the user has written
their own rule that's broken in the same way. LP:
Did you follow the workaround in the bug description? The bug fix does
not help people who upgraded to Hardy before the bug was fixed. Please
try the following:
1. sudo rm /etc/udev/rules.d/70-persistent-net.rules
2. Reboot
/etc/udev/rules.d/70-persistent-net.rules should have been regenerated
The bug still happens to me on up-to-date hardy amd64!
I have an ipw3945 and have no wireless after resume!
--
mac80211 "master" interface matches existant persistent network rules
https://bugs.launchpad.net/bugs/183968
You received this bug notification because you are a member of Ubuntu
Bugs, w
Ok, works fine again. :)
Sorry about the inconvenience and thanks for the reply.
What confused me was that right after the bug was marked fixed everything was
fine on that update, then, after two small updates, it broke again! I thought
the bug I subscribed at the time wasn't a duplicate.
--
ma
I can't boot my laptop anymore. I had done the suggested workaround
*before* the update. Today morning 10:00 am pacific I updated my machine
and can't boot anymore. First, it gets stuck on "loading hardware
drivers...", then when I force it to skip that it gets stuck starting
the cups daemon.
What
Ok I do have a clue. It seems to be the new kernel update "...-16"
causing the problem. If I boot using the old kernel image "...-15"
everything works ok!
--
mac80211 "master" interface matches existant persistent network rules
https://bugs.launchpad.net/bugs/183968
You received this bug notifica
1 - 100 of 156 matches
Mail list logo
