Running APT evince 42.1-3 on stock Ubuntu 22.04/GNOME 42.0/Wayland.
My issue is Evince opening in a tiny window every time it's fired off;
this deployment was upgraded from 21.10, which didn't suffer from such
issue.
I attach below the output from `journalctl -f` while starting up Evince,
which
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1969896
Title:
Evince Document Viewer(42.0) does not remember last page in 22.04 and
opens in a tiny window when launched
To manage notifications
FWIW, I've just upgraded to 22.04 and the version of Evolution bundled
with it (3.44.0-1ubuntu1) doesn't suffer from this problem; so it
affects 21.10 only.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Public bug reported:
This morning the security patch USN-5394-1
(https://ubuntu.com/security/notices/USN-5394-1) deployed on my laptop
and following a reboot, I can no longer compose emails (or reply to
emails) using Evolution (3.40.4-1ubuntu2). The composition window is
blank. I'm on 21.10.
@enoriel - I've read carefully the info in this ticket; I'm still
contemplating the Hirsute to Impish upgrade and *really* glad I didn't
pull the trigger earlier!!
The bad news is that it seems clear that the original Impish kernel
(5.13.0-19) corrupted filesystems it ran against; thus running
Having just upgraded from Focal (w/ original 5.4 kernel) to Groovy
(5.8.0-44), this issue definitely seems to have regressed.
Does it require a new bug since this one is tagged "Focal"? That said
one of the above reports also claims that it affects the Focal 5.8
series. Could someone advise?
*** This bug is a duplicate of bug 1839658 ***
https://bugs.launchpad.net/bugs/1839658
Anyone who comes across this issue, resulting in denial of service from
neutron-server with the exceptions mentioned in the OP, it's reasonably
painless to workaround; simply delete the subnet(s) with NULL
Just to clarify, is it correct that this issue only affects systems
initially deployed with 20.04? On my 19.10 upgraded system, `grep -r`
didn't reveal anything suspicious. I'm sorry if this is obvious from
the launchpad metadata (it's not to me)
--
You received this bug notification because
@c-lobrano: Glad to see this issue is being addressed, thank you! I
can't imagine that it is Canonical's goal to restrict its user base to
people with perfectly calibrated monitors and/or working in darkened
rooms.
--
You received this bug notification because you are a member of Ubuntu
Bugs,
FWIW, I raised #1872488 with the same issue.
IMHO - admittedly "opinion" - this severely impairs usability; it should
be classed as an accessibility issue.
My monitor is a fairly high-end Eizo FlexScan EV2785. I have looked at
the screenshot attached to #1872488 on that, my laptop's screen and
Public bug reported:
IMHO the highlighting of the current app on the 20.04 task switcher
being dark gray over a black background (see attached screenshot) is
nearly impossible to distinguish.
This may be suitable for the "dark" theme variant (people working in
darkened rooms) but it should be
Same here, 20.04 beta, AMD Ryzen 7 PRO 3700U w/ Radeon Vega Mobile
(Thinkpad t495s), upgraded from 19.10.
I have the same list of 24 missing amdgpu modules as the previous
poster.
This bug really needs re-working and yet it's status is set to "Fix
Released" (which I can't seem to be able to
I have a brand new ThinkPad t495s (Ryzen 7 Pro 3700U) with a fresh Eoan
deployment, which exhibits exactly the behaviour described in this
ticket. AFAIK everything is up-to-date. Am I doing smth wrong or is
there an issue with this fix? Please let me know if I can provide
further evidence or
Issue definitely also occurs with stock Ubuntu GNOME DE (just did a
fresh install on a ThinkPad t495s with "AMD Ryzen 7 PRO 3700U w/ Radeon
Vega Mobile Gfx"; up-to-date kernel 5.3.0-26-generic and the issue
occurred twice within 12 hours of installing - once upon resuming and
the 2nd time just
Hi Daniel,
Thanks to the pointer. I now have 3.30.1-2ubuntu1.18.10.2 and it seems
the issue is resolved (not sure if this is the new version or the manual
fix below, which I applied thanks to your pointer).
I'd installed the Pop theme manually (through apt) atop stock 18.10.
The slightly
Hi Daniel, please see attached; apologies for delay. I hope the weird
"gnome-session-binary[4266]: CRITICAL: We failed, but the fail whale is
dead. Sorry" is a tell-tale sign?
Cheers
Christian
** Attachment added: "prevboot.txt"
** Description changed:
An upgrade to gnome-shell on 18.10 was recently released which made it
impossible for me to log in to my DE. Upon typing my password, the gdm
screen would disappear, only to re-appear a few seconds later. This was
not a password typo as I didn't get the usual msg
Public bug reported:
An upgrade to gnome-shell on 18.10 was recently released which made it
impossible for me to log in to my DE. Upon typing my password, the gdm
screen would disappear, only to re-appear a few seconds later. This was
not a password typo as I didn't get the usual msg to that
*** This bug is a duplicate of bug 1769819 ***
https://bugs.launchpad.net/bugs/1769819
FWIW, I am experiencing fairly regular X.org crashes at sleep resume
with my ThinkPad X1c5 (stock KabyLake Intel HD 620 iGPU) on 18.04
(currently running 4.15.0-36 but has been happening for a while).
+1 with i350 NICs (many of them so this is consistently reproducible).
We worked it around as follows (on the MAAS server):
cd /tmp
wget
http://archive.ubuntu.com/ubuntu/dists/xenial-updates/main/uefi/grub2-amd64/2.02~beta2-36ubuntu3.18/grubnetx64.efi.signed
cp -p grubnetx64.efi.signed
Just to clarify above comment from hans005: from what I can read here
his problem (#138, #145) was a completely different issue: standby with
nvidia GPU.
This regression relates to *hibernation* (not mere standby) and AFAIK,
has been experienced with a variety of GPUs (included Intel integrated
Same issue here, fresh install of stock Ubuntu 17.10(.1) on a ThinkPad
X1 Carbon gen5, kernel 4.13.0-25-generic, with LUKS-encrypted swap
partition sitting alongside the root partition. The same hardware/setup
worked fine on Zesty but as we know, that just went EoL.
Just to add: the machine
I'm on Zesty and my syslogs are chock-full of those sta.c:1523
stacktraces.
Below is the `lshw -c network` section that pertains to my wireless
card. This may or may not be related as it's a different wireless card;
or perhaps, rather it's an issue that affects multiple Intel cards?
My oldest
@tim-8aw3u04umo no installation issue here. I used: 'sudo apt update &&
sudo apt upgrade'.
uname -r reports "4.10.0-22-generic"
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1674838
Title:
kernel
Not a comment on the slow patching schedule but while we're waiting for
a proper release, those who prefer to use a released kernel might want
to switch to 4.10.0-13-generic. Several people here (myself included)
haven't had a crash for days using it and there is strong suspicion (see
#104) that
BTW for those who encounter this issue (as I've just had the pleasure
today), it might be useful to reboot your box using the "magic SysRq"
sequence since it's supposed to be more gentle than the power key:
https://en.wikipedia.org/wiki/Magic_SysRq_key
In order to enable this feature, I have this
Hi Joseph,
As previously reported:
4.10.0-15: affected
4.10.0-14: issue not experienced in over a week
Obviously "not experienced" doesn't mean the bug isn't present. All I
can say is that it was first experienced with 4.10.0-15.
--
You received this bug notification because you are a
My laptop (Kaby Lake) has 16 GB swap configured and I have encountered
the issue 5 times so far; see
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1682184/comments/27
for exact details, including which kernels were concerned.
--
You received this bug notification because you are a member
Same issue encountered 5 times so far:
Apr 9 19:28:51 [59352.218844] kernel BUG at
/build/linux-dfiP6t/linux-4.10.0/include/linux/swapops.h:129!
Apr 11 18:36:27 [ 1067.925360] kernel BUG at
/build/linux-Fk60NP/linux-4.10.0/include/linux/swapops.h:129!
Apr 11 18:41:21 [ 75.894177] kernel BUG
Hi @cascagrossa, just to clarify: my impression is that in order to
trigger the bug you'll need to suspend somewhere where the WLAN network
you want to connect to at resume time isn't available as it's the scan
aspect of things that appears to be inhibited. This is evidenced by the
fact that he
Also further to #60, I have put the following in mine (Thinkpad X1
Carbon 3) and it does indeed seem to fix the problem so far - been
testing over a few days:
/lib/systemd/system-sleep/wpasupplicant:
post) (sleep 3 ; /sbin/wpa_cli resume) & ;;
16.04.1 fresh install, kernel 4.4.0-59;
Fresh 16.04.1 install on ThinkPad X1 carbon 3 with stock Intel 7265
(802.11abgn) WiFi here; laptop also has a Sierra Wireless EM7345 4G LTE
WWAN integrate USB module.
Typical scenario: I use the WWAN when out and about, suspend the laptop,
come back to office and expect the laptop to re-connect
@Timo: ok thanks for letting me know but your terse reply eludes me
somewhat. Are you suggesting - despite similarities in symptoms and
context - that:
1. My problem is different therefore I need to raise a new one?
2. There is another bug to which I should attach this?
3. My contribution is
This has been happening to me for about ~2 months too: hangs, typically
after resuming from suspend, either immediately after resume or within a
couple of minutes. Hard power-cycle by holding down power button is
only way out (CTRL+ALT+F1 unresponsive and entire laptop appears
frozen).
Think
That mlx4.conf file is also present in the same form on 14.04 cloudimg,
which doesn't suffer from the issue. Or maybe the systemd module loader
interprets this differently?
BTW the workaround I've found is to add the following to
/etc/modprobe.d/blacklist.conf:
blacklist ib_iser
install ib_iser
Didn't mean to blame systemd-modules-load.service specifically; as you
point out, it's just where the smoking gun appears. I suppose the only
thing that's debatable is whether it should fail in these circumstances
and whether it would inhibit other, unrelated, modules to load? (that
would be bad)
Public bug reported:
On a number of VMs using Xenial daily builds 20160330 and 20160403, out
of the box (just after booting for the first time), the following
appears in dmesg at boot time:
systemd[1]: systemd-modules-load.service: Main process exited, code=exited,
status=1/FAILURE
systemd[1]:
@nacc,
I'm really sorry to pester as you must be v. busy at this point but is
there a definitive word on what's going to happen with 16.04 GA? It's
only 3 weeks away and people are having to plan out what release they'll
be deploying in the near future.
FWIW as a service provider, I'm squarely
@nacc,
I'm really sorry to pester as you must be v. busy at this point but is
there a definitive word on what's going to happen with 16.04 GA? It's
only 3 weeks away and people are having to plan out what release they'll
be deploying in the near future.
FWIW as a service provider, I'm squarely
39 matches
Mail list logo
