<infinisil>
Maybe making a reproducible example would be a good idea, where you can say, run this command in this repo and you get this result, but I expect this other thing to happen
jonringer has quit [Remote host closed the connection]
<hazel[m]>
i really appreciate it when I say something in this IRC and someone pings me on github multiple days later because they remember me talking about it
<pie_>
clever: i mean, i have a directory, not a tar yet
<clever>
once the build is done, nix will purify the directory, removing all timestamps, ownership, and the read/write bits
<pie_>
yes thats why im askingxD
<clever>
no way to disable that
beertoagunfight has joined #nixos
<pie_>
ok let me put it this way, i know that nix purifies its imports, im guessing the answer is that i _cant_ shove a tar before the import, but thats why i thought id ask
<jackdk>
I am seeing "substituter 'https://hydra.iohk.io' does not have a valid signature for path" warnings for things that ought to be coming from the iohk cache. Reposting here because I suspect I've done something wrong with the config I'll paste what nix considers the config to be, below:
<pie_>
oh doh of course the installer cd does that
<pie_>
and here i thought im doing something weird
<jackdk>
In a single-user nix install on mac, is the only narinfo cache the one at $HOME/.cache/nix/binary-cache-v6.sqlite ? I'm trying to figure out why this setup has cached the fact that some paths have bad signatures, when that's definitely not the case
ddellacosta has joined #nixos
<clever>
jackdk: it might also be in /nix/var/nix/db/db.sqlite
<pie_>
clever: 1) thanks 2) i guess there isnt a restriciton requiring the overlay to be moutned before the other filesystems?
<pie_>
* after
<clever>
pie_: the overlay can be mounted at any time before its being used
<jackdk>
clever: /nix/var/nix/db/db.sqlite only appears to have tables `DerivationOutputs`, `Refs`, and `ValidPaths`
<clever>
jackdk: if something is a validpath (in your /nix/store), it may have a copy of the sig locally
<jackdk>
clever: ok, before I take a nuke to this nix install, is there a good way to purge these? nix-collect-garbage didn't do anything useful
ddellacosta has quit [Ping timeout: 245 seconds]
<clever>
jackdk: what is the exact error msg?
<jackdk>
substituter 'https://hydra.iohk.io' does not have a valid signature for path
<clever>
jackdk: for which path?
waleee-cl has quit [Quit: Connection closed for inactivity]
ahmed_elgabri has joined #nixos
<jackdk>
many. `/nix/store/s8w5b48szmkiy0v0dxhnshja0rx7rs13-ghc-8.6.5-configured-src` is one. I suspect https://github.com/NixOS/nix/issues/4258 but /root/.cache/nix does not exist
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
TrinityHex[m] has joined #nixos
ddellacosta has quit [Ping timeout: 252 seconds]
aaabbbbbbbbbb has joined #nixos
jgt has joined #nixos
<{^_^}>
[nixpkgs] @raboof opened pull request #120696 → <!-- To help with the large amounts of pull requests, we would appreciate your reviews of other pull requests, especiall… → https://github.com/NixOS/nixpkgs/pull/120696
<{^_^}>
[nixpkgs] @raboof closed pull request #120696 → <!-- To help with the large amounts of pull requests, we would appreciate your reviews of other pull requests, especiall… → https://github.com/NixOS/nixpkgs/pull/120696
<jdelStrother>
The v8 package no longer builds on macos, I've been trying to fix it but seem to be going down a rabbit hole. First off, is it expected that xcbuild provides the 10.12 SDK, and nothing newer is available?
<jdelStrother>
And then, I've worked around that but hit compile errors (unknown argument: '-ftrivial-auto-var-init=pattern'). Looks like trivial-auto-var-init needs clang 8, and I've got clang 7 by default. Clang 7 seems pretty old. And how did this compile on linux if that's also using clang 7?
<jdelStrother>
Or would it have been using gcc there?
<{^_^}>
[nixpkgs] @Luflosi opened pull request #120714 → ocamlPackages.dtoa: disable hardening feature based on more accurate condition → https://github.com/NixOS/nixpkgs/pull/120714
<dotlambda>
Okay, I manually turned a grepped list of files into a list of attributes. Now how do I use `nix repl` or something similar in a bash script to get the maintainers of each package?
<{^_^}>
[nixpkgs] @sternenseemann opened pull request #120716 → ocamlPackages.paf: init at 0.8.0; ocamlPackages.letsencrypt: init at 0.2.4 → https://github.com/NixOS/nixpkgs/pull/120716
<sterni>
dotlambda: or nix-instantiate --strict --json --eval -E '(import <nixpkgs> {}).${ATTR}.meta.maintainers' which is I guess a bit more stable for now in terms of interface
<{^_^}>
nix#3032 (by lilyball, 1 year ago, closed): `nix eval` doesn't understand expressions that don't begin with a paren
<dotlambda>
thibm: Yeah it was actually pretty obvious from the examples `nix eval --help` I just didn't read well enough. The upcomimg `--expr` is definitely better.
jdelStrother has quit [Quit: Ping timeout (120 seconds)]
jarkad has joined #nixos
jarkad has quit [Client Quit]
thblt has left #nixos ["ERC (IRC client for Emacs 28.0.50)"]
<clever>
yaymukund: this will diff the final derivation for 2 generations, in my case, revealing that i only changed a single word in /etc/nix/machines
<yaymukund>
i might just write a script to clean up the output of nixos-rebuild, i think i just want the list of changed derivations without the sha prefixes
ahmed_elgabri has joined #nixos
ddellacosta has joined #nixos
<yaymukund>
(i say 'just', but i'm sure i overlook complexities)
<Henson>
I'm trying to figure out how to classify in the nixpkgs heirarchy a support package called "Andrews Web Library" in PHP. It consists of PHP code that is used, as far as I can tell, by only one package: DAViCal, for which I have written a NixOS module. I know where to file DAViCal in the nixpkgs heirarchy, but not AWL. It would be either in phpPackages or phpExtensions. I'm thinking the former
<Henson>
or perhaps it would belong somewhere else.
<o1lo01ol1o>
Does anyone know what the following haskell.nix error is referring to? error: The Nixpkgs package set does not contain the package: m (system dependency)
<o1lo01ol1o>
I don't know what "m" is.
andycandy has joined #nixos
<Henson>
o1lo01ol1o: what's in the haskell.nix file? It's trying to use the package "m" which it can't find.
sabry97[m] has joined #nixos
ddellacosta has joined #nixos
<__monty__>
I'm providing a path to a tarball to a nix expression, using nix-build -E. Might this be the cause of the "dumping very large path" warning. And if so is there a way to avoid having to repeat this?
figgyc has quit [Quit: No Ping reply in 180 seconds.]
<__monty__>
To avoid XY: If I evaluate the expression without arguments I don't get the warning. If I do pass an argset with store paths I do get the warning. Is there a way to avoid this? I assume nix is copying the contents of the tarball to the store each time?
<Henson>
__monty__: yes, Nix copies the contents of the tarball each time
<Henson>
__monty__: I'm not sure of the exact expression you're evaluating, but because Nix has lazy evaluation without args could simply be resulting in a lambda that is unevaluated. Then when you pass arguments it has to evaluate it at which point it's sucking in the large tarball and giving you the error.
<Henson>
__monty__: if the thing you're compiling really /is/ that large, then that's fine. But you want to avoid pulling in large things unnecessarily.
<Henson>
compiling -> building
<Henson>
__monty__: I've had this problem before when I'm building things from source, and I've accidentally had a bunch of stuff in the source path that I generated while debugging and testing. All that extra stuff gets pulled in too because it's part of the files being used by Nix to build the package.
sangoma has quit [Quit: WeeChat 3.1]
<__monty__>
Henson: The expression usually uses a tarball which is in the binary cache. I'm trying to override that tarball specifically. Wondering whether I can't pass in a hash of the tarball or something so nix realizes it's already unpacked it before.
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ddellaco_ has joined #nixos
<{^_^}>
[nixpkgs] @vbgl merged pull request #120714 → ocamlPackages.dtoa: disable hardening feature based on more accurate condition → https://github.com/NixOS/nixpkgs/pull/120714
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Spritzgebaeck>
i got following problem: error: packages '/nix/store/z1bzg30mapyk87cdb9k327b8fmnwy7pc-freecad-unstable-2020-09-25/doc/FreeCAD/ThirdPartyLibraries.html' and '/nix/store/gykqmk4v4jl0ynxf6gjr3bzncvabg0yx-freecad-0.19.1/doc/FreeCAD/ThirdPartyLibraries.html' have the same priority 5; use 'nix-env --set-flag priority NUMBER INSTALLED_PKGNAME' to change the priority of one of the conflicting packages (0
<Henson>
__monty__: that might generate a warning. If it really is that big, then just put up with the error. To be able to bring in the tar file from the nix cache you'd probably have to look in nixpkgs to see where the tar file is being pulled in and then put that in your code so it's being pulled in in exactly the same way.
<Henson>
__monty__: but in the end it'd still be pulling in a bunch of stuff. If you're doing local testing and it's not pulling in extra stuff by mistake, then just ignore the error.
<__monty__>
It's just that this seems to take quite long for each build.
<Spritzgebaeck>
i have no idea how to fix this error
ddellacosta has quit [Ping timeout: 252 seconds]
evils has quit [Ping timeout: 240 seconds]
evils has joined #nixos
rubm has joined #nixos
<Henson>
__monty__: what's taking a long time? Unpacking the file, compiling the contents of the file?
<Henson>
__monty__: also, if you're trying to override the tarball, then pulling it in from the binary cache won't work because it'll be different than what is usually used, right?
<srhb>
Spritzgebaeck: The easiest to understand is probably to not install two versions of freecad in the same profile
<srhb>
Spritzgebaeck: So uninstall the one you don't want first.
<thibm>
__monty__: I hit this once with a 30GB gzipped tarball. I tried a lot of things and, IIRC, I remounted the store in rw and put the file there myself (with the right hash)
<__monty__>
Henson: I don't know since there's no feedback from nix-build. And yes the point is to override it. I don't want to use the binary cache I want to kinda turn it into a fixed-output derivation so nix realises it already has it unpacked in the store.
<__monty__>
thibm: Thankfully this tarball is far smaller, so I don't mind nix copying it the first time. It's just the subsequent times I'd like to avoid.
<Henson>
__monty__: ok. Can you give me the snippet of how you're trying to import the file? I would imagine it should take only a few seconds or a couple tens of seconds to import 54MB into the store.
<srhb>
Spritzgebaeck: No, it's complaining that it cannot install the second one, because they both contain the same file, which would link to the same place in the profile in question. :)
<turlando>
Hello everybody. I'm trying to make boot.initrd.network.ssh.authorizedKeys source the pubkey from a file in the same path as the nix file. I'm doing something like 'authorizedKeys = [ (builtins.readFile ./boot.pub) ]' but I get error: opening file '/etc/nixos/boot.pub': No such file or directory. What should I do?
<srhb>
Spritzgebaeck: You do have the one path though, althought it may be nonobvious from whence it came.
<Spritzgebaeck>
i don't get it
<srhb>
Spritzgebaeck: OK, let's break it down. Are you trying to install freecad via nix-env, or is this something like home manager or nixos rebuild?
<Spritzgebaeck>
nix-env
<Spritzgebaeck>
nix-env -iA nixos.freecad
<Spritzgebaeck>
this
<srhb>
Spritzgebaeck: In your nix profile (~/.nix-profile) you'll see a number of directories
<Spritzgebaeck>
sorry, really new to nixos
<Spritzgebaeck>
yeah
<srhb>
Spritzgebaeck: In there you'll find ThirdPartyLibraries.html
<srhb>
Spritzgebaeck: Which is a file from an already-installed (in your profile) version of freecad.
<srhb>
Spritzgebaeck: nix-env is complaining that it cannot add a package which _also_ contains that file to your profile, because it doesn't know which of the packages should win and finally provide the symlink to the file named thusly.
<Spritzgebaeck>
okay
<Spritzgebaeck>
but how is this installed and how i get rid of it?
<srhb>
Spritzgebaeck: nix-env -q to list your installed packages. You may have freecad there in some incarnation which nix does not detect is "equivalent" to yhe one you're trying to install
<srhb>
Spritzgebaeck: nix-env -e (the-name from -q)
<Spritzgebaeck>
ah tehre
<Spritzgebaeck>
freecad-unstable-2020-09-25
<srhb>
Spritzgebaeck: Nuke that with nix-env -e
vidbina has quit [Ping timeout: 265 seconds]
<srhb>
Spritzgebaeck: -e (that name) that is
<srhb>
tab completion should work :)
<Henson>
turlando: does the file /etc/nixos/boot.pub exist?
<srhb>
Spritzgebaeck: Afterwards, you should be able to execute your original command
<pennae>
nixos.that doesn't exist anyway :D
<srhb>
Spritzgebaeck: What likely happened is that the package changed name, so nix-env does not detect that it should consider it the _same_ "installed package" and overwrite the old with the new.
tbreslein has joined #nixos
<turlando>
Henson, it was just me having to sleep a bit more. What I'm doing is having my config in some folder F and then using a makefile to copy it over /etc/nixos. I placed my ssh key inside F, but I forgot I have to copy it over /etc/nixos to work and that paths are relative to that directory. I solved updating my makefile to have it copy my key
<Henson>
turlando: excellent!
<srhb>
Spritzgebaeck: I hope that made some amount of sense :)
<Spritzgebaeck>
srhb: it's working, thanks a lot
<Spritzgebaeck>
srhb++
<{^_^}>
srhb's karma got increased to 150
<srhb>
Spritzgebaeck: Great! :)
<__monty__>
Henson: Here you go, https://git.io/JOFiV . It's not easily reproducible though.
<Spritzgebaeck>
srhb: yeah, it makes sense, but installed last week nixos, came from arch and it's really differnet. so i'm currently try to understand how this stuff is working in nix
gustavderdrache has joined #nixos
<srhb>
Spritzgebaeck: Oh yeah, it's very different. Hope you enjoy plus/minus the inevitable frustrations though :)
ddellacosta has joined #nixos
Maxdamantus has quit [Ping timeout: 265 seconds]
wallacer has quit [Ping timeout: 250 seconds]
<pennae>
came from arch too a couple weeks ago. really digging the override mechanism :3
<srhb>
pennae: Indeed, that's really nifty :)
<Spritzgebaeck>
we will see :D maybe i will ask 1-2 other questions
<Henson>
__monty__: it looks like you're not calling the function correctly. boostrapFiles is a member of the set produced by the make-bootstrap-tools.nix file, and isn't accepted as an argument. You could try using "
<Henson>
__monty__: what is it you're trying to achieve with this? It looks like the make-bootstrap-tools.nix file return a set which contains many different things. the bootstrapFiles set is returned by that file and contains paths generated from the "build" attribute of that set. This bootstrapFiles set is then used by the "unpack" attribute.
lordcirth has quit [Ping timeout: 250 seconds]
<Henson>
__monty__: I think the way you're trying to accomplish your goal needs to be tweaked, so I need to know what your goal is.
ddellacosta has joined #nixos
<__monty__>
Henson: I'm trying to generate the bootstrap-tools using updated bootstrap-tools.
meh` has joined #nixos
nitsky has joined #nixos
nitsky has quit [Client Quit]
<Henson>
__monty__: the bootstrapFiles attribute is generated by the build attribute which is generated by the make-bootstrap-tools.nix file. It takes a whole bunch of different packages and bundles them into the bootstrapFiles attribute. It is not generated from the bootstrap-tools.cpio.bz2 file, the bootstrap-tools.cpio.bz2 is generated by it.
ddellacosta has quit [Ping timeout: 240 seconds]
<__monty__>
Henson: Yes, but it does import nixpkgs and I want that import to use a new bootstrap-tools.
<__monty__>
It's basically a test of the bootstrap-tools.
ahmed_elgabri has quit [Ping timeout: 245 seconds]
<Henson>
__monty__: it looks like bootstrapFiles gets used by the "unpack" attribute. You could try to override the bootstrapFiles attributes in the derivation generated by "unpack", but I don't know where you'd go from there.
<asymmetric>
is there a way to pin a grub entry? so that regardless of how many times i run `nixos-rebuild boot`, it will stay there and i won't lose it?
ahmed_elgabri has quit [Ping timeout: 245 seconds]
abathur has quit [Quit: abathur]
ddellacosta has quit [Ping timeout: 240 seconds]
o1lo01ol1o has quit [Read error: Connection reset by peer]
<{^_^}>
[hydra] @grahamc merged pull request #921 → Make it possible to enable email notifications when creating a jobset → https://github.com/NixOS/hydra/pull/921
abstrn has quit [Ping timeout: 240 seconds]
o1lo01ol1o has joined #nixos
cole-h has joined #nixos
abstrn has joined #nixos
zebrag has quit [Quit: Konversation terminated!]
<turlando>
I'm doing my first upgrade from nixos 20.03 to 20.09. I've read the documentation and I should just run nix-channel --add https://nixos.org/channels/nixos-20.09 nixos as root. Should I remove the old channel afterwards or nix will take care of that? I'm reading the faq about when updating stateVersion: what does it mean «2. You have verified all instances of stateVersion in the code in <nixpkgs/nixos>.»?
zebrag has joined #nixos
zebrag has quit [Client Quit]
<srhb>
turlando: I don't remember if nix-channel --add overwrites the same-named channel or not. If it does you're good, if not, delete the old one and create the new one. I don't know where the stateVersion comment is coming from, can you link it? Normally you should _not_ alter stateVersion during an upgrade.
<cransom>
the channel names are unique, you have to remove the old before adding the new.
<cransom>
stateVersion is a compatability level setting. if you have stateversion 20.03, and there was a change for a module you use, in order to not break your system when using 20.09, the 20.09 module will adjust itself to be compatible with 20.03.
<turlando>
cransom: perfect, good to know, thank you!
<turlando>
cransom: so I should just leave it to 20.03 and forget about it?
<srhb>
turlando: OK, that's not very end-user-oriented. It literally means "check that all NixOS modules do something sane and don't brick the user's state by reading all the source code"
<cransom>
if you want to change it (but you aren't required to), you need to look at the modules in your configuration and see if they make specific changes between 03 and 09 and change that state yourself.
<srhb>
turlando: Yes, you should :)
<cransom>
i'd recommend leaving it.
<srhb>
turlando: Essentially before changing it, you'd have to take manual steps to upgrade all stateful data, which is not trivial. In fact I'd probably rather do a backup-reinstall-restore than bump my stateVersion :P
<cransom>
though, i did some work this weekend on a machine that had an 18.09 stateVersion and i updated it because of an internal OCD.
<turlando>
cransom I'm actually thinking about sticking to 20.03 for some time more :)
<turlando>
thanks for the tip srhb
<pennae>
nixos-option really could do with better command line error handling than throwing an exception :<
ericsagn1 has quit [Ping timeout: 260 seconds]
ddellacosta has joined #nixos
<srhb>
pennae: True... Though it's probably hard to "do better" _and_ give good feedback when an eval error occurs in a configuration or the nixpkgs/nixos itself.
<{^_^}>
[rfc39-record] @grahamc pushed commit from rfc39 to main « Automated team sync results. »: https://git.io/JOFxm
<srhb>
turlando: I would not recommend to stick on "20.03" if you mean NixOS itself (_not_ stateVersion) :)
<pennae>
srhb: mostly thinking about printing a small usage summary instead of throwing UsageError("unrecognized flag …")
<srhb>
pennae: Ah, yes, ok :)
<pennae>
also interestingly that dumps core on this this machine
<pennae>
... and on others too
<srhb>
pennae: Here, too. Arguably a feature! ;-)
<turlando>
srhb yep, I mean nixos. So without touching stateVersion I should be able to upgrade seamlessly?
<srhb>
turlando: Yes (that is the purpose of stateVersion) :)
<srhb>
turlando: To ensure that modules remain compatible with however state was provisioned on your machine, even though you're using a newer nixpkgs.
<pennae>
srhb: potholes deep enough to drown in are technically also features?
<srhb>
pennae: You know, opinions and stuff. I find it very handy! I sympathize with the idea that it isn't very user friendly though.
justanotheruser has joined #nixos
<srhb>
(... but imagine if I couldn't remember the name for the --do-dump-core flag!) -- ok I'll stop myself now.
<NemesisD>
why is it on https://nixos.org/channels i see nixpkgs-unstable but all the other versioned channels are for darwin? nixpkgs-stable has broken dropbox for me which is preventing me from making any home-manager changes so wanted to switch to something more stable
<srhb>
NemesisD: I don't think nixpkgs (non-darwin) has had versioned channels like that, there's nixpkgs-unstable and nixos-${version} and nixos-${version}-small
<cransom>
nixos = nixpkgs. nixos just happens to have more tests, which means more things likely work.
<NemesisD>
ok so even if i'm not using nixos (just nixpkgs on darwin) i could switch to nixos-20.09?
ericsagn1 has joined #nixos
<srhb>
NemesisD: You could, but the test set that must pass for the channel to update may be less relevant to you.
<cransom>
yes.
domogled has joined #nixos
<srhb>
NemesisD: You can check by investigating the "hydra job for tests" links here: https://status.nixos.org/ -- and then pressing constituents
<__monty__>
Henson: Ok, thanks, no worries.
<NemesisD>
i would say 80% of the time something blows up with my nix configuration its some transitive python dependency not passing its test suite
<srhb>
NemesisD: Those are the jobs that must succeed for the channel to update.
<srhb>
NemesisD: nixos will contain things that are simply not relevant to darwin, but whether the full set is better/worse for you depends on your case.
<srhb>
(eg. whether the linux nixos installer can uefi boot. You probably don't care.)
<NemesisD>
ah whoops i'm undercaffinated. i'm running nixpkgs on *debian* not darwin lol
<srhb>
Well, the logic still sorta applies :)
<srhb>
The test set that's relevant to you from nixos may be larger though.
<Henson>
I'm trying to figure out how to classify in the nixpkgs heirarchy a support package called "Andrews Web Library" in PHP. It consists of PHP code that is used, as far as I can tell, by only one package: DAViCal, for which I have written a NixOS module. I know where to file DAViCal in the nixpkgs heirarchy, but not AWL. It would be either in phpPackages or phpExtensions, or maybe somewhere else
jmeredith has quit [Quit: Connection closed for inactivity]
<srhb>
Henson: Extensions look like the sort of things that are likely to include a .so and require php.ini configuration.
<srhb>
Henson: But if you're using it in just that one place, maybe you don't want to make it a separate package at all, and just inline the dependency where it's needed. That sounds horribly non-DRY, but if they always go together...
<NemesisD>
i'm mainly just trying to lower the probability of not being able to build my system when i run an update
<srhb>
NemesisD: THen pick the channel that has tests for the most things you use.
<srhb>
NemesisD: There's no channels-as-a-service unless you run your own hydra-ish thing that only bumps when _your_ system builds. :)
<srhb>
(Incidentally, totally doable)
<Henson>
srhb: it doesn't include a .so file, it's just a bunch of PHP code that is used by the DAViCal package. I had considered simply rolling it into the DAViCal derivation, but didn't know if that was the right thing to do
<srhb>
Henson: I wouldn't sweat it either way. :) Think you can do just that.
<NemesisD>
srhb: is there something i can do when this happens that can maybe get me out of this bind? weekly i usually run nix-channel --update and then home-manager switch. if something breaks can i "undo" that nix-channel --update?
<srhb>
And reviewers might have more opinions than the channel anyway, so just be prepared to adjust and you're good :)
<Henson>
srhb: on Debian it's a separate package, but I need to see if it's only used in the DAViCal software, in which case it should be incorporated into it.
<srhb>
NemesisD: nix-channel --rollback
tbreslein has quit [Quit: tbreslein]
<srhb>
NemesisD: Many people also forgo channels in favor of a declarative nixpkgs, or a git checkout, etc.
<Henson>
srhb: ok, being flexible is pretty easy.
<Henson>
srhb: thanks for the advice
<srhb>
Henson++
<{^_^}>
Henson's karma got increased to 13
<NemesisD>
srhb: what's a declarative nixpkgs? like pinning to a particular revision in their config?
ddellac__ has quit [Ping timeout: 240 seconds]
<srhb>
NemesisD: Another simple way is to just test beforehand. NIX_PATH=nixpkgs=https://github.com/NixOS/nixpkgs/archive/nixos-unstable.tar.gz nixos-rebuild build <-- build the system against current nixos-unstable, if it fails, just don't bump nix-channel! :)
<srhb>
NemesisD: Yes, exactly that.
<srhb>
NemesisD: Then everything becomes `git revert`
avaq has quit [Ping timeout: 260 seconds]
rj has quit [Ping timeout: 240 seconds]
<NemesisD>
srhb: cool. i'll look into it. and for the time being the rollback worked great. thank you!
<srhb>
NemesisD: Sure :)
Agustin2021 has joined #nixos
camsbury has quit [Ping timeout: 250 seconds]
erasmas has joined #nixos
rj has joined #nixos
saschagrunert has quit [Quit: Leaving]
fuzzypixelz[m] has quit [Quit: Idle for 30+ days]
ArtemPelenitsyn[ has quit [Quit: Idle for 30+ days]
<pennae>
hmm is there an option to put nixos-enter into initrd yet
<turlando>
srhb I grabbed a keyboard and a screen. The issue is that now it tries to import another encrypted pool during boot time, preventing the machine to fully boot unattended. My boot sequence was initrd -> dropbear start -> I ssh in, zfs load-key -a, killall zfs -> boot continues. Now I can unlock the system pool and import another pool but it will try to unlock it nonetheless during boot time from systemd
<pie_>
pennae i think you can put anything in initrd? question is if it will actually work?
<pie_>
doesnt that need systemd or something? i think stage 1 doesnt have systemd? (yet?(
<srhb>
turlando: Not sure I understood. It's trying to decrypt a pool that _shouldn't_ be necessary for boot?
<turlando>
srhb exactly. The system pool can be successfully unlocked from ssh in initrd, when I resume the boot process after unlocking the system pool it will load systemd which will try to unlock another pool making the machine hang there
<pennae>
pie_: haven't checked either! initrd not having a systemd of any kind would explain containers being hard-killed when stopped immediately after starting (before stage 2 starts)
<srhb>
turlando: Actually that probably doesn't matter if it's systemd doing it.
<turlando>
srhb it isn't set in my config. Maybe I can solve the issue disabling zfs-import-<pool>.service at boot time?
<pie_>
pennae: are they even actually starting or is that just what it says?
<srhb>
turlando: I feel like those units shouldn't even exist on NixOS... Are you not using legacy mounts?
<turlando>
I'm using legacy mounts, but it is the pool being encrypted, not a filesystem, I have to point out
<srhb>
Oh I guess they should for non-"boot" pools. Hmm.
<pennae>
pie_: they start, get the "please shut down" signal to nspawn in stage1, stage1 ignores it, execs stage2, stage2 knows of no shutdown and just goes on. then systemd terminated the entire tree because the stop command didn't stop anything
<turlando>
(also it's trying to import the pool, not mount the fs)
<srhb>
Yes, understood.
griff__ has joined #nixos
<turlando>
Thanks for helping by the way
<pennae>
pie_: the log for the container goes all the way to the login prompt in that case, until the stop timeout elapses and all containers processes get -9d
<srhb>
turlando: I'm afraid I don't know the answer. You might want to import it in the initrd since you're already loading all the keys.
<pie_>
pennae: *shrug* good to know
<srhb>
turlando: OTherwise yes, you could disable that unit (or figure out why it's there at all)
<pie_>
pennae: wait but how does systemd even know about it if its not running yet in stage1?
<turlando>
srhb I imported the pool in the initrd session, and it didn't boot nonetheless. I think it's not visible to systemd? Could that be?
<bqv>
Hey question
<pennae>
pie_: don't quite understand that question, sorry
<bqv>
If go.sum contains hashes already, what is the point of vendorSha256?
ahmed_elgabri has joined #nixos
<bqv>
(in buildGoModule)
<srhb>
turlando: I don't want to guess at that. I think you should probably follow the logic in nixos/modules/filesystems/zfs.nix
<gchristensen>
you'd need to use IFD or recursive nix to read the hashes from buildGoModule bqv, recursive nix isn't really stable, and IFD is prohibited from Nixpkgs for performance reasons
<srhb>
turlando: (Which is not a user-friendly answer, sorry :))
<pennae>
the host systemd knows about the (declarative) container unit from configuration, and systemd treats a container unit as "starting" until the container'd systemd has reached its boot target
<bqv>
gchristensen: Oh, I keep forgetting that. Fair enough
superherointj has joined #nixos
<gchristensen>
it'd be really cool to stabilize recursive nix
zupo has joined #nixos
<pennae>
shutdown signals sent by the container unit on the host are only honored by container systemd, not stage1. so they're just ignored if you start and then stop the container in quick succession
<srhb>
turlando: It looks like the logic is: If the pool is used in fileSystems, but it's not a "root pool" (eg. needed for boot in stage2) an import service is generated
<srhb>
turlando: But that doesn't answer why it fails. Because it's already loaded I guess?
<srhb>
turlando: This definitely feels like a bug.
<srhb>
turlando: Do you have any helpful logs from the failing import unit?
ahmed_elgabri has quit [Ping timeout: 245 seconds]
<turlando>
srhb if I manage to get the machine up and running I can get some logs I guess. What should I look other than zfs-import-$pool.service?
<srhb>
turlando: Just there. My suspicion is that it ends up prompting for credentials, which I think is what you hinted at, that somehow we've "lost" that prior information between stage1 and systemd coming up.
<srhb>
Which, frankly, I don't understand.
<turlando>
In the meanwhile can I just disable the service in order to have a booting machine? Not a nixos expert, can I do it from the nix config?
<pie_>
pennae: im distracted so good luck but do tell me if you find anytihng out. ive been doing a lot of container poking so it would be good to know
<pennae>
that's all we've found out so far on that. haven't really looked into it much
<srhb>
turlando: yes, you should be to set `wantedBy = lib.mkForce [];` for that service, though it _won't_ be imported then, which may cause other dependents to fail.
<turlando>
srhb I managed to get a booting and ssh-able machine. Now what should I do? If I make the FS needed for boot or if I disable the import service and I import it by hand in stage1 would it be visible to the booted system or it will hang at boot again?
<turlando>
Not sure if I managed to explain my concern
cybrian has joined #nixos
<srhb>
turlando: I think you did, and unfortunately the only answer I feel completely comfortable giving is "try either out" -- I'm still not sure _why_ it hangs at all, so I'm not sure how it will react. :)
<turlando>
I can give you the logs for that unit in the meanwhile. Which one do you suggest trying first srhb?
superherointj has quit [Quit: Leaving]
<srhb>
turlando: I'd try making it necessary for boot :)
jgt has quit [Ping timeout: 252 seconds]
<srhb>
turlando: And yeah, feel free to pastebin the logs.
<turlando>
Meanwhile I can say that making it needed for boot removed the systemd service, let's reboot and see how far it goes
<srhb>
turlando: Well, presumablt it's the 16:08:15 failure to get a password.
<turlando>
Definitely, but nothing we didn't already knew. Curious thing is that systemd claimed there was not a timeout
amerigo has joined #nixos
<conkker>
is it possible to drop into a nix-shell for a nixpkgs package? so I have all the dependencies I need installed for building in my local directory
<conkker>
basically use the buildInputs from some package as the inputs for my shell
ddellac__ has quit [Ping timeout: 252 seconds]
<lukegb>
err, yes, e.g. `nix-shell '<nixpkgs>' -A hello` should do that, iirc
<turlando>
srhb another strange thing is that zfs load-key -a asks me the passphrase for the system pool only
<srhb>
turlando: OK that is weird. Is it a different host device from the system pool? Say, a different bus? USB?
<srhb>
turlando: Because that seems to suggest that the pool is not discovered at all in stage 1. Can you check?
<srhb>
turlando: (If so it may just be a missing module)
<conkker>
lukegb: it doesn't seem to install anything, for example I can't run cmake
<turlando>
srhb zpool import <poolname> does work at stage1. It doesn't ask for password though, I think zfs caches them IIRC
<srhb>
Oh, that may just be it. Meh, the other explanation was easiter :) If it's the same password that's probably just normal.
<lukegb>
conkker: hrm, it does seem to work for me
<turlando>
Another thing that changed from 20.03 is that before I would run killall zfs from the ssh session in order to kill the interactive prompt asking for a password in stage1, now it will not do anything and there seems not to be a zfs process at all
<srhb>
turlando: you will need the requestEncryptionCredentials thing for it to block on zfs load-key, iirc.
<srhb>
turlando: Wait, how'd you even get to stage2 without that?
<srhb>
Lucky break on import being stuck? Hmm.
<srhb>
Oh it's true by default. Nevermind me.
<srhb>
But then it should absolutely be stuck until killall zfs...
<conkker>
lukegb: I tried neovim.unwrapped instead of just neovim and I think it works, thanks
<turlando>
srhb Sorry, I explained it very bad. It does block on zfs load-key at stage 1, which allows me to connect via ssh and unlock the pool remotely. After I unlocked the pool via ssh I would run killall zfs in order to kill the interactive prompt in stage1 and resume the boot process. Now it doesn't seem to do anything and my ssh sessions keeps being alive. I tried killall sshd but now I can't ssh in the fully booted system :\ I hope it's
<turlando>
clearer now
<srhb>
turlando: It is clearer now, yes.
<lukegb>
conkker: ah, yeah, wrapped packages make it harder
<turlando>
This upgrade it's been very painful but yet less painful than upgrading debian :)
gnopdf has joined #nixos
<srhb>
turlando: I don't have a secondary encrypted pool which is probably why I don't know exactly your case. However, on nixos-unstable, I absolutely do pkill zfs after loading the keys.
<srhb>
turlando: Which implies, if sshd keeps up, that the mounts required for stage2 aren't all there.
<turlando>
Let me reboot and try again. What makes everything extremely complicated to debug is that I have no screen where I keep this machine so I have to do back and forth moving the case because moving the screens I have it's even more painful
<srhb>
turlando: Yuck, yes. Not easy :)
anandprabhu has joined #nixos
<turlando>
I haven't rebooted yet, but it seems I can ping the machine, so network configuration is done, but I can't ssh. I feel like it's stuck again somewhere at systemd
<srhb>
turlando: Just to confirm, this is _after_ having ssh'ed to deliver encryption keys via initrd ssh, yes?
stree has quit [Ping timeout: 260 seconds]
<turlando>
Yes, also after doing killall sshd
<srhb>
OK. Can you reboot and not killall sshd? We can inspect from there.
<turlando>
But I want to try again to be sure about the pkill zfs thing
<srhb>
Right
<srhb>
You should not have to killall sshd, to be clear.
<srhb>
If that's necessary, something is already wrong.
ManiacOfMadness has joined #nixos
<srhb>
And we'd like to inspect logs at that point.
<turlando>
So, I rebooted and I'm at the initrd ssh prompt. Should I do zfs load-keys -a?
<srhb>
Let's find out if zfs is running first
<srhb>
with whatever ps | grep etc. shenanigans you have available
<turlando>
srhb, I can confirm zfs load-key -s is running
<srhb>
-s?
<turlando>
-a, typo
<srhb>
OK :P Then load-key -a and check again
<turlando>
1 / 1 key(s) successfully loaded. zfs load-key -a still running, same PID
<srhb>
then surely pkill zfs?
<srhb>
And now ssh _should_ shut down
<turlando>
pkill zfs, a NEW zfs process is spawn, ssh still running
<turlando>
Should I try unlocking the other pool too at this point?
<srhb>
Go ahead :)
<turlando>
OK, this is curious. zpool import <poolname> claims it's already imported, and sure enough it shows up in zpool status
bruh-buy has joined #nixos
<srhb>
Well this is zfs encryption right? So we can show them in status and import them but not mount filesystems.
<srhb>
zfs list should even show datasets.
bruh-buy has quit [Client Quit]
<srhb>
Or hm, I just realized I don't use full-pool encryption, maybe I'm wrong.
<turlando>
I'm not sure about your first sentence: I'm encrypting the whole pool and not the single filesystems. Also I'm leving nixos handling the mount having the mount zfs option set to legacy
<turlando>
Anyway zfs list shows all the filesystems
<srhb>
Yeah I think I was making assumptions based on my current setup.
<srhb>
try killing the new zfs process?
<hyper_ch>
srhb: I would not recommend to use full pool encryption
<srhb>
Nor I.
<srhb>
But that's the setup at hand :)
<hyper_ch>
you have more flexibility by creating an unencrypted pool and then make an encrypted dataset
simba has quit [Ping timeout: 245 seconds]
<hyper_ch>
I just use pool/encZFS/Nixos
<srhb>
We're not formatting anything right now, just debugging stage1/stage2 :)
<turlando>
srhb now the zfs process is definitely gone, but sshd is still alive and kicking
<srhb>
turlando: Puzzling. OK, let me check if we can extract logs from somewhere...
<turlando>
hyper_ch thanks for the suggestion. Given that I'm going to encrypt everything nonetheless, apart from the advantage of not having /nix encrypted what are the benefits?
<hyper_ch>
turland: I got bitten when I started using pool level encryption when it was first released
<hyper_ch>
there was a format change about a year later
<hyper_ch>
and I had to zfs send / recv it all to some other location
SurfacePro4Loser has joined #nixos
<turlando>
Did it corrupt the pool?
<hyper_ch>
if I had used pool/encZFS/[....].... then I could have send the data to on the same pool
stree has joined #nixos
<hyper_ch>
no, it did not corrupted the pool
<SurfacePro4Loser>
Is there a resource for NixOS prebuiilds? like, say, for a Surface Pro 4?
<turlando>
hyper_ch well that's expected to be fair
<srhb>
turlando: You still have ssh, right? can you try mounting it manually (somewhere) ?
<turlando>
srhb: mount -t zfs home/tancredi /tmp/test: mount: mounting home/tancredi on /tmp/test failed: Permission denied
<srhb>
turlando: That's interesting. Did you unlock it by hand?
<hyper_ch>
turlando: did you unlock it with your key?
<turlando>
srhb Yep, I did zpool import home and it did not ask me for a password since it was cached (I guess? hope?)
ddellac__ has joined #nixos
<hyper_ch>
no, that's not unlocked
<hyper_ch>
zfs load-key -a
anandprabhu has quit [Quit: Konversation terminated!]
andycandy has quit [Quit: Connection closed]
<turlando>
I will do it again, but I did it already for the system pool
<hyper_ch>
(-a will ask for all datasets that have not inherited keys)
<srhb>
hyper_ch: It would be helpful if you scroll up before butting in :)
<hyper_ch>
scrolling up is overrrated ;) sorry
<srhb>
turlando: I suspect it was either not inherited or you have some encrypted sets that are not inheriting :)
<turlando>
srhb maybe hyper_ch is right, it's asking me a password for home
simba has quit [Ping timeout: 250 seconds]
<srhb>
Did we have an -r in there at some point...
<srhb>
hyper_ch: Wait, can you elaborate on "not inherited" keys? Are you saying that the second time, it'll load for datasets? That doesn't sound right.
<turlando>
Honestly I'm not sure of anything anymore, but -r should unlock recursively, and I'm unlocking two different pools :\
<turlando>
Now... how can I resume boot? :)
<hyper_ch>
srhb: not sure what you mean. You can have different keys on different datasets..... or if you inherited the key before you can set it to something else on the child dataset
<turlando>
hyper_ch but they're two different pools
ddellac__ has quit [Ping timeout: 240 seconds]
<hyper_ch>
so they don't share the same key
<srhb>
turlando: You can _try_ rerunning stage1, but I think it's safer to try rebooting and doing the unlock over in the order we now know(???) does the thing.
<turlando>
let's reboot!
simba has joined #nixos
SurfacePro4Loser has quit [Quit: Connection closed]
<turlando>
Aaaaand 'reboot' does nothing! shutdown is not present :\
<srhb>
And once again, if done right, sshd should die on its own. But I'm puzzled. Just to clarify, you're saying(?) that you ran zfs load-key -a. Both pools have the same encryption keys. We expect both to be unlocked. You can _see_ datasets on pool "home" but not mount them, with permission denied?
<hyper_ch>
well, on my homeserver where I have a second encrypted pool, I use this (also for remote unlocking) to make sure, key is requested for both pools: https://paste.simplylinux.ch/view/raw/6f3ac87c
hdhog has quit [Quit: Lost terminal]
<turlando>
srhb everything you said it's correct
rajivr has quit [Quit: Connection closed for inactivity]
dev_mohe has joined #nixos
<srhb>
turlando: That's so weird.
jgt has joined #nixos
<hyper_ch>
do you have to enter the password twice for each pool upon boot?
<samueldr>
iirc in our initrd shutdown/reboot are busybox's, and those don't work if you don't use busybox as PID1
SurfacePro4Loser has joined #nixos
<hyper_ch>
well, twice - for each pool once
<srhb>
turlando: My only vague feeling at this point is that somehow the datasets are also encrypted and not unlocked the first time, but frankly I didn't think that was even possible.
<srhb>
(it may not be and I'm leading you astray)
<turlando>
I know. It's the first time I'm using zfs native encryption, I'm a long time ZFS user on FreeBSD (since FreeBSD 7) and I would encrypt with geli (similar to linux's cryptsetup), but AFAIK dataset metadata are not encrypted, so it makes sense that we're able to zfs list and zpool status, I guess?
<SurfacePro4Loser>
srhb 3 but not 4. 1-2-3 are interchangable and 4-5-6-7 are close too but 3 to 4 is a no on HW. thank you for the link though
<srhb>
turlando: Try sticking an -r in there
<srhb>
SurfacePro4Loser: Ah, sorry :/
<hyper_ch>
just making sure: you have two different pools and both are encrypted. At boot you only get prompted for one password.
<srhb>
hyper_ch: We're running load-keys via initrd ssh
<srhb>
hyper_ch: load-keys -a to be specific
<turlando>
srhb too late :\ I rebooted, did zfs load-key -a, asked me for the system passphrase. Ran zfs load-key -a again and it immediately quit
<hyper_ch>
srhb: but it's two different pools, right?
<srhb>
turlando: Oh, well, closer!
<srhb>
hyper_ch: Correct.
<hyper_ch>
second pool needs also to be imported
<turlando>
Yeah, but I expected it to aske me for the home passphrase!
<srhb>
turlando: Are we racing import of the secondary pool?
Guest4333 has quit [Killed (verne.freenode.net (Nickname regained by services))]
supersandro2000 has joined #nixos
<Henson>
does anybody have any experience setting up local delivery only e-mail on NixOS? I'm trying to set it up to prevent non-local e-mail delivery.
superherointj has quit [Quit: Leaving]
abstrn has joined #nixos
lordcirth has quit [Remote host closed the connection]
lordcirth has joined #nixos
<pennae>
haven't done it, but should be reasonably easy with postfix and just restricting it to 127.1 / ::1
<pennae>
or do you also mean blocking outgoing mail?
rubm has quit [Ping timeout: 260 seconds]
<Henson>
pennae: yes, blocking outgoing mail. I suspect it has something to do with default_transport or one of those transport options. Currently looking it up.
moet has quit [Quit: leaving]
<pennae>
you might want to specify recipient restrictions with a check_recipient_table that disallows all but mydomains targets
<pennae>
(it's been a while since we configured postfix, sheesh)