lix-installer installs a non-functional setup #1158
Labels
No labels
Affects/CppNix
Affects/Nightly
Affects/Only nightly
Affects/Stable
Area/build-packaging
Area/cli
Area/evaluator
Area/fetching
Area/flakes
Area/language
Area/lix ci
Area/nix-eval-jobs
Area/profiles
Area/protocol
Area/releng
Area/remote-builds
Area/repl
Area/repl/debugger
Area/store
awaiting
author
awaiting
contributors
bug
Context
contributors
Context
drive-by
Context
maintainers
Context
RFD
crash 💥
Cross Compilation
devx
docs
Downstream Dependents
E/easy
E/hard
E/help wanted
E/reproducible
E/requires rearchitecture
Feature/S3
Importance
High
Importance
Low
imported
Language/Bash
Language/C++
Language/NixLang
Language/Python
Language/Rust
Needs Langver
OS/Linux
OS/macOS
performance
regression
Release Blocking
Non-urgent
Release Blocking
Urgent
stability
Status
blocked
Status
invalid
Status
postponed
Status
wontfix
testing
testing/flakey
Topic/Large Scale Installations
Urgency
High
Urgency
Low
ux
No milestone
No project
No assignees
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
lix-project/lix#1158
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Platform
This is on a GitHub Actions runner
Additional information
I run the installation with this snippet:
Since March 17 this now fails to install a working
NixLix.I tried following the log output suggestion of source-ing nix-daemon.sh here but the issue has persisted.
Output
Output
I'm seeing the same error (
could not connect to any lix socket (tried /nix/var/nix/daemon-socket/socket)) in a container environment, and noticed the regression also on that day.Since my environment is a container, I thought passing
--init noneto the installer would solve it, but it results in the same error.Indeed, it seems that our installers have some critical bug related to a change we made in the service management files. We are looking into this, I recommend using a versioned installer of the previous version (2.94.1), to do this:
(for Linux)
Am I doing something wrong or does this flag have no effect?
@ofalvai wrote in #1158 (comment):
The installer can't cope with the latest Lix, raito's suggestion downgrades Lix to the stable build before the current one. The installer not changing is expected.
For now, the installers have been roll backed to 2.94.0, @msfjarvis @ofalvai @ninanomenon could you confirm this resolved your issues for now?
Can confirm, thank you for the quick workaround ❤️
Also fixed for me.
@raito works for mee too. Thank you!
Awesome, closing here. We will ensure that the next installers we will release will not have this regression. Thanks for your patience and reaching out here.
@raito let me know if it deserves a ticket, but I think something regressed about this yesterday. As a quick repro, the Dockerfile example from the readme is now failing with this error:
Note how I passed the
--init nonein theRUNcommandIf I omit the flag, I get an error which is kind of expected (although it used to work previously):
That looks indeed wrong, thanks for the report. We will be looking into that ASAP.