[dm-crypt] Boot Prompt Text

[dm-crypt] Boot Prompt Text

[Andrew Dunn]

Is it possible to change the boot prompt text?

Currently, my system boots and since I'm running nvidia bin graphics
with nomodeset I get the text prompt for full disk encryption. It
displays something like "Please Enter the password for <UUID>:

I would like if I could have the prompt have no text at all. Just a
blinking cursor.

If it makes any difference, I'm on Fedora 20.

Thanks!

Re: [dm-crypt] Boot Prompt Text

[Arno Wagner]

On Mon, Feb 17, 2014 at 12:28:13 CET, Andrew Dunn wrote:
> Is it possible to change the boot prompt text?
> 
> Currently, my system boots and since I'm running nvidia bin graphics
> with nomodeset I get the text prompt for full disk encryption. It
> displays something like "Please Enter the password for <UUID>:
> 
> I would like if I could have the prompt have no text at all. Just a
> blinking cursor.
> 
> If it makes any difference, I'm on Fedora 20.

Then you should talk to the Fedora 20 people. This prompt is their
doing...

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -  Plato

Re: [dm-crypt] Boot Prompt Text

[Thomas Bächler]

[-- Attachment #1: Type: text/plain, Size: 729 bytes --]

Am 17.02.2014 14:04, schrieb Arno Wagner:
> On Mon, Feb 17, 2014 at 12:28:13 CET, Andrew Dunn wrote:
>> Is it possible to change the boot prompt text?
>>
>> Currently, my system boots and since I'm running nvidia bin graphics
>> with nomodeset I get the text prompt for full disk encryption. It
>> displays something like "Please Enter the password for <UUID>:
>>
>> I would like if I could have the prompt have no text at all. Just a
>> blinking cursor.
>>
>> If it makes any difference, I'm on Fedora 20.
> 
> Then you should talk to the Fedora 20 people. This prompt is their
> doing...

Actually, it's systemd's doing:

http://cgit.freedesktop.org/systemd/systemd/tree/src/cryptsetup/cryptsetup.c#n266



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [dm-crypt] Boot Prompt Text

[Arno Wagner]

On Mon, Feb 17, 2014 at 14:19:31 CET, Thomas Bächler wrote:
> Am 17.02.2014 14:04, schrieb Arno Wagner:
> > On Mon, Feb 17, 2014 at 12:28:13 CET, Andrew Dunn wrote:
> >> Is it possible to change the boot prompt text?
> >>
> >> Currently, my system boots and since I'm running nvidia bin graphics
> >> with nomodeset I get the text prompt for full disk encryption. It
> >> displays something like "Please Enter the password for <UUID>:
> >>
> >> I would like if I could have the prompt have no text at all. Just a
> >> blinking cursor.
> >>
> >> If it makes any difference, I'm on Fedora 20.
> > 
> > Then you should talk to the Fedora 20 people. This prompt is their
> > doing...
> 
> Actually, it's systemd's doing:
> 
> http://cgit.freedesktop.org/systemd/systemd/tree/src/cryptsetup/cryptsetup.c#n266

Ah, that evil monster. For that I would say those that 
use systemd shall suffer from the complexity they chose.
That this is in a c-file, not an easily changed shell-
skript, already explains quite a bit of what is wrong
with systemd.

So fixing this goes something like this:
 - create a patch for the c-code
 - recompile and reinstall systemd
 - and maintain your patch forever

Pity. With a sane init system, it would just be a change to
some shell-skript, i.e. 2 minutes with a text editor. 

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -  Plato

Re: [dm-crypt] Boot Prompt Text

[Thomas Bächler]

[-- Attachment #1: Type: text/plain, Size: 1023 bytes --]

Am 17.02.2014 15:39, schrieb Arno Wagner:
> That this is in a c-file, not an easily changed shell-
> skript, already explains quite a bit of what is wrong
> with systemd.

Besides the fact that this is completely off-topic:

You could use the same argument on cryptsetup and claim that it should
be a shell script. Why isn't it? If I want 'cryptsetup luksOpen's prompt
to change, I need to change it in cryptsetup and recompile. If it was a
script, I could easily edit it.

It's *precisely* your argument. (Of course, it completely ignores that
the next system update would overwrite it, shell script or binary).

Really, please stop inventing weird arguments against things that you
don't use, are not interested in and don't know anything about - and
keep it on-topic.

> Pity. With a sane init system, it would just be a change to
> some shell-skript, i.e. 2 minutes with a text editor. 

Until the next system update - and then you edit it again. System
maintenance like it is done in 2014!



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [dm-crypt] Boot Prompt Text

[Sven Eschenberg]

On Mon, February 17, 2014 16:02, Thomas Bächler wrote:
> Am 17.02.2014 15:39, schrieb Arno Wagner:
>> That this is in a c-file, not an easily changed shell-
>> skript, already explains quite a bit of what is wrong
>> with systemd.
>
> Besides the fact that this is completely off-topic:
>
> You could use the same argument on cryptsetup and claim that it should
> be a shell script. Why isn't it? If I want 'cryptsetup luksOpen's prompt
> to change, I need to change it in cryptsetup and recompile. If it was a
> script, I could easily edit it.

As you might have realized, cryptsetup provides ways to not show it's own
prompt and offers various ways of providing a key/password, so using a
script with your own prompt is straight forward. Of course doing it all in
a shell script is impossible, I assume you know that already and why.

>
> It's *precisely* your argument. (Of course, it completely ignores that
> the next system update would overwrite it, shell script or binary).

