Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LightDM doesn't properly install within a container #452

Closed
jerbmega opened this issue Apr 17, 2023 · 8 comments
Closed

LightDM doesn't properly install within a container #452

jerbmega opened this issue Apr 17, 2023 · 8 comments
Labels
bug Something isn't working

Comments

@jerbmega
Copy link

Describe the bug
LightDM is not properly installed when added within a Containerfile.
Adding lightdm in a Containerfile results in a build that succeeds, but cannot properly run LightDM, as the user is not made due to an error. I also get a dbus-daemon error within the container. I've reproduced this on both Fedora 37 and 38.

I get the following error during build:

error: Found argument '-M' which wasn't expected, or isn't valid in this context

	If you tried to supply `-M` as a value rather than a flag, use `-- -M`

USAGE:
    useradd [OPTIONS] <username>

For more information try --help
Installing: lightdm-1.32.0-2.fc37.x86_64 (fedora)
dbus-daemon: no process found

When running lightdm --debug in the resulting install, the following relevant debug output is noted:

...
[+0.10s] WARNING: Could not enumerate user data directory /var/lib/lightdm-data: Error opening directory `/var/lib/lightdm-data`: No such file or directory
-snip-
[+1.42s] DEBUG: Session pid=1225: Started with service `lightdm-greeter`, username `lightdm`
Failed to get information on user lightdm: Success
[+1.46s] DEBUG: Session pid=1225: Authentication complete with return value 10: User not known to the underlying authentication module
...

The package works properly when layering it over an existing installation, implying this is solely a container issue.

To Reproduce

  • Add rpm-ostree install lightdm into a Containerfile. The build will succeed but will not run properly once deployed, with the above symptoms. This can be reproduced both via a local Podman build as well as Github Actions.
@jerbmega jerbmega added the bug Something isn't working label Apr 17, 2023
@juhp
Copy link

juhp commented Apr 17, 2023

You have an rpm-ostree based container?

This may not be the best place to solve this problem.

@jerbmega
Copy link
Author

Yes, it's a custom image I intend to boot off of. There are similar issues on this repo (#413 and #430) and I was advised this is the right place to file a bug for this workflow.

@travier
Copy link
Member

travier commented Apr 17, 2023

The package works properly when layering it over an existing installation, implying this is solely a container issue.

Then this is an rpm-ostree issue. Please file the issue there.

I'm closing this here as we don't ship ligthdm in Silverblue.

@travier travier closed this as not planned Won't fix, can't repro, duplicate, stale Apr 17, 2023
@travier
Copy link
Member

travier commented Apr 17, 2023

Error opening directory `/var/lib/lightdm-data`: No such file or directory

This should be converted to a tmpfiles.d config file instead of being manually created in the package.

@travier
Copy link
Member

travier commented Apr 17, 2023

@jerbmega
Copy link
Author

I'll file an issue with rpm-ostree, thanks.

@juhp
Copy link

juhp commented Apr 18, 2023

(I am still curious: are there any examples of rpm-ostree based containers generally available?)

@travier
Copy link
Member

travier commented Apr 18, 2023

@juhp You should checkout the great work from the https://ublue.it/ team :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants