Public bug reported:
problem occurred becauuse symlink /initrd.imgpointed to old disco
initrd, resolved by forcibly recreating it, for now...?
ProblemType: Package
DistroRelease: Ubuntu 19.10
Package: initramfs-tools 0.133ubuntu10
ProcVersionSignature: Ubuntu 5.3.0-19.20-generic 5.3.1
Uname:
as of this morning's updates, this problem seems to have disappeared.
I've been able to log out and back in several times to my ubuntu wayland
session, at least on my i915 machine (the dell laptop).
nb: this morning's updates updated gnome-session-bin and ubuntu-session
to 3.33.92-1ubuntu1, gdm3
My point regarding gnome-session-wayland.target is that if we're seeing
different filenames for that file (assuming they're functionally the
same) and mine definitely comes from gnome-session-bin, does that
suggest we're running different gnome-session-bin versions? And seeing
as you're not
minor contextual note: It took me a little while to get the other
machine, ssh in (offending ssh key to resolve), call up this page to
remind me of the exact commands. The point of which is to say, these
weren't taken *immediately* after the logout, but at least a minute
later, certainly beyond
journalctl -b output as attached
loginctl as below:
rachel in ~ at rainbow
➜ loginctl
SESSION UID USER SEAT TTY
1 1000 rachel seat0 tty2
3 1000 rachel pts/0
2 sessions listed.
rachel in ~ at rainbow
➜ loginctl show-session 1
Id=1
User=1000
Name=rachel
Timestamp=Tue
It is definitely /usr/lib/systemd/user-gnome-session-wayland.target.
dpkg -S on that file gives gnome-session-bin which is on version
3.33.90-2ubuntu2. dpkg -S on the .service file gives no match.
This problem didn't start on upgrade to the 5.2 kernels, which happened
a few weeks(?) earlier, but
With --systemd removed as directed I still ended up stuck on a black
screen, except this time it had a flashing white text cursor in the top
left.
(BTW reboots occurred between each test, somewhat perforce...)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded
I tried (just now) deliberately leaving it longer than 30 seconds to
come back after a logout. In fact left it longer than 60 seconds.
Nothing happening. I wasn't logged in via ssh as well at the time (I
hadn't thought the systemd --user instance was related to the ssh
session before so presumably
ditto upgrading in two steps bionic->cosmic->disco
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to shared-mime-info in
Ubuntu.
https://bugs.launchpad.net/bugs/1827099
Title:
package shared-mime-info 1.10-1 failed to
trying to get that screenshot was how i discovered it *does* appear to
be retaining stuff for a while at least. :-) I'll try to do so next time
I'm there.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in
actually i think cookies are being held for at least a while, as,
sitting in the cafe, I can log out and in, and even reboot, and get
logged directly back into the hotspot. But when I come back the next day
I'm asked if I even want to accept cookies. It's that being asked to
accept cookies every
i mean literally http web cookies from the portal page. if you ignore
the network login app (as was the case before it worked reliably), it
shows up in your normal browser. This does remember cookies, so you
don't get asked if you want to accept cookies every time you go there.
What the portal
Follow up comment on the upstream bug pointed to a commit where it
suggests the rp_filter default should actually now be 2 rather than 1:
https://github.com/systemd/systemd/commit/230450d4e4f1f5fc9fa4295ed9185eea5b6ea16e
Think at this point I need to just let you guys talk amongst yourself.
:-)
Reporting back on this:
The opinion there seems to be that the problem is down to the sys
net.ipv4.conf.*.rp_filter values being set to 1 instead of defaulting to
0. This is done in the procps package, and I'm guessing is the way it is
as a protection against IP spoofing. kernel doc page I was
Public bug reported:
As per subject. This package defines the file
/usr/lib/NetworkManager/conf.d/20-connectivity-ubuntu.conf, which
defines the uri for the connectivity check to be http://connectivity-
check.ubuntu.com
This hostname does not resolve to an IPv6 address. Therefore, even if
the
As it recurred again today and showed no signs of correcting itself like
it did on Friday, I went ahead and reported it upstream, here:
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/116
--
You received this bug notification because you are a member of Ubuntu
Touch seeded
Noted. I see there's no report of anything similar already, and if it
was the sort of problem it looked like to me, people would be screaming
blue murder about it, so I think I'll wait and see if it recurs or
becomes an ongoing problem, rather than a one-off. Maybe my LAN was
having a bad hair
Public bug reported:
Actually this might be a heisenbug. I've had an issue with this all
morning since network-manager got an update this morning, but just now
*while this bug was being submitted* it decided to correct itself.
What I was getting was, on a machine (Dell XPS 13 9370) with WiFi and
FWIW I have *not* seen this since upgrading to Bionic. It was probably
fixed sooner, when they said it was, but at some point I gave up on
Artful because of various gnome-shell problems including this, went back
to Mac, and tried again with a fresh Bionic install, where they almost
all seem to
belately thought of trying: running sudo update-initramfs -k all -c
produced no errors for both currently installed kernels:
rachel@spitfire:~$ sudo update-initramfs -k all -c
update-initramfs: Generating /boot/initrd.img-4.15.0-21-generic
update-initramfs: Generating
Public bug reported:
kernel upgrade appeared to go OK actually; on the *second* reboot after
that, this appeared after login.
ProblemType: Package
DistroRelease: Ubuntu 18.04
Package: initramfs-tools 0.130ubuntu3
ProcVersionSignature: Ubuntu 4.15.0-21.22-generic 4.15.17
Uname: Linux
Public bug reported:
There's an ongoing issue with gnome-shell crashing during or on exit
from screen lock. I am no longer able to report when this happens
because apport silently refuses to send the bug report.
If the automatic whoopsie dialog opens at all (it doesn't, often), and I
click to
Public bug reported:
Today for the first time, and coincidentally looking for a different
setting, I went to the Settings->Privacy dialogue. I was also
(coincidentally for a different reason, relating to #1720149) already
tailing /var/log/syslog to a terminal.
Immediately on opening that
confirmed that environment variable set before opening the app works.
Whose project do we complain at that QT apps don't (or rather, only
inconsistently) follow this setting?
(For instance, when I set that in my ~/.profile, a different QT5 app, in which
originally *some* of its widgets are
Public bug reported:
The attached screenshot should say it all, showing it in comparison with
Firefox and, indeed, the rest of the Unity desktop.
Basically, on a 4K display, with a native resolution of 3840x2160, but
with the scaling factor set to 2, and Scale all window contents set on,
*most*
25 matches
Mail list logo