No it is not, as cryptsetup is a minimal tool doing one job which can not
be achived by the shell itself, while offering various ways to provide the
key and as such can easily be wrapped.

While binaries get replaced during an update, shell scripts don't. (Matter
of fact, it depends on the dist, so it's up to the user to choose)

>
> Really, please stop inventing weird arguments against things that you
> don't use, are not interested in and don't know anything about - and
> keep it on-topic.

Arno merely gave a side remark as well as the answer on how to achieve
what was asked, nothing wrong here.

>
>> Pity. With a sane init system, it would just be a change to
>> some shell-skript, i.e. 2 minutes with a text editor.
>
> Until the next system update - and then you edit it again. System
> maintenance like it is done in 2014!

System updates in 2014 do not forcefully revert user changes!

-Sven

Re: [dm-crypt] Boot Prompt Text

[Thomas Bächler]

[-- Attachment #1: Type: text/plain, Size: 200 bytes --]

Am 17.02.2014 16:18, schrieb Sven Eschenberg:
> As you might have realized, cryptsetup provides ways to not show its own
> prompt

What's the option for that? I can't find it in the manpage.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [dm-crypt] Boot Prompt Text

[.. ink ..]

[-- Attachment #1: Type: text/plain, Size: 425 bytes --]

On Mon, Feb 17, 2014 at 10:28 AM, Thomas Bächler <thomas@archlinux.org>wrote:

> Am 17.02.2014 16:18, schrieb Sven Eschenberg:
> > As you might have realized, cryptsetup provides ways to not show its own
> > prompt
>
> What's the option for that? I can't find it in the manpage.
>
>
The library has the option

http://wiki.cryptsetup.googlecode.com/git/API/libcryptsetup_8h.html#a5c25a4cad1bebe338a85c99099b007e9

[-- Attachment #2: Type: text/html, Size: 909 bytes --]

Re: [dm-crypt] Boot Prompt Text

[Arno Wagner]

On Mon, Feb 17, 2014 at 16:28:08 CET, Thomas Bächler wrote:
> Am 17.02.2014 16:18, schrieb Sven Eschenberg:
> > As you might have realized, cryptsetup provides ways to not show its own
> > prompt
> 
> What's the option for that? I can't find it in the manpage.

Learn to read. 

"--batch-mode" might help and so might the info in the two
sections "NOTES ON PASSPHRASE PROCESSING FOR PLAIN MODE"
and "NOTES ON PASSPHRASE PROCESSING FOR LUKS".

cryptsetup will detect whether it is connected to a terminal 
or fed via stdin. If fed via stdin it will only report errors 
to stderr.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -  Plato

Re: [dm-crypt] Boot Prompt Text

[Sven Eschenberg]

You can use -d to pass in file data, which naturally bypasses the prompt,
it should easily work with a fifo too, IIC.

Quote:
       --key-file, -d name
              Read the passphrase from file.

              If the name given is "-", then the passphrase will be read
from stdin.  In this case, reading will not stop at newline
characters.

              With LUKS, passphrases supplied via --key-file are always
the existing passphrases requested by a command, except in
the case of luksFormat where --key-file is equivalent to 
the
              positional key file argument.

              If you want to set a new passphrase via key file, you have
to use a positional argument to luksAddKey.

              See section NOTES ON PASSPHRASE PROCESSING for more
information.

And please read the passphrase processing part for a complete understanding!

-Sven

On Mon, February 17, 2014 16:28, Thomas Bächler wrote:
> Am 17.02.2014 16:18, schrieb Sven Eschenberg:
>> As you might have realized, cryptsetup provides ways to not show its own
>> prompt
>
> What's the option for that? I can't find it in the manpage.
>
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] Boot Prompt Text

[Arno Wagner]

On Mon, Feb 17, 2014 at 16:02:17 CET, Thomas Bächler wrote:
> Am 17.02.2014 15:39, schrieb Arno Wagner:
> > That this is in a c-file, not an easily changed shell-
> > skript, already explains quite a bit of what is wrong
> > with systemd.
> 
> Besides the fact that this is completely off-topic:
> 
> You could use the same argument on cryptsetup and claim that it should
> be a shell script. Why isn't it? If I want 'cryptsetup luksOpen's prompt
> to change, I need to change it in cryptsetup and recompile. If it was a
> script, I could easily edit it.

Actually, you just need to read the man-page to find out how to
use cryptsetup from a shell-script and then you can do anything
you like in that wrapper. It is pretty well prepared for that 
usage-scenario. As to why it is not a shell-script itself,
doing crypto in a shell-script is pretty stupid for a number
of reasons that do not require elaboration for anybody that 
knows the first thing about crypto.  
 
> It's *precisely* your argument. (Of course, it completely ignores that

No, it is not. Not even close. See above.

> the next system update would overwrite it, shell script or binary).

Oh? Not in a sane update system for a shell script. Debians
"file has been changed from original, (d)iff, (o)verwrite,
(k)eep" (paraphrased) works pretty well for shell-scripts.
It does not really work for binaries, for obvious reasons.

> Really, please stop inventing weird arguments against things that you
> don't use, are not interested in and don't know anything about - and
> keep it on-topic.

I am on-topic. There is absolutely nothing weird about my argument.
Can the cheap retorics and the personal insults. They just disqualify 
you.

> > Pity. With a sane init system, it would just be a change to
> > some shell-skript, i.e. 2 minutes with a text editor. 
> 
> Until the next system update - and then you edit it again. System
> maintenance like it is done in 2014!

Not at all. See above. I have been modifying init-scripts
for more than a decade and never had any serious issues.
I can only guess you lack that kind of experience.

So I your answer is "it does not work, but other ways to
do that are broken too"? That is both pretty pathetic not true.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -  Plato

Re: [dm-crypt] Boot Prompt Text

[Arno Wagner]

On Mon, Feb 17, 2014 at 15:39:01 CET, Arno Wagner wrote:
> > Actually, it's systemd's doing:
> > 
> > http://cgit.freedesktop.org/systemd/systemd/tree/src/cryptsetup/cryptsetup.c#n266
> 
> Ah, that evil monster. For that I would say those that 
> use systemd shall suffer from the complexity they chose.
> That this is in a c-file, not an easily changed shell-
> skript, already explains quite a bit of what is wrong
> with systemd.
> 
> So fixing this goes something like this:
>  - create a patch for the c-code
>  - recompile and reinstall systemd
>  - and maintain your patch forever
> 
> Pity. With a sane init system, it would just be a change to
> some shell-skript, i.e. 2 minutes with a text editor. 

Aparently, I was wrong. It seems the correct process to
do this (according to a personal communication from
Thomas Bächler) is as follows:

- Find a solution for the problem that
  a) is generic enough to fit your use case and satisfy others
  b) can be implemented by the admin using appopriate configuration
     files (without further editing shell scripts or binaries).
