Those power options in LightDM are greyed out for me, too. I don't know how to fix.

This worked: sudo GTK_OVERLAY_SCROLLING=0 caja /

Yes, your explanation is correct: When you deleted Jessie, ASCII's partition changed from /dev/sda6 to /dev/sda5, so GRUB could no longer find ASCII's grub.cfg--even though the file still existed--because GRUB was still looking for it in /dev/sda6.

[If GRUB used UUIDs to locate partitions, your partition reshuffling would not have created a problem. However, based on this discussion (see posts #6 and #8) GRUB "remembers" its grub.cfg partition using a single byte, which is enough to store a single digit (e.g., /dev/sda6) but not enough to store the 32 digits of a UUID.]

Are you sure that the option you saw during installation didn't have to do with putting /boot in its own partition? That would make more sense and some people do that. However, putting GRUB in its own partition just doesn't make any sense for a disk with MBR partition table--among other reasons because it would not prevent the kind of issue you experienced. If your impulse to put GRUB in its own partition is to keep it out of harm's way, perching it at the "root" of /dev/sda (which is called its MBR) accomplishes your intent beautifully: It would be very difficult for you or some piece of software to accidentally wipe the disk's MBR.

(In GPT-land everything is different, but I don't want to confuse things since both you and I live in MBR-land.)

Glad I could help. It was a lucky guess.

Being paranoid about privacy, I've had to wiggle the mouse plenty of times to help gpg generate key pairs, but then I installed haveged and my mouse wiggling days were over

rolfie, sorry to hear you're still struggling with this. I installed ASCII from a Miyo live image, then proceeded to install MATE and lightdm. It was at that point that all the permissions issues kicked in (any time I tried to use a thumbdrive or even just shut down the machine, I either got a permissions error or things failed silently. Those are the troubles I remember, but there were other similar issues).

For me it was simply a matter of installing two packages (libpolkit-backend-1-0-elogind and libpolkit-gobject-1-0-elogind) and all problems immediately went away. I didn't need to do any configuration, it was truly just a matter of having the right packages. It was only after a few days of everything working that I got brave and uninstalled all the consolekit-related packages, and things simply continued humming along.

If you don't have a strong reason to stick with consolekit, why don't you try your luck with elogind?

My ASCII+MATE installation also started out as Miyo linux. I've used lightdm, slim, and startx; boot/login time for all of them is about the same (12 seconds; note that I have a SSD).

The bit about login time being shorter when mouse is moved around is very strange. The only process I can think of which is faster when mouse is moved is entropy generation. It wouldn't hurt to install haveged and see if it helps.

How are you compiling? If from upstream non-debianized source code, your custom VLC may be much more different from our repository version than you think, which possibly may account for failure to produce video.

Here are my personal notes on building a .deb from debianized source code. Forgive me if you already know all this. If you do it this way, your custom package is virtually guaranteed to differ from our repository version only in what you change.

$ sudo apt-get install build-essential dpkg-dev fakeroot

make sure /etc/apt/sources.list has at least one deb-src line
(e.g., deb-src http://pkgmaster.devuan.org/merged/ ascii main)

$ sudo apt-get update

$ sudo apt-get build-dep vlc

$ apt-get source vlc

edit source code to taste

$ cd vlc-<version>

$ dpkg-buildpackage -rfakeroot -us -uc
(if this step complains about "missing upstream tarball", add -b flag)  

Sorry I can't be helpful in specifics. Graphics are not my forte.

Can you please post the output of dpkg -l | perl -lane 'print "$F[1] $F[2]" if /^.i/' | grep linux?

My gut feeling is that it is a kernel component, too. Thanks for sharing your thoughts. I'm glad that my hunch seems plausible to at least one other knowledgeable user.

Maybe we'll never know for sure, but as long as we're not missing an obvious answer then I'm fine with that.

So I installed acpid and both closing the lid and opening it are events that acpi can catch. I save the brightness on lid close, then restore it on lid open. Now after I open the lid, the brightness is maxed out for a fraction of a second and then acpi restores the saved brightness.

So although I now have a workaround (thank you, devuser!), the main reason I opened the thread is that I would like to know what system component is cranking up the brightness when I open the lid. I know it's not UPower and not acpi (since it wasn't even installed). How do I find out if the culprit is X, the kernel, i915, or something else?

BEAUTIFUL, ralph.ronnquist! Yes, that does it.

So to summarize:
1. Do the steps in post #9
2. Add the line to /etc/inittab as shown in post #10
3. Bind Control+Alt+Backspace to run the command sudo init 3 (e.g., via xbindkeys)
4. Disable* the system's Control+Alt+Backspace keybinding to kill X server (if your system has that binding)

Now the behavior is exactly what one would expect: Logging out causes LightDM to show a graphical login screen, while Control+Alt+Backspace kills X and lightdm, and the user gets a CLI login prompt in tty7. To return to a graphical session in tty7, user types sudo init 2 (if xinit package is installed, startx also works).

* I don't know a CLI or DE-agnostic way to do this. In MATE: System > Preferences > Keyboard > Layouts > Options > Key sequence to kill the X server > uncheck the Control+Alt+Backspace box

fsmithred, the runlevel approach is pretty clever.

Normally when I want to remove a symlink for a runlevel, I just go with the absolute easiest way and prepend the link's name with an underscore.

Here's what I tried:

But the above is not working: Switching runlevels has no discernible effect--I still find myself in my MATE session with both X and lightdm still running. I can confirm that the change in runlevel did occur:

Any ideas?