Glad to see this is "new" *sarcasm*. I've moved to ctwm. There isn't
much refuge left unless you conform to single GPU/XScreen Wayland/randr
setups. Even Evolution relies on GTK which makes ancient "pure" xorg
tools or KDE the only choice.
--
You received this bug notification because you are a
Sadly this will *never* be fixed unless XFCE dumps GTK as this is caused
by GTK. Since GTK 3.something GTK ignores all XScreens and assumes just
one causing the problem.
Current KDE works for Multi-XScreen/GPU but has some idiotic maximize
behavior. The only thing I've found really functional is
No it's not, he HAS a nVidia card, that is the point, DUAL GPU, not
single brand of GPU. Originally the bug seemed to be the driver but it
was coincidence that the GTK updates arrived with the same update making
it look like the driver was to blame. His issue is 100% THE issue. Dual
GPU of any
I've come to find out this is 100% Gnomes fault. Shortly after GTK3 was
finalized they ignorantly nuked the enumeration of XScreens. Because
Ubuntu/Debian is slow to update this problem went semi-undetected for
years until we had to move to a system where those changes/packages had
been (forced)
** Description changed:
systemd.mount constantly unmounts an in use sshfs drive!
Sep 09 11:20:01 $HOSTNAME systemd[4613]: pathtomount.mount: Succeeded.
░░ Subject: Unit succeeded
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ The unit UNIT has successfully
** Description changed:
systemd.mount constantly unmounts an in use sshfs drive!
- mount has successfully entered the 'dead' state.
+ Sep 09 11:20:01 $HOSTNAME systemd[4613]: pathtomount.mount: Succeeded.
+ ░░ Subject: Unit succeeded
+ ░░ Defined-By: systemd
+ ░░ Support:
** Description changed:
systemd.mount constantly unmounts an in use sshfs drive!
mount has successfully entered the 'dead' state.
+
+ Change my kernel and the issue *seems* to have subsided.
ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package: systemd 247.3-3ubuntu3.4
** Description changed:
systemd.mount constantly unmounts an in use sshfs drive!
mount has successfully entered the 'dead' state. -What the hell I WAS
USING IT!
I had this drive originally in auto.sshfs but when the application I was
using accessing files on the drive just up and
** Description changed:
systemd.mount constantly unmounts an in use sshfs drive!
mount has successfully entered the 'dead' state. -What the hell I WAS
USING IT!
I had this drive originally in auto.sshfs but when the application I was
using accessing files on the drive just up and
** Description changed:
systemd.mount constantly unmounts an in use sshfs drive!
mount has successfully entered the 'dead' state. -What the hell I WAS
USING IT!
I had this drive originally in auto.sshfs but when the application I was
using accessing files on the drive just up and
Public bug reported:
systemd.mount constantly unmounts an in use sshfs drive!
mount has successfully entered the 'dead' state. -What the hell I WAS
USING IT!
I had this drive originally in auto.sshfs but when the application I was
using accessing files on the drive just up and vanished I
Well I'm less concerned with getting the old GPU to work (again just a
test system trying to debug dual GPU in general) as I am getting my NEW
GPU's on my workstation working in 21.04 and future releases. Right now
Dual GPU is horribly broken and it's spans tons huge swathes of the
system. My set
This machine is a frankenstien to help debug the issues with my main
workstation. I need to upgrade but dual GPU is horribly broken on across
all flavors and even non-Ubuntu/Debian distros.
I was explicitly testing how the system functions with no xorg.conf
between 2 separate GPU's. Yes the
Public bug reported:
Changing display settings hard locks the machine (no reisub save).
Installing nouveau-firmware allows changes to be made without hard lock
ups but the screen using nouveau draws the mouse cursor and will launch
apps on it but does not draw anything on screen. Dmesg is flooded
Enabling updates to the install of 21.04 fixes the crashing and ends up
more "working" than a full Ubuntu/Gnome DE. However you can not control
theming or decorations on anything outside the base XScreen. Launching
applications always default to the base XScreen rather than the active
Problem still exists in 21.04 nv470.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1822937
Title:
NVIDIA settings won't write to /etc/xorg
To manage notifications about this bug go to:
Public bug reported:
Multi XScreen configuration ignores theming on all XScreens other than
0.0.
Launching xfce4-settings-manager on the desired XScreen and settings
appearance only changes on DISPLAY=:0.0.
Command line is also ineffective in that is works but only affects DISPLAY=:0.0.
** Description changed:
installed shim-signed package post-installation script subprocess
returned error exit status 1
+
+ I've had this on Xubuntu 20.04 and Kubuntu 21.04. Installation get to
+ the end, errors with the above and the installer kinda crashes rather
+ than allowing input.
Public bug reported:
installed shim-signed package post-installation script subprocess
returned error exit status 1
ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package: ubuntu-release-upgrader-core 1:21.04.10
ProcVersionSignature: Ubuntu 5.11.0-16.17-generic 5.11.12
Uname: Linux
Yeah this is insane. I've just grabbed some bug reports for this and in
my testing for it I enabled a second XScreen on the GPU that was
"working" with a single XScreen...kablam! System go poof! Never mind if
I enable XScreens for my other GPU's!
Given your bug report has been open for at least a
No thank you for taking the time to check into this and give me some
extra place to peek for errors outside dmesg/syslog. I'm stressing hard
with no way to upgrade outside losing a massive chunk of my
hardware/workflow.
I will have to reinstall to try these things. Report back in a few.
--
You
Sadly this seems to be what I'm dealing with. Everything newer than
18.04 breaks once you have a second XScreen/GPU.
https://bugs.launchpad.net/ubuntu/+source/xfwm4/+bug/1942477
Seems to be bigger than the DE tough because I've tried a few different
distros (not just debian) and various DE's all
** Summary changed:
- XFWM4 (and most all of any DE crash/loop on login)
+ XFWM4 (and most all of any DE crash/loop on login with more than one XScreen)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Public bug reported:
Fresh install of 20.04 or 21.04 both yield the same results/issues.
Creating a second XScreen causes everything to crash and the system to
become crippled and unusable.
[ 50.355096] traps: xfwm4[1387] trap int3 ip:7fd80682a295 sp:7ffe4072be80
error:0 in
[ 46.504672] xfce4-session[1220]: segfault at 0 ip 7f52d3e7fb7e sp
7ffd390d35f8 error 4 in libc-2.31.so[7f52d3d1e000+178000]
I had added a Firefox complaint but it looks to have been removed or
Firefox didn't submit correctly before it died. Basically says two cards
from the same vendor
** Description changed:
Install 20.04 or 21.04, install the proprietary drivers. Add a second
XScreen so you can enable the primary GPU and its screens and
applications start to crash. System is unusable.
-
- [ 46.504672] xfce4-session[1220]: segfault at 0 ip 7f52d3e7fb7e sp
-
** Description changed:
- Install 20.04 or 21.04...survive the open source drivers crashing and
- bugging out (or hard locking the system) to install the proprietary
- drivers. Add a second XScreen so you can enable the primary GPU and its
- screens and applications start to crash. You can't
** Description changed:
Install 20.04 or 21.04...survive the open source drivers crashing and
bugging out (or hard locking the system) to install the proprietary
drivers. Add a second XScreen so you can enable the primary GPU and its
screens and applications start to crash. You can't
Public bug reported:
Install 20.04 or 21.04...survive the open source drivers crashing and
bugging out (or hard locking the system) to install the proprietary
drivers. Add a second XScreen so you can enable the primary GPU and its
screens and applications start to crash. You can't actually use
As I said the proprietary drivers don't work either on either 20.04 or
21.04. I will try to do another install and switch to the proprietary
for another bug report shortly. I don't think there are any errors with
the proprietary though, the system is just unusable if you enable the
primary GPU
Public bug reported:
This is a rather huge issue and I'm not 100% if it's xorg or a kernel
issue. I have tons of errors from the DE, Nouveau drivers and various
other things. In 16.04.X and 18.04.X everything has worked fine. When I
tried to upgrade to 20.04 setting up my screens either locks the
Is anything going on with this? It's been quite a while. I recently
retested and the r8169 still will not wake for 80+ seconds upon wake.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1752772
Title:
I tried adding the module to MODULES_WHITELIST and the prefix to
SKIP_INTERFACES to my acpi-support...no dice, still takes approx 80
seconds before the interface is brought back up.
[ +0.003247] PM: suspend exit
[ +0.084034] libphy: r8169: probed
[ +0.000214] r8169 :22:00.0 eth0:
Perhaps should have added more info as I didn't notice someone with a
different adapter posting before me which may lead people to think I am
chiming in about the r8152 rather than the r8169.
Ubuntu 18.04.4 LTS
Linux $HOST 5.4.0-42-lowlatency #46~18.04.1-Ubuntu SMP PREEMPT Fri Jul
10 08:10:40
I'm affected too. Noticed a few months back after updates resuming from
suspend became obnoxiously slow, almost 2 minutes to resume the network
interface. Meanwhile the system is trying to remount network drives and
failing because there is no network so clearly the system isn't in sync
with
35 matches
Mail list logo