- Implement that solution in the code.
- Get the patch merged into systemd.
 
How that has any business replacing

- Start editor
- Fiddle with init-script until you like the prompt
- Enjoy _your_ solution to the problem, no matter what 
  anybody else thinks about it

is beyond me. But I do know a certain other OS where 
they do not like you to customize your experience either.
I can only advise anybody that does want to customize what 
their system does to stay away from these authoritarian 
atrocities.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -  Plato

Re: [dm-crypt] Boot Prompt Text

[Dave Reisner]

On Mon, Feb 17, 2014 at 06:57:25PM +0100, Arno Wagner wrote:
> On Mon, Feb 17, 2014 at 15:39:01 CET, Arno Wagner wrote:
> > > Actually, it's systemd's doing:
> > > 
> > > http://cgit.freedesktop.org/systemd/systemd/tree/src/cryptsetup/cryptsetup.c#n266
> > 
> > Ah, that evil monster. For that I would say those that 
> > use systemd shall suffer from the complexity they chose.
> > That this is in a c-file, not an easily changed shell-
> > skript, already explains quite a bit of what is wrong
> > with systemd.
> > 
> > So fixing this goes something like this:
> >  - create a patch for the c-code
> >  - recompile and reinstall systemd
> >  - and maintain your patch forever
> > 
> > Pity. With a sane init system, it would just be a change to
> > some shell-skript, i.e. 2 minutes with a text editor. 
> 
> Aparently, I was wrong. It seems the correct process to
> do this (according to a personal communication from
> Thomas Bächler) is as follows:
> 
> - Find a solution for the problem that
>   a) is generic enough to fit your use case and satisfy others
>   b) can be implemented by the admin using appopriate configuration
>      files (without further editing shell scripts or binaries).
> - Implement that solution in the code.
> - Get the patch merged into systemd.
>  
> How that has any business replacing
> - Start editor
> - Fiddle with init-script until you like the prompt
> - Enjoy _your_ solution to the problem, no matter what 
>   anybody else thinks about it

