Hi Christopher, the apport-collected data above was gathered from my main desktop, which only has Intel graphics. (I mentioned the other system with Radeon just because it *didn’t* suffer from this problem despite having the same software. I no longer have access to that system so unfortunately I can’t provide the same logs from it for comparision.)
Note: I’m attaching a video below demonstrating the issue. In it I’m reproducing the problem with the amd64 ISO of 15.04.
Steps to reproduce:
1. Have a (virtual) machine with a clean 10 GB hard disk and 8 GB of RAM.
2. Start the installer, select ”Erase disk and install Ubuntu”, click ”Install now”.
What happens:
A ”Do you want to return to the partitioner?” window pops up, saying ”Some of the partitions you created are too small. Please make the following partitions at least this large:
/ 3.5 GB
If you do not go back to the partitioner and increase the size of these partitions, the installation may fail.”
Selecting Continue then goes on to an installation which fails due to lack of space as promised. This is because the installer has partitioned the disk with a 8+ GB swap partition, and only what remains of the 10 GB after that allocated to /.
What I expect to happen:
I know this is a tricky corner case, but I think there are better ways to deal with it than exhibited by the installer above. Here are some alternative suggestions I came up with:
1) change the way the disk space requirement is calculated for the ”Preparing to install” view: make it require at least the minimum ”/” size + expected swap size, thus notifying the user beforehand if the requirement is not met. (As you see in the video, currently it has the green checkmark even when the installer is about to fail predictably.)
2) have the installer select a partitioning scheme where ”/” is the minimum required and allocate whatever remains for swap; warn the user that swap will be too small to do hibernation.
3) at the very least, have the ”Do you want to return to the partitioner?” window describe the situation better. It was the biggest source of confusion for me because the wording implied I had partitioned the disk (which I hadn’t done) and prompting me to ”return to the partitioner” where I hadn’t been to.
The setup for unlocking an encrypted volume during boot using (only) a keyfile (on a detachable USB drive) usually calls for a keyscript to be specified as one of the encrypted volume’s options. But with systemd, such encrypted volumes can only be unlocked during boot by typing in a passphrase.
Steps to reproduce:
1. Have a LUKS encrypted volume.
2. Have said volume specified in /etc/crypttab, with keyscript= option pointing to your script for outputting the unlocking key.
3. Boot.
What I expect to happen:
To have the volume unlocked by the script at boot time without manual intervention.
What happens instead:
Plymouth shows a prompt to enter a valid passphrase for the volume.
Workarounds:
Apparently the options for unlocking encrypted drives, including keyscript, can also be specified at the kernel command-line, without crypttab, and according to yaantc at Hacker News [1] this can be used to work around the issue. I haven’t personally tried this.
* [1] https://news.ycombinator.com/item?id=8477913
This morning Gmail notified me that my browser is unsupported, which made me realize Chromium for Precise hasn’t been updated since September 2014 and is currently at version 37 (37.0.2062.120-0ubuntu0.12.04.1~pkg917) whereas more recent versions of Ubuntu are already at Chromium version 41. The ”unsupported version” messages are of course harmless and easy enough to dismiss, but I’m guessing the newer Chromium releases also have important security fixes that should warrant an update – unless there are compatibility issues blocking it from happening?
/etc/X11/imwheel/imwheel rc starts out with:
# This is only for demonstration of the priority command…
# See the other global Exclude command below for the one you want to use!
# If this is activated it will only apps that have a lower priority
# priority is based first on the priority command, then the position in this
# file – the higher the line is in a file the higher in a priority class it is
# thus for a default priority you can see that the position in the file is
# important, but the priority command CAN appear anywahere in a window’s list
# of translations, and the priority will be assigned to all translations below
# it until either a new window is defined or the priority is set again.
I can’t make heads or tails of that. It’s like most of the sentence-ending periods have been misplaced to make random, unnecessary ellipses elsewhere in the file.
This does indeed seem to be fixed Vivid. Nautilus now has two options to remember the credentials (till logout or forever), and both seem to do what it says on the tin.
The community wiki currently claims that the default editor for visudo has been sensible-editor since 8.10 [1]. But for me in both 12.04 and 14.04, `sudo visudo` still launches /etc/alternatives/editor, so select-editor doesn’t actually change visudo’s editor; for that I have to run `sudo update-alternatives –config editor`. So I suspect that either the wiki has incorrect advice, or this bug has been fixed, and has since reappeared.
* [1] https://help.ubuntu.com/community/Sudoers?action=recall&rev=25#content
IN 12.04 at least, this seems to be tied to Xorg’s blanking which by default happens after 10 minutes/600 seconds. It can be unset via xset on the commandline, but I finally managed to do this via xorg.conf, like so:
jani@saegusa:~$ cat /etc/X11/xorg.conf.d/*
Section ”Extensions”
Option ”DPMS” ”Disable”
Option ”MIT-SCREEN-SAVER” ”Disable”
EndSection
Section ”Device”
Identifier ”Intel Graphics”
Driver ”intel”
Option ”DPMS” ”Disable”
EndSection
Section ”ServerFlags”
Option ”NoPM” ”true”
EndSection
Section ”ServerLayout”
Identifier ”X.org Configured”
Option ”BlankTime” ”0”
Option ”StandbyTime” ”0”
Option ”SuspendTime” ”0”
Option ”OffTime” ”0”
EndSection
It could be that just the ServerLayout section is actually required (and I’m not sure if other graphics drivers even have a DPMS option of their own like intel does), as none of the other sections by themselves nor together prevented the screen from turning off. (The most confusing one is MIT-SCREEN-SAVER, which I thought was exactly what the xset timeouts were controlling, but apparently not so, as disabling it does not prevent the issue either.)
Thanks Michael. I’ve added lxpanel as being affected, hopefully someone there can take a look.
The indicator blinks between what looks like an empty graph (in a vertically shorter box) and the actual graph (in a full-sized box). This is best demonstrated in a video so I’m attaching one below.
Both the official repository version (0.4) and the one from daily PPA (0.5) exhibit this. Different color schemes don’t seem to affect it (i.e. the problem remains). There’s further problems when I add a third graph, but this report is just about the blinking.
(Bug #1336828 is about the indicator missing entirely in 14.04, so I decided to report this slightly different issue separately.)