I believe this may be a kernel regression. I can repro on 15.04 with
sddm by installing any 4.x series kernel, haven't done any bisecting,
and can't find anything interesting in dmesg (when I can switch to a vc
sucessfully after X starts but fails to output anything), but with a
single change from
*** This bug is a duplicate of bug 1193205 ***
https://bugs.launchpad.net/bugs/1193205
** This bug has been marked a duplicate of bug 1193205
dhcp IPv6 sets accept_ra to 0 and doesn't get IPv6 route
--
You received this bug notification because you are a member of Desktop
Packages, which
Please re-open - this is confirmed broken again in Trusty.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/936712
Title:
NetworkManager should put IPv6 DNS servers before IPv4
On 29/05/12 07:06, Thomas Hood wrote:
> We aren't getting duplicates of #1000244 so it's probably not a
> frequently occurring problem. If resolvconf were systematically
> failing to create the resolv.conf symlink we'd be getting hundreds of
> reports about it. Based on what we know now it's most p
@jdthood - what's required for this?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1000244
Title:
Network Manager does not populate resolv.conf
Status in “network-manager” p
On 28/05/12 08:05, Sergio Callegari wrote:
> My idea for a heuristic was indeed extremely simple. In case the first
> name server has a non public ip address, auto switch to strict order.
That may work in many scenarios, but not if the address happens to be
routable, and only until IPv6 is prevale
On 27/05/12 17:58, Simon Kelley wrote:
> Executive summary: non-equivalent servers are bad, but --strict-order
> will make things work, for the same value of "work" as the libc
> resolver). Non-equivalent servers are bad, so don't encourage their
> use by making --strict-order the default.
To be
@jdthood - I mentioned that resolv.conf was missing in #1000244, and
since it wasn't being populated correctly, so if it's not being
populated, and you disable dnsmasq, that would result in no
resolution...
--
You received this bug notification because you are a member of Desktop
Packages, which
@callegar - that's all well and good, and I agree, but this is unlikely
to get solved in dnsmasq (though that would be ideal).
@jdthood:
1. Would have been the sane option for an LTS release (and server installs
should use traditional resolv.conf model, if that's not the case)
2. Well, commenting
I believe this is related to the various other resolvconf issues.
Search domains are also not respected when assigned via DHCP.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/507
@jdthood:
- /etc/resolv.conf did not exist in any form on a clean install, prior to
dpkg-reconfiguring resolvconf
- DNS resolution worked with the following caveats:
- search domains offered via DHCP were not honored
- random order nameserver querying and caching by dnsmasq results in
persist
Unfortunately I've now 'fixed' mine by disabling dnsmasq and
reconfiguring resolvconf, but this behaviour was exhibited on a clean
install for me.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.lau
Short-term fix is to `dpkg-reconfigure resolvconf` and enable the option
to 'Prepare /etc/resolv.conf for dynamic updates' or whatever it says.
Then, `resolvconf --enable-updates` (the latter may not be needed).
Also, your search domain won't work if you're using the dnsmasq method
in networkmanag
Thanks for the rapid fix guys, appreciated.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nautilus in Ubuntu.
https://bugs.launchpad.net/bugs/868032
Title:
nautilus progress window marked skipped, not managed by gnome-shell
Status i
I've compiled the nautilus-3.2 branch from Gnome git and still don't get
any notifications. I'll try building master, and if still no luck, I'll
do some debugging and try to find out why, and maybe go back to
upstream.
--
You received this bug notification because you are a member of Desktop
Pac
@julo - They're separate bugs that exacerbate each other. If one
worked, the other would not be such a problem. That said, I've tried
building 3.2.1 with all Debian/Ubuntu patches removed, and I still get
no notification, so #849733 must either be an upstream bug (the linked
issue from bug #84973
*** This bug is a duplicate of bug 868032 ***
https://bugs.launchpad.net/bugs/868032
This is not a duplicate of bug #868032, though it is exacerbated by it.
This is about a lack of copy progress in the notification area, rather
than the copy dialog window skip flag.
--
You received this bug
@didrocks - thanks for the explanation, I'll look at producing a patch
for this. I must admit, I didn't search the changelog, but commenting
the patches themselves (as Debian do) makes this round-trip a lot more
accessible and clear.
@seb128 - a quick post to say this patch was related to #784804
It's a confirmed issue set to low priority, but with medium impact - the
incongruence is what prompted the additional comments. Particularly
when the fix is simply to remove a completely unnecessary Ubuntu-
specific patch.
--
You received this bug notification because you are a member of Desktop
Absolutely - this is absolutely ridiculous.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nautilus in Ubuntu.
https://bugs.launchpad.net/bugs/868032
Title:
nautilus progress window marked skipped, not managed by gnome-shell
Status i
20 matches
Mail list logo