These appear to be very different processes. Generally speaking, one of
them results in an upstream change that everyone can benefit from at no
cost. The other results in an isolated change that may or may not be
respected by your package manager on upgrade. Should your toy break,
you're own your own to debug your local modifications before you can
debug the upstream code.

Where did the --batch-mode flag come from? Surely, someone recognized a
need and solved it in the cryptsetup binary. Why do you consider this
feature addition in cryptsetup different from proposing a patch to any
other project which uses a compiled language? I suspect this only works
if you assume that the upstream project is contributor-hostile and will
never accept your patch.

Do you also frown on people who patch their kernel to make changes that
benefit themselves but which wouldn't be acceptable mainline? Do you
share similar contempt for any compiled code which could have a
functionally equivalent solution in an interpreted language?

> is beyond me. But I do know a certain other OS where 
> they do not like you to customize your experience either.
> I can only advise anybody that does want to customize what 
> their system does to stay away from these authoritarian 
> atrocities.

I used to respect your opinion on this list. Your work on the FAQ is
fantastic, and a service to (I can only imagine) thousands of users.
Your behavior here just makes you look like an adolescent who refuses to
understand why one might prefer a different solution to their problem.
Furthermore, defaming the work of people who've put their own time into
$PROJECT does nothing to support your stance. It's childish at best.

I'm saddened by this. I really don't understand your attitude.

d

Re: [dm-crypt] Boot Prompt Text

[Arno Wagner]

