touch-packages team mailing list archive

[Stephen Lin <stephenwlin@xxxxxxxxx>]

Public bug reported:

I'm not sure if this really counts as a bug or if it's just an
unsupported configuration, but the post-install script
(lightdm.postinst) doesn't ensure that "/var/lib/lightdm" exists and has
the correct permissions if the user already exists, since it is relying
upon "adduser" to create the home directory and only does so if the
"lightdm" user doesn't already exist. This prevents lightdm from
starting and leads to a fallback X session being created instead, which
doesn't give any helpful information about the underlying problem.

The reason I already had a lightdm user in passwd is because I was
bootstrapping Ubuntu in a chroot and copied passwd/shadow/group/gshadow
into it before installing packages, since I wanted to make sure UID/GIDs
would be consistent between the two installations. It would be nice if
this case could be more gracefully handled, since I don't think it's all
that unusual.

** Affects: lightdm (Ubuntu)
     Importance: Undecided
         Status: New

** Summary changed:

- lightdm post-install script doesn't create var/lib/lightdm if user already exists, preventing lightdm from starting
+ lightdm post-install script doesn't create /var/lib/lightdm if user already exists, preventing lightdm from starting

** Description changed:

  I'm not sure if this really counts as a bug or if it's just an
  unsupported configuration, but the post-install script
- (lightdm.postinst) doesn't ensure that "var/lib/lightdm" exists and has
+ (lightdm.postinst) doesn't ensure that "/var/lib/lightdm" exists and has
  the correct permissions if the user already exists, since it is relying
  upon "adduser" to create the home directory and only does so if the
  "lightdm" user doesn't already exists. This prevents lightdm from
- starting and leads to a fallback X session being created instead.
+ starting and leads to a fallback X session being created instead, which
+ doesn't give any helpful information about the underlying problem.
  
  The reason I already had a lightdm user in passwd is because I was
  bootstrapping lightdm in a chroot and copied passwd/shadow/group/gshadow
  into it before installing packages, since I wanted to make sure UID/GIDs
  would be consistent between the two installations. It would be nice if
- this case were more gracefully handled.
+ this case could be more gracefully handled.

** Description changed:

  I'm not sure if this really counts as a bug or if it's just an
  unsupported configuration, but the post-install script
  (lightdm.postinst) doesn't ensure that "/var/lib/lightdm" exists and has
  the correct permissions if the user already exists, since it is relying
  upon "adduser" to create the home directory and only does so if the
  "lightdm" user doesn't already exists. This prevents lightdm from
  starting and leads to a fallback X session being created instead, which
  doesn't give any helpful information about the underlying problem.
  
  The reason I already had a lightdm user in passwd is because I was
- bootstrapping lightdm in a chroot and copied passwd/shadow/group/gshadow
+ bootstrapping Ubuntu in a chroot and copied passwd/shadow/group/gshadow
  into it before installing packages, since I wanted to make sure UID/GIDs
  would be consistent between the two installations. It would be nice if
  this case could be more gracefully handled.

** Description changed:

  I'm not sure if this really counts as a bug or if it's just an
  unsupported configuration, but the post-install script
  (lightdm.postinst) doesn't ensure that "/var/lib/lightdm" exists and has
  the correct permissions if the user already exists, since it is relying
  upon "adduser" to create the home directory and only does so if the
  "lightdm" user doesn't already exists. This prevents lightdm from
  starting and leads to a fallback X session being created instead, which
  doesn't give any helpful information about the underlying problem.
  
  The reason I already had a lightdm user in passwd is because I was
  bootstrapping Ubuntu in a chroot and copied passwd/shadow/group/gshadow
  into it before installing packages, since I wanted to make sure UID/GIDs
  would be consistent between the two installations. It would be nice if
- this case could be more gracefully handled.
+ this case could be more gracefully handled, since I don't think it's all
+ that unusual.

** Description changed:

  I'm not sure if this really counts as a bug or if it's just an
  unsupported configuration, but the post-install script
  (lightdm.postinst) doesn't ensure that "/var/lib/lightdm" exists and has
  the correct permissions if the user already exists, since it is relying
  upon "adduser" to create the home directory and only does so if the
- "lightdm" user doesn't already exists. This prevents lightdm from
+ "lightdm" user doesn't already exist. This prevents lightdm from
  starting and leads to a fallback X session being created instead, which
  doesn't give any helpful information about the underlying problem.
  
  The reason I already had a lightdm user in passwd is because I was
  bootstrapping Ubuntu in a chroot and copied passwd/shadow/group/gshadow
  into it before installing packages, since I wanted to make sure UID/GIDs
  would be consistent between the two installations. It would be nice if
  this case could be more gracefully handled, since I don't think it's all
  that unusual.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lightdm in Ubuntu.
https://bugs.launchpad.net/bugs/1395530

Title:
  lightdm post-install script doesn't create /var/lib/lightdm if user
  already exists, preventing lightdm from starting

Status in “lightdm” package in Ubuntu:
  New

Bug description:
  I'm not sure if this really counts as a bug or if it's just an
  unsupported configuration, but the post-install script
  (lightdm.postinst) doesn't ensure that "/var/lib/lightdm" exists and
  has the correct permissions if the user already exists, since it is
  relying upon "adduser" to create the home directory and only does so
  if the "lightdm" user doesn't already exist. This prevents lightdm
  from starting and leads to a fallback X session being created instead,
  which doesn't give any helpful information about the underlying
  problem.

  The reason I already had a lightdm user in passwd is because I was
  bootstrapping Ubuntu in a chroot and copied
  passwd/shadow/group/gshadow into it before installing packages, since
  I wanted to make sure UID/GIDs would be consistent between the two
  installations. It would be nice if this case could be more gracefully
  handled, since I don't think it's all that unusual.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1395530/+subscriptions