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.
This is basically the same as bug #870297, but for LXDM.
Systems using LXDM have no entries in the utmp record for logins, so tools like ’w’ and ’who’ do not show LXDM sessions.
Testcase:
1. Start Lubuntu system
2. Log into session
3. Open gnome-terminal
4. Run ’who’ command
Expected result:
You should see TWO entries (the first is from LXDM, the second is from gnome-terminal):
tty7 YYYY-MM-DD HH:MM
pts/0 YYYY-MM-DD HH:MM (:0)
Observed result:
You see only one entry:
pts/0 YYYY-MM-DD HH:MM (:0)
Additional info:
Used gnome-terminal just for consistency with the LightDM report; lxterminal also doesn’t seem to update login records so if you use it instead, observed result is actually ”no entries at all” (and issue for another report). Also, bug #1027805 about wtmp records is similarly applicable to LXDM, but that remains to be fixed even in LightDM…
Also reproducible with chromium-browser 28.0.1500.52-0ubuntu1.12.04.2 (in 12.04).
As the original reporter, I’m confirming that 5.20.0-0ubuntu2 from -proposed does contain the fix for this bug, i.e. the issue I reported above is no longer reproducible. I’m only hesitant about tagging this ’verification-done’ because PerformingSRUVerification is pretty adamant about having a solid test case and I’m not sure my sloppy initial report qualifies.
jani@saegusa:~$ LC_ALL=C apt-cache policy unity
unity:
Installed: 5.20.0-0ubuntu2
Candidate: 5.20.0-0ubuntu2
Version table:
*** 5.20.0-0ubuntu2 0
500 http://archive.ubuntu.com/ubuntu/ precise-proposed/main amd64 Packages
100 /var/lib/dpkg/status
5.18.0-0ubuntu2 0
500 http://archive.ubuntu.com/ubuntu/ precise-updates/main amd64 Packages
5.10.0-0ubuntu6 0
500 http://archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
Christopher, your test packages do indeed fix this, excellent! As I mentioned in the report, this was 100% reproducible with the packages from -proposed, and now with the packages from your PPA I could no longer reproduce it at all, during the multiple test logins I did.
Definitely not a showstopper for me Christopher, just a minor annoyance, so it’s a go-ahead from me. Thanks for asking!
Yep, that’s exactly the issue as it occurs here too. Thanks for looking into this Christopher! If you do get this narrowed down and need testing for potentially fixed builds, I’ll be happy to try them out.
Hi Christopher, sure. For the test user, I just go to the top right cog menu, select ”Startup Applications…” and ”Add” Firefox (/usr/bin/firefox). Firefox remembers the window size, so I start it once (manually), maximize the window and then close it. On the next login, it should start maximized.
Verifying that for both test cases the issue is no longer reproducible with the proposed packages. In other words, results with packages from -proposed are as described in ”Expected:” for each test case. (For both cases the issue was reproducible here with 1:0.9.7.0~bzr19-0ubuntu10.)
jani@saegusa:~$ LC_ALL=C apt-cache policy compiz-plugins-main compiz-plugins-main-default
compiz-plugins-main:
Installed: 1:0.9.7.0~bzr19-0ubuntu10.1
Candidate: 1:0.9.7.0~bzr19-0ubuntu10.1
Version table:
*** 1:0.9.7.0~bzr19-0ubuntu10.1 0
500 http://archive.ubuntu.com/ubuntu/ precise-proposed/main amd64 Packages
100 /var/lib/dpkg/status
1:0.9.7.0~bzr19-0ubuntu10 0
500 http://archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
compiz-plugins-main-default:
Installed: 1:0.9.7.0~bzr19-0ubuntu10.1
Candidate: 1:0.9.7.0~bzr19-0ubuntu10.1
Version table:
*** 1:0.9.7.0~bzr19-0ubuntu10.1 0
500 http://archive.ubuntu.com/ubuntu/ precise-proposed/main amd64 Packages
100 /var/lib/dpkg/status
1:0.9.7.0~bzr19-0ubuntu10 0
500 http://archive.ubuntu.com/ubuntu/ precise/main amd64 Packages