On Mon, Feb 17, 2014 at 19:58:27 CET, Dave Reisner wrote:
> On Mon, Feb 17, 2014 at 06:57:25PM +0100, Arno Wagner wrote:
> > On Mon, Feb 17, 2014 at 15:39:01 CET, Arno Wagner wrote:
> > > > Actually, it's systemd's doing:
> > > > 
> > > > http://cgit.freedesktop.org/systemd/systemd/tree/src/cryptsetup/cryptsetup.c#n266
> > > 
> > > Ah, that evil monster. For that I would say those that 
> > > use systemd shall suffer from the complexity they chose.
> > > That this is in a c-file, not an easily changed shell-
> > > skript, already explains quite a bit of what is wrong
> > > with systemd.
> > > 
> > > So fixing this goes something like this:
> > >  - create a patch for the c-code
> > >  - recompile and reinstall systemd
> > >  - and maintain your patch forever
> > > 
> > > Pity. With a sane init system, it would just be a change to
> > > some shell-skript, i.e. 2 minutes with a text editor. 
> > 
> > Aparently, I was wrong. It seems the correct process to
> > do this (according to a personal communication from
> > Thomas Bächler) is as follows:
> > 
> > - Find a solution for the problem that
> >   a) is generic enough to fit your use case and satisfy others
> >   b) can be implemented by the admin using appopriate configuration
> >      files (without further editing shell scripts or binaries).
> > - Implement that solution in the code.
> > - Get the patch merged into systemd.
> >  
> > How that has any business replacing
> > - Start editor
> > - Fiddle with init-script until you like the prompt
> > - Enjoy _your_ solution to the problem, no matter what 
> >   anybody else thinks about it
> 
> These appear to be very different processes. Generally speaking, one of
> them results in an upstream change that everyone can benefit from at no
> cost.

But:
- Requires whoever wants to make a change to be a developer
  and learn enough to change the c-code. A heavyweight effort.
  Also quite elitist as it excludes all people that to not have
  the required c programming skills from doing what should be a 
  minor modification.
- Requires what they want to be something that is "mainstream"
  enough so that it gets accepted. (What the HELL???? I 
  insist I can customize my Linux system any way I want and I 
  insist than in places where it should be easy _anybody_
  should be able to do so _without_ having a comittee signing
  off on their wishes first!)

> The other results in an isolated change that may or may not be
> respected by your package manager on upgrade. 

If your package manager does not respect it, then the package
manager is broken. Not all are. That argument is a red herring.

> Should your toy break,
> you're own your own to debug your local modifications before you can
> debug the upstream code.

The price of non-conformity is higher effort. Do you want 
everybody to use the same thing to prevent that? Guess what, 
it is not your choice, or at least it should not be. And if 
somebody want to do their own engineering on parts of their
system, that is one of the reasons to use Linux. (Calling it 
a "toy" is just hughely disrespectful to anybody that wans to do
this type of cutomization, btw.)

> Where did the --batch-mode flag come from? Surely, someone recognized a
> need and solved it in the cryptsetup binary. Why do you consider this
> feature addition in cryptsetup different from proposing a patch to any
> other project which uses a compiled language? I suspect this only works
> if you assume that the upstream project is contributor-hostile and will
> never accept your patch.

Apples and oranges. --batch-mode is by its very nature a general idea.

> Do you also frown on people who patch their kernel to make changes that
> benefit themselves but which wouldn't be acceptable mainline? Do you

No, I do not. In fact I have done so myself. I do however not
understand your point at all. 

> share similar contempt for any compiled code which could have a
> functionally equivalent solution in an interpreted language?

Huh? That depends on its usage cenario: Glue code, configuration 
code that should be highly flexible is better off being interprted.
Code that does not have high performance needs and does simple
things that people may want to customize as well.

Code that "does one thing, and does it well" can be both. 

If performance is an issue, or things like memory locking, going
non-compiled becomes very difficult.

You are over-generalizing here to make an invalid point. 
It is not flattering.

> > is beyond me. But I do know a certain other OS where 
> > they do not like you to customize your experience either.
> > I can only advise anybody that does want to customize what 
> > their system does to stay away from these authoritarian 
> > atrocities.
> 
> I used to respect your opinion on this list. Your work on the FAQ is
> fantastic, and a service to (I can only imagine) thousands of users.
> Your behavior here just makes you look like an adolescent who refuses to
> understand why one might prefer a different solution to their problem.

Nice contrast. Maybe, just maybe you do really not get what this is
about? But guess what, neither my comments here, not the FAQ I do
to get admiration or respect and after this infantile posturing, 
certainly not to get yours. I do them because they are needed.

If however, a single voiced opinion of mine can negate all your
respect for some completely unrelated work of mine, then you 
should ask yourself whether there is something wrong with your 
world model. Your reaction is that of a true believer that
has his faith challenged. A mature person can disagree with 
another person and still respect their work on other things. 

As to the ad hominem, you can stick that were the sun does not
shine, I am entirely unimpressed by infantile name-calling.

