Bug 620589

can you provide this screen for us? are you using encrypted fs?

Thanks for your report.

--
Fedora Bugzappers Team Member

(In reply to comment #1)
> can you provide this screen for us?

A screen of what? "plymouth ask-for-password" ?

Why don't you boot why an encryption partition setup in /etc/crypttab?

> are you using encrypted fs?

Yes, why would the initscripts ask for a partition password otherwise?

(In reply to comment #2)
> (In reply to comment #1)
> > can you provide this screen for us?
> 
> A screen of what? "plymouth ask-for-password" ?

You boot screen, no plymouth screen, type ESC to view the messages behind Plymouth.

> 
> Why don't you boot why an encryption partition setup in /etc/crypttab?
> 
> > are you using encrypted fs?
> 
> Yes, why would the initscripts ask for a partition password otherwise?    

I'm just trying to understand your problem to make sure you on right component.

--
Fedora Bugzappers Team Member

(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > can you provide this screen for us?
> > 
> > A screen of what? "plymouth ask-for-password" ?
> 
> You boot screen, no plymouth screen, type ESC to view the messages behind
> Plymouth.

It is not *my* screen, try it on any system and it will be the same result.

There's no option on plymouth, if you go the console plymouth is still asking for a password, and if you cancel it, the boot process is halted.

The option to skip the password should be *on* plymouth *and* initscripts.

> > Why don't you boot why an encryption partition setup in /etc/crypttab?

*** This bug has been marked as a duplicate of bug 588302 ***

(In reply to comment #5)
> 
> *** This bug has been marked as a duplicate of bug 588302 ***    

Wrong.

This but is not about have a 'noauto' option in crypttab, which can only be edited *before* booting; it's about having the option to skip mounting one partition at boot-time, even when the 'auto' option is present in crypttab.

This used to work before: I just had to press 'esc'.

Allowing you to escape just means it's going to fall over later in all likelyhood when it goes to mount the filesystem. How is that useful?

(In reply to comment #7)
> Allowing you to escape just means it's going to fall over later in all
> likelyhood when it goes to mount the filesystem. How is that useful?    

You don't mount that particular partition. No problem.

(not all partitions are root partitions)

... then it should be marked noauto, once that gets added.

(In reply to comment #9)
> ... then it should be marked noauto, once that gets added.    

No. Whether a non-root partition is automatically mounted at boot-time or not should be a decision of the user.

If the user chooses to configure a non-root encrypted partition to mount at boot-time, the user might still decide not to mount it in certain times, like when using the computer from a hotel room, or a train station, or simply because it's not going to be used.

Other exceptional situations include:
 * Forgetting the password of the partition (you still want to boot)
 * Time is critical and there's no point in wasting it typing an unnecessary password
 * Somebody who shouldn't be allowed access to that data is going to use that computer
 * Booting the system with a kernel that doesn't have that particular crypto facilities

It's very simple: steps that are not essential to the system booting should not prevent the system from booting when skipped.

(In reply to comment #10)
> (In reply to comment #9)
> > ... then it should be marked noauto, once that gets added.    
> 
> No. Whether a non-root partition is automatically mounted at boot-time or not
> should be a decision of the user.

By that logic, mount -a and fsck -a should ask the user/have an option to bail and continue. Neither do, and neither are planned. The crypttab is modelled after fstab - once we have the ability for noauto partitions, it would mirror it pretty much exactly.

(In reply to comment #11)
> By that logic, mount -a and fsck -a should ask the user/have an option to bail
> and continue. Neither do, and neither are planned.

mount -a does bail and continue.

I just added this to fstab and the system booted just fine:
/dev/foobar /foo btrfs defaults 1 2

> The crypttab is modelled
> after fstab - once we have the ability for noauto partitions, it would mirror
> it pretty much exactly.    

Neither fstab or crypttab imply anything about whether or not the system should continue booting if mounting a certain partition is not possible. Just like /etc/sysconfig/network doesn't imply anything about whether or not the system should boot if there's no network.

Before plymouth, typing the password wrong 3 times was considered a failure, and the system continued booting, just like a failure to mount partitions from fstab doesn't prevent the system from booting.

What should happen if you configure an NFS partition to mount automatically, but the network is down or not available?

Hello?

This is unlikely to change in initscripts at this point, as this functionality has moved to systemd. systemd does, I believe, have a timeout feature for encrypted devices.

Closing as WONTFIX for initscripts.

(In reply to comment #14)
> This is unlikely to change in initscripts at this point, as this functionality
> has moved to systemd. systemd does, I believe, have a timeout feature for
> encrypted devices.
> 
> Closing as WONTFIX for initscripts.

When Fedora 15 is released, if systemd is there, and it indeed allows to boot without partition password, this can be closed.

In the meantime this is still an issue, maybe not on 'initscripts', but an issue still.

It's a RFE that is not going to be addressed in upstream initscripts at this time; hence the closure.

If you prefer CLOSED->RAWHIDE, in relation to the change being done there in systemd, we can certainly mark it that way.