When the selected/renamed file is a directory: see Bug #1105232.
When the selected/renamed file is a directory: see Bug #1105232.
When the selected/renamed file is a directory: see Bug #1105232.
Had just opened Gedit, and the file chooser dialog from there. Had successfully selected one directory in the dialog, and the crash occurred when I clicked (I think) on the file name listing column. Couldn’t reproduce it again.
The system in question is currently out of use (and reproducing the bug isn’t straightforward), so I’ll let this one expire.
I have Trusty and Precise installations affected by this. For me just one refresh usually is enough to fix it though. Also, sometimes the blackening doesn’t happen straight away but only once I start scrolling the page down to the comments section.
I’ve made some progress. By setting up an xorg.conf with a modeline for the external display, I got graphics on the (lightdm) login screen to show up on it. But the login input fields weren’t on this screen (it was just the background), so this was further evidence that there’s monitor misdetection going on (greeter/lightdm happily thinks it’s displaying the input fields on the broken internal LCD).
So I further tweaked xorg.conf to force X to ignore the internal display, and now I’ve got a working login screen back on the external display. I’ll attach my xorg.conf below; it is a satisfactory workaround.
Further details: mouse cursor is briefly visible just prior to the black (login) screen. GDM does show up on the display, but in too big a resolution, so that I only get some of the grey background visible on screen and still have to log in blindly.
It occurred to me that with lightdm, the symptom appears as I would expect if it failed to do monitor detection properly and thinks it’s displaying the login screen on the (broken) internal display only. Well, apart from the funky ”login screen desktop background” phenomenon (which could be a separate issue though).
(Just to be clear: this same combination of broken internal + working external display did display the login screen correctly on the external one in Precise.)
This is a laptop with a broken internal display (”LVDS1” in xrandr output), and therefore connected to a working external LCD (”VGA1”).
After upgrading from Precise to Trusty, boot ends with a black screen (on the external display). The greeter sound effect is played. Typing my password (I’m the sole user) does log me in, and brings up the desktop on the display.
So the login functionality is there, just the visuals are missing. And they do flash by (corrupted) when the desktop is loading; if I set automatic login for myself, I get a desktop with the login screen as the background image (I’ll attach a screenshot).
There are existing, similar reports but all with subtle differences from this (such as Bug #1252748, where the user only gets black screen half the time) or too vague for me to claim to be the same issue with certainty (such as Bug #1242213). A lightdm restart (such as in Bug #969489) doesn’t fix this (i.e. black screen still after lightdm restart).
I’m not sure whether this is a lightdm issue or a unity-greeter one, so my reporting this against the latter is just a guess.
I currently have a 100% reliable recipe for reproducing this in 12.04: trying to restore a saved session of Trusty crashes VirtualBox 4.3.2 (from Oracle), after which Apport’s ”TypeError(Error(’Incorrect padding’,),)” pops up. (The recipe works also after removing crash files from /var/crash.)
Hi Christopher.
I was unable to test the Saucy images and the latest mainline kernel, as they refuse to boot/install on the Amilo due to lack of PAE support.
jani@kingugidora:~$ LC_ALL=C sudo dpkg –install linux-image-3.11.0-031100rc6-generic_3.11.0-031100rc6.201308181835_i386.deb
(Reading database … 818498 files and directories currently installed.)
Unpacking linux-image-3.11.0-031100rc6-generic (from linux-image-3.11.0-031100rc6-generic_3.11.0-031100rc6.201308181835_i386.deb) …
This kernel does not support a non-PAE CPU.
dpkg: error processing linux-image-3.11.0-031100rc6-generic_3.11.0-031100rc6.201308181835_i386.deb (–install):
subprocess new pre-installation script returned error exit status 1
Examining /etc/kernel/postrm.d .
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 3.11.0-031100rc6-generic /boot/vmlinuz-3.11.0-031100rc6-generic
run-parts: executing /etc/kernel/postrm.d/zz-update-grub 3.11.0-031100rc6-generic /boot/vmlinuz-3.11.0-031100rc6-generic
Errors were encountered while processing:
linux-image-3.11.0-031100rc6-generic_3.11.0-031100rc6.201308181835_i386.deb
I guess the only (unimportant) question remaining is how come I was able to boot -pae kernels on this very same device back in the pre-release times (3.2.0-[<23]) – perhaps those earlier kernels didn’t properly detect the lack of PAE?
The wireless now (with the current 3.2.0-52-generic #78-Ubuntu) seems to somehow work without wistron_btns.
I’m not sure how to deal with the tags & bug status in this case, so I’ll leave it to your discretion. If you have further ideas to test, I’ll be happy to provide, but closing this report (perhaps as ’Invalid’) is also fine by me.
Hi Thomas, sure. Yes, the bug is still reproducible in Precise (gimp 2.6.12-1ubuntu1.2), which is what I’m using on my main desktop. But the good news is I can’t reproduce it in VMs running Raring or Saucy (both of which currently have gimp 2.8.4-1ubuntu1), so it looks like it’s been fixed in the 2.8.4 series at the very latest.