Bug 620589 - Unable to boot without partition password
Unable to boot without partition password
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
13
All Linux
low Severity high
: ---
: ---
Assigned To: Bill Nottingham
Fedora Extras Quality Assurance
: Reopened, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-02 18:45 EDT by Felipe Contreras
Modified: 2014-03-16 23:24 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-02-28 16:01:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Felipe Contreras 2010-08-02 18:45:15 EDT
When booting the system asks for a partition password; there should be a way to skip that step and boot the system without mounting that partition.
Comment 1 iarly selbir 2010-08-03 07:17:13 EDT
can you provide this screen for us? are you using encrypted fs?

Thanks for your report.

--
Fedora Bugzappers Team Member
Comment 2 Felipe Contreras 2010-08-03 07:33:12 EDT
(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?
Comment 3 iarly selbir 2010-08-03 07:44:58 EDT
(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
Comment 4 Felipe Contreras 2010-08-03 07:55:58 EDT
(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?
Comment 5 Bill Nottingham 2010-08-03 10:28:13 EDT

*** This bug has been marked as a duplicate of bug 588302 ***
Comment 6 Felipe Contreras 2010-08-03 11:35:31 EDT
(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'.
Comment 7 Bill Nottingham 2010-08-03 12:24:50 EDT
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?
Comment 8 Felipe Contreras 2010-08-03 14:47:05 EDT
(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)
Comment 9 Bill Nottingham 2010-08-03 14:54:41 EDT
... then it should be marked noauto, once that gets added.
Comment 10 Felipe Contreras 2010-08-03 15:10:40 EDT
(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.
Comment 11 Bill Nottingham 2010-08-03 15:26:04 EDT
(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.
Comment 12 Felipe Contreras 2010-08-03 16:23:42 EDT
(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?
Comment 13 Felipe Contreras 2011-02-04 16:16:53 EST
Hello?
Comment 14 Bill Nottingham 2011-02-28 14:49:05 EST
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.
Comment 15 Felipe Contreras 2011-02-28 15:51:47 EST
(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.
Comment 16 Bill Nottingham 2011-02-28 16:01:51 EST
It's a RFE that is not going to be addressed in upstream initscripts at this time; hence the closure.
Comment 17 Bill Nottingham 2011-02-28 16:02:18 EST
If you prefer CLOSED->RAWHIDE, in relation to the change being done there in systemd, we can certainly mark it that way.

Note You need to log in before you can comment on or make changes to this bug.