> Furthermore, defaming the work of people who've put their own time into
> $PROJECT does nothing to support your stance. It's childish at best.

If the work sucks, I will call it bad. That is not defamation.
I do have noticed however, that the systemd crowd behaves more 
like a cult in that regard: Any criticism is immediately dragged
on an emotional level instead of being dealt with in a rational 
manner. That is one of the cheapest tricks to deflect criticism 
without dealing with the points raised. It also is a rather 
strong indicator that the work in question cannot stand on its 
own merits or such underhanded tactics would be unneccessary.
 
> I'm saddened by this. I really don't understand your attitude.

It is motivated by the technical facts I see and by a clearly 
hostile takeover attempt with regard to a critical part of 
Linux infrastructure. That you do not understand my attitude 
may be because you do not understand what I am saying and why 
I am saying it. But as I said, that some people do not like 
what I say will not stop me from calling a bad thing bad.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -  Plato

Re: [dm-crypt] Boot Prompt Text

[Richard Z]

On Mon, Feb 17, 2014 at 06:57:25PM +0100, Arno Wagner wrote:
> On Mon, Feb 17, 2014 at 15:39:01 CET, Arno Wagner wrote:
> > > Actually, it's systemd's doing:
> > > 
> > > http://cgit.freedesktop.org/systemd/systemd/tree/src/cryptsetup/cryptsetup.c#n266
> > 
> > Ah, that evil monster. For that I would say those that 
> > use systemd shall suffer from the complexity they chose.
> > That this is in a c-file, not an easily changed shell-
> > skript, already explains quite a bit of what is wrong
> > with systemd.
> > 
> > So fixing this goes something like this:
> >  - create a patch for the c-code
> >  - recompile and reinstall systemd
> >  - and maintain your patch forever
> > 
> > Pity. With a sane init system, it would just be a change to
> > some shell-skript, i.e. 2 minutes with a text editor. 
> 
> Aparently, I was wrong. It seems the correct process to
> do this (according to a personal communication from
> Thomas Bächler) is as follows:
> 
> - Find a solution for the problem that
>   a) is generic enough to fit your use case and satisfy others
>   b) can be implemented by the admin using appopriate configuration
>      files (without further editing shell scripts or binaries).
> - Implement that solution in the code.
> - Get the patch merged into systemd.

seems there are other ways to do it because on my Fedora 19 with 
out of the box encrypted hard disk I do not see any prompt - just 
an entry box without any text where I can type the password.

> How that has any business replacing
> 
> - Start editor
> - Fiddle with init-script until you like the prompt
> - Enjoy _your_ solution to the problem, no matter what 
>   anybody else thinks about it
 
not always quite so easy, some distros have some kind of initial 
ram disk. I would rather patch systemd than mess with the initial
ramdisk every time a new kernel is installed.


Richard

---
Name and OpenPGP keys available from pgp key servers

Re: [dm-crypt] Boot Prompt Text

[Arno Wagner]

On Tue, Feb 18, 2014 at 12:33:49 CET, Richard Z wrote:
> On Mon, Feb 17, 2014 at 06:57:25PM +0100, Arno Wagner wrote:
> > On Mon, Feb 17, 2014 at 15:39:01 CET, Arno Wagner wrote:
> > > > Actually, it's systemd's doing:
> > > > 
> > > > http://cgit.freedesktop.org/systemd/systemd/tree/src/cryptsetup/cryptsetup.c#n266
> > > 
> > > Ah, that evil monster. For that I would say those that 
> > > use systemd shall suffer from the complexity they chose.
> > > That this is in a c-file, not an easily changed shell-
> > > skript, already explains quite a bit of what is wrong
> > > with systemd.
> > > 
> > > So fixing this goes something like this:
> > >  - create a patch for the c-code
> > >  - recompile and reinstall systemd
> > >  - and maintain your patch forever
> > > 
> > > Pity. With a sane init system, it would just be a change to
> > > some shell-skript, i.e. 2 minutes with a text editor. 
> > 
> > Aparently, I was wrong. It seems the correct process to
> > do this (according to a personal communication from
> > Thomas Bächler) is as follows:
> > 
> > - Find a solution for the problem that
> >   a) is generic enough to fit your use case and satisfy others
> >   b) can be implemented by the admin using appopriate configuration
> >      files (without further editing shell scripts or binaries).
> > - Implement that solution in the code.
> > - Get the patch merged into systemd.
> 
> seems there are other ways to do it because on my Fedora 19 with 
> out of the box encrypted hard disk I do not see any prompt - just 
> an entry box without any text where I can type the password.

Interesting. Can you find out what the difference is?
The OP might want to know.
 
> > How that has any business replacing
> > 
> > - Start editor
> > - Fiddle with init-script until you like the prompt
> > - Enjoy _your_ solution to the problem, no matter what 
> >   anybody else thinks about it
>  
> not always quite so easy, some distros have some kind of initial 
> ram disk. I would rather patch systemd than mess with the initial
> ramdisk every time a new kernel is installed.

How difficult messing with the initrd is depends on the
distro: Some have commands that allow you to change things
easily and persistently, others will make that very hard.

If you are able to patch systemd, then there is nothing 
wrong with doing so IMO, and you can try to get the patch
into the upstream version as well. 

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -  Plato

Re: [dm-crypt] Boot Prompt Text

[Milan Broz]

On 02/18/2014 05:21 PM, Arno Wagner wrote:
> On Tue, Feb 18, 2014 at 12:33:49 CET, Richard Z wrote:
>> On Mon, Feb 17, 2014 at 06:57:25PM +0100, Arno Wagner wrote:

>> seems there are other ways to do it because on my Fedora 19 with 
>> out of the box encrypted hard disk I do not see any prompt - just 
>> an entry box without any text where I can type the password.
> 
> Interesting. Can you find out what the difference is?
> The OP might want to know.

BTW Fedora used plymouth (graphical and text boot frontend)
for password prompt, then it pushed password to cryptsetup directly.

Recent versions use systemd, password prompt depends
on configuration (I think it can be still still plymouth) but unlocking
of disk is done by systemd itself (resp. system-cryptsetup
generator parsing /etc/crypttab translating it to separate systemd units).

Unlocking uses libcryptsetup only.
IIRC in Fedora boot process there is no cryptsetup binary used at all.

I would suggest to ask on systemd or Fedora devel list if you want
to change prompt then.

Milan

Re: [dm-crypt] Boot Prompt Text

[Arno Wagner]

On Tue, Feb 18, 2014 at 17:44:31 CET, Milan Broz wrote:
> On 02/18/2014 05:21 PM, Arno Wagner wrote:
> > On Tue, Feb 18, 2014 at 12:33:49 CET, Richard Z wrote:
> >> On Mon, Feb 17, 2014 at 06:57:25PM +0100, Arno Wagner wrote:
> 
> >> seems there are other ways to do it because on my Fedora 19 with 
> >> out of the box encrypted hard disk I do not see any prompt - just 
> >> an entry box without any text where I can type the password.
> > 
> > Interesting. Can you find out what the difference is?
> > The OP might want to know.
> 
> BTW Fedora used plymouth (graphical and text boot frontend)
> for password prompt, then it pushed password to cryptsetup directly.

Interesting.
 
> Recent versions use systemd, password prompt depends
> on configuration (I think it can be still still plymouth) but unlocking
> of disk is done by systemd itself (resp. system-cryptsetup
> generator parsing /etc/crypttab translating it to separate systemd units).
> 
> Unlocking uses libcryptsetup only.
> IIRC in Fedora boot process there is no cryptsetup binary used at all.

While I do not like that they do it, I think this is the right 
way to do it from c code. Of course it places all responsibility 
for the user interface on them.
 
> I would suggest to ask on systemd or Fedora devel list if you want
> to change prompt then.

Probably the best first approach.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -  Plato

Re: [dm-crypt] Boot Prompt Text

[Thomas Bächler]

[-- Attachment #1: Type: text/plain, Size: 381 bytes --]

Am 18.02.2014 12:33, schrieb Richard Z:
> seems there are other ways to do it because on my Fedora 19 with 
> out of the box encrypted hard disk I do not see any prompt - just 
> an entry box without any text where I can type the password.

That is likely plymouth. It won't work for OP, since he uses the
proprietary nvidia drivers and thus gets no modesetting driver.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]