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

@trentrichardson I’ve just tested the branch with the change and it’s working perfectly.

Hey @trentrichardson, and thanks for the response! The best I could figure in the meantime was to initialize the prompt differently in each branch, like so:

    if (user.isSignedIn) {
        states = {
            signOut: states.signOut,
            signIn: states.signIn,
            register: states.register
        };
    } else {
        states = {
            signIn: states.signIn,
            signOut: states.signOut,
            register: states.register
        };
    }
    thePrompt = $.prompt(states);

But it’s definitely better to have true support for this in the extension itself. Excellent!

Sorry if this is obvious, but how can I open a multiple-state prompt in a specific state other than the first one in the states object? In other words, in the first statesdemo example, how can I open the prompt in state1 instead of state0?

I’m working on a login/logout/registration form with each of the three as a separate state and would like to start the prompt in either the ”log in” or ”log out” state depending on whether the user is currently logged in or not.

(I’m trying to work out the solution reading Impromptu’s source code, but figured I’d also pose this question here for others like me to find in the future.)

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?

@virtadpt, good to know that the search will scale. As long as it’s snappy to open and to react to typing, I don’t think I’ll need anything fancier in the popup selector.

And yes, DataOutputAgent is what I’m currently using for emitting the feeds (I just spelled it with whitespace above), unless I’m missing your point.

I’m a heavy Yahoo Pipes user, and recently deployed Huginn to Heroku to see if I could use it to replace Pipes. My main motivation for this is ensuring continuity (should Y! decide to pull the plug on Pipes), but an almost equally important one is that managing Pipes has become nightmarish with the amount of individual pipes I’ve accumulated, currently more than 150.

With Huginn I see I can employ Scenarios to group agents together, which is already more than what Pipes offers. But duplicating just a couple of my Pipes’ functionality in Huginn has already produced six agents. Additionally, unlike Pipes, Scenarios can’t be nested (into Scenarios of Scenarios), so I fear that finding and managing individual agents, and perhaps even Scenarios, would eventually become as complicated as managing Pipes once I’d get in double- and triple-digit amounts.

So what I’d like to have in the UI is more means to classify and search for agents. My old-fashioned instinct makes me suggest a directory-like tree structure, but more modern and semantic solutions such as tagging could work just as well if not better. Being able to select an Agent Type could also be one way to narrow down the main agents list (/agents). That list also doesn’t seem to have a search function. The popup list for selecting agents in the Scenario editor does have a search and it seems to work nicely, with real-time results and all, although I’ve not yet created hundreds of agents to see how well it scales.

(In my case, another natural way to reduce the clutter would be having a true singular RSS feed filtering agent (fetch a feed, filter the results, emit the filtered feed), which is my main use-case for Pipes. Currently I’m using an RSS Agent to fetch the feed, a Trigger Agent to filter the results and a Data Output Agent to output the filtered feed, resulting in three separate agents for each of my Pipes. But this is a separate ”Agent Suggestions” issue from the one I’m reporting here. And of course there might already exist a smarter way to do this which I’m just not aware of.)

/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.

I have the exact same problem with the exact same scanner (but I’m running 64-bit Ubuntu w/Linux 3.13.0-45). Sometimes instead of error -110 the logs show the device as being identified correctly, but immediately followed by ”string descriptor 0 read error: -32”. On very rare occasions it just works (no errors when plugged in, identified correctly and scanning works).-110 apparently means not enough power, which is doubly funny because the damn thing has its own power source, and surely a desktop PSU has more power than a laptop…