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
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
