Cannot install with a blank password

Solution proposed in the attached branches is to ass an additional passwd/allow-password-empty boolean preseed value, and to have user-setup check this before presenting the user-setup/password-empty error.

The password empty check has been removed from ubiquity. In the event that a user proceeds with an empty password, and it is not permitted, the user-setup/password-empty error will return the user to the ubiquity interface for input of the password.

user-setup change applied, though I merged it too early to include the bug number. (I've remerged the branch so that it's there for archaeological purposes.)

user-setup (1.20ubuntu8) intrepid; urgency=low

  * Add support and template for passwd/allow-password-empty as a
    boolean preseed value that overrides the test for an empty
    password.

 -- Emmet Hikory <email address hidden> Tue, 07 Oct 2008 18:23:28 +0900

With regard to your ubiquity change, I think I'd rather have ubiquity check passwd/allow-password-empty and continue to disable the next button for empty password/verified-password entry boxes if it's false; I don't think this should be too difficult. My reasoning is:

  * If you don't know about the allow-password-empty change, it's a bit of a weird UI change.
  * It's better to handle problems as early as possible rather than having to go through user-setup and back. Out of necessity, there are some problems that we can only deal with by the latter method, but where it's feasible we should prefer to simply prevent the user from going forward until they've filled in the necessary information.

I've updated the ubiquity branch with a change that preserves the previous user interaction except in cases where passwd/allow-password-empty is set to true, in which case the Forward button is enabled while the password entry is blank. I was unable to expose user-setup/password-empty in the ubiquity UI for any of the permutations I tested with this updated branch.

The applied fix to user-setup was quite effectively shot down as being even sensible by Frans Pop in BTS 501849. While I'd personally be happy not to revert for Intrepid given the timeframe, I'll plan on unimplementing this and preparing different functionality for Jaunty to meet the target goals.

If there is any desire to unimplement for Intrepid, please comment to this bug, and I'll address the root issue in another manner.

Since Frans hadn't considered the case of embedded devices without keyboard input, I have no problem with this remaining in place for Intrepid.

This bug was fixed in the package ubiquity - 1.10.5

---------------
ubiquity (1.10.5) intrepid; urgency=low

  [ Evan Dandrea ]
  * Filter out the net subsystem when calling update-dev to prevent the
    network connection from resetting (LP: #276383).
  * If ubiquity is installing from a disk, such as a USB drive, then default
    to writing grub to the disk that /boot or / is to be written to, as (hd0)
    will most likely be the installation medium (LP: #282037).
  * Automatic update of included source packages: apt-setup
    1:0.37ubuntu5, partman-auto 78ubuntu3, partman-base 121ubuntu7,
    partman-target 55ubuntu4, user-setup 1.20ubuntu9.

  [ Colin Watson ]
  * Fix typo in architecture detection for ntfsprogs dependency.
  * Work around lpia having DEB_HOST_ARCH_CPU=i686 (!).
  * Disable window minimise buttons if the installer is running in
    standalone mode (LP: #249045).
  * Update imported translations from gtk+2.0 2.14.3-0ubuntu3.
  * Update translations from Launchpad (LP: #144741, #218636, #277451).

  [ Emmet Hikory ]
  * Honor preseeded passwd/allow-password-empty (LP: #280014)

 -- Evan Dandrea <email address hidden> Mon, 13 Oct 2008 01:34:45 -0400

For the record, I renamed this to user-setup/allow-password-empty for consistency with user-setup/password-empty (passwd/* really ought to be renamed to user-setup/* in general; the passwd/* names are historical). I'll keep compatibility with the old name for one release.

I'm marking the installation-guide change won't fix, have closed the Debian bugs (or attempted to do so), and intend to revert this as part of bug #347207. There are other ways to achieve the goal (which isn't a very good goal anyway), and it's easier to stay in line with trunk.