2019-08-09

<clever> nix-build can do all of that
<clever> so nixops would need an arm build slave to finish things
<clever> but any config files, like /etc/ also have to be "native built" on arm
<clever> nixpkgs.system would instruct it to native-build
<clever> i think its nixpkgs.crossSystem
<clever> Miyu-chan: the arch is part of the $out hash
<clever> the file i linked requires an arm build slave, and wont cross
<clever> something i was toying with a year ago
<clever> if you set nixpkgs.system, it could also deploy to an arm
<clever> it just requires an x86-64-linux build slave to do the builds
<clever> Miyu-chan: given that nixops works on a mac already, it should work with an arm client too
<clever> nyanloutre[m]: nix-store --delete, dont force it
<clever> sphalerite: ive heard horror stories about SSD's not handling trim properly
<clever> pie_: it may be the pattern of syncs and random writes that zfs does
<clever> which improves write performance
<clever> some high end camera's have also gotten flack, because they dont let you erase a single clip, then only let you blkdiscard the whole ssd at once
<clever> that lets you boost write performace short-term
<clever> pie_: and if the ssd is brand new, or about to be sold, you should probably run blkdiscard on it, WARNING, IT WILL WIPE THE DISK
<clever> so that lets it pre-erase a large chunk of the disk
<clever> and erasing ssd blocks is a large chunk of write time
<clever> pie_: if trim is enabled, and doesnt malfunction, it will tell the SSD to erase any blocks that zfs isnt using
<clever> so you wont get metrics like this
<clever> Percentage Used: 23%
<clever> SMART/Health Information (NVMe Log 0x02)
<clever> yeah, definitely not nvme
<clever> pie_: what does iostat call it?
<clever> pie_: sata ssd or nvme ssd?
<clever> pie_: one min
<clever> pie_: ive had the same question
<clever> srhb: but if you have a foo.nix, that is only in imports on foo, there is no need for it to be conditional
<clever> pie_: was the ssd previously used, or brand new?
<clever> any shared stuff can just be imports = [ ./shared.nix ]; in both of them
<clever> marek: simpler answer is to just have 2 files, and choose which one you put into imports = [ ./foo.nix ];
<clever> which end has a higher util% in `iostat -x 30` (wait for the 2nd sample)
<clever> first, you need to figure out if its read or write throttled
<clever> it just hasnt found enough cachable data to cache
<clever> its only using 2.5gig for you, but it wants to use 4.8gig
<clever> it will dynamically change the goal, based on how much is free
<clever> pie_: i never set arc max, and it automatically limited itself to 1.4gig
<clever> 05:00:41 2.9K 199 2.7K 93 3 295 2.4K 0 2.3K 1.4G 85 15 7 199 2.7K 2.1K 92 181 93 0 1.4G
<clever> time read dmis dhit dh% mrug mru mfu mfug mread c ph% pm% mm% miss hits mhit mh% mmis hit% eskip arcsz
<clever> pie_: what does this say?
<clever> arcstat.py -f time,read,dmis,dhit,dh%,mrug,mru,mfu,mfug,mread,c,ph%,pm%,mm%,miss,hits,mhit,mh%,mmis,hit%,eskip,arcsz 10
<clever> pie_: zfs will never use more then 50% of the ram by default
<clever> 362be9608c3 is what i'm testing the fix on
<clever> kalbasit: still building!
<clever> kalbasit: maybe the new muslc stuff...
<clever> yep
<clever> ERROR: Got argument default_library as both -Ddefault_library and --default-library. Pick one.
<clever> checking that rev...
<clever> ah, but i can reproduce this if i use a newer nixpkgs temporarily
<clever> trace: warning: The option `boot.binfmtMiscRegistrations' defined in `/home/clever/apps/nixos-configs/qemu.nix' has been renamed to `boot.binfmt.registrations'.
<clever> for me, it builds on this rev
<clever> [root@amd-nixos:~]# nix eval nixpkgs.lib.version
<clever> "19.09pre179307.bc94dcf5002"
<clever> i'll test things on this end...
<clever> you would have to look for git revs leaking out in --version strings
<clever> but you cant see branches, so you dont know what commits to look for
<clever> and can still see commits from the private repo you cant access
<clever> if you fork a private repo, into another orginization, and then your access is revoked, the org still has access to its fork
<clever> that has a bigger impact with private github repos
<clever> and commits on one fork exist in all other forks
<clever> kalbasit: behind the scenes, every fork is stored in the same .git dir
<clever> kalbasit: i think it will force you to make a fork first
<clever> just delete line 7
<clever> remove line 7 from my default.nix
<clever> and this is forcing static only
<clever> ahh, i'm forcing it to both dynamic and static
<clever> so it suddenly started to obey mesonFlags
<clever> and in the commit i linked, glib switched to meson
<clever> yeah
<clever> ah
<clever> the build system was redone, and that broke compatability
<clever> kalbasit: i think this commit was to blame?
<clever> to see when it was changed in a conflicting way
<clever> youll want to check the git history on glib, in nixpkgs
<clever> an older nixpkgs is more likely to fix it
<clever> no un-commited changes locally
<clever> *looks*
<clever> kalbasit: thats a problem with the latest glib, i thought i had fixed it already
<clever> --option system aarch64-linux may also work in this case
<clever> pkgs = import <nixpkgs> { system = "aarch64-linux"; }
<clever> you can just set system when importing nixpkgs
<clever> kalbasit: after adding qemu.nix to imports, and setting qemu-user.aarch64 = true; in your configuration.nix
<clever> so if you run darwin in qemu, and use the right arguments on both ends, you can mount a virtio-fs
<clever> surpisingly, darwin now supports virtio-fs

2019-08-08

<clever> you can manually export it as a one-time fix, then nixos-rebuild to experiment with a long-term fix
<clever> nakkle: thats the value it should have
<clever> /root/.nix-defexpr/channels:nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixos:nixos-config=/etc/nixos/configuration.nix:/nix/var/nix/profiles/per-user/root/channels
<clever> [root@amd-nixos:~]# echo $NIX_PATH
<clever> nakkle: thats not what it should be, did you change nix.nixPath or set NIX_PATH in a .bashrc ?
<clever> nakkle: what does `echo $NIX_PATH` say?
<clever> ajs124: journalctl -u display-manager
<clever> yep
<clever> iqubic: builtins.trace "foo" "bar" will print foo, then return bar
<clever> hyper_ch2: so the dataset names are leaking
<clever> hyper_ch2: but you do need to know the name of the dataset
<clever> and how big the dataset is
<clever> hyper_ch2: because you need to be able to delete a dataset you lack the keys for
<clever> hyper_ch2: i believe all dataset names, snapshot names, and properties
<clever> pie_: very
<clever> pie_: the root device under zfs should still grow, according to lsblk
<clever> # Key length 32, device size 975722511 sectors, header size 2050 sectors.
<clever> [root@system76:~]# cryptsetup luksDump /dev/nvme0n1p2 --debug
<clever> reboot?
<clever> pie_: the cryptsetup resize that originally alerted you to the fubar
<clever> `sudo nix-env` operates on roots ~/.nix-profile, not the system profile
<clever> ,tofu
<clever> MasseR: you usually need to override src=
<clever> nope
<clever> pie_: what is the starting offset of the partition?
<clever> pie_: are you starting 544 from the partition or disk?
<clever> `you would use masterKey.bin in your cryptsetup command as the master key file`
<clever> 2nd answer
<clever> xxd i think it was
<clever> pie_: master key must be binary, read the 2nd answer in the stackexchange link you pasted
<clever> so 396 bytes in, youll find a 4 byte int32
<clever> and the stripe width is the 44th byte in the slot
<clever> so slot 4 is at 352 bytes
<clever> pie_: slot 1 is at 208, slot 2 is at 256, each slot is 48 bytes
<clever> pie_: the error is complaining about the stripe count on slot 4
<clever> pie_: the sensitive stuff doesnt really start until byte 112 (hex 0x70), with the hash of the master key
<clever> page 6 lists the types and offsets of every byte
<clever> and my laptop is using luks 1
<clever> Version: 1
<clever> LUKS header information for /dev/nvme0n1p2
<clever> section 3.1, version 1
<clever> page 5, partition header
<clever> unknown
<clever> oh, i truncated the url
<clever> pie_: page 2 of the pdf explains the header
<clever> elvishjerricco: after expanding the partition, he told luks to expand the luks volume, and it failed
<clever> and the remaining bytes in that line are all 0's
<clever> pie_: that would be a single byte you censored, plus the encoding of aes :P
<clever> pie_: are the censored bytes 01 61 65 73?
<clever> pie_: id say find the luks channel on irc
<clever> pie_: try this?
<clever> [root@system76:~]# cryptsetup luksDump /dev/nvme0n1p2 --debug
<clever> 2019-08-08 03:00:25 < clever> and luksKillSlot may be able to nuke slot 4
<clever> pie_: you may need to kill the keyslot first
<clever> the 2nd answer in stackage shows how to convert the hex key to binary
<clever> elvishjerricco: except all luks commands fail due to the header being corrupt
<clever> then open it, dmsetup dump the key, close it, kill a keyslot, then try to remake a keyslot
<clever> cryptsetup luksformat /root/fake-volume
<clever> pie_: create a new luks "volume" (in a file), and then play with that
<clever> pie_: ive also got an idea
<clever> i'm guessing the key from dmsetup, possibly in binary form
<clever> and luksKillSlot may be able to nuke slot 4
<clever> luksAddKey can also take a --master-key-file
<clever> it may also need --type
<clever> if i'm reading the man page right, this might let you open a volume and ignore the keyslots
<clever> 2019-08-08 02:32:53 < clever> luksOpen --master-key-file foo
<clever> bbl
<clever> no idea
<clever> elvishjerricco: he expanded the partition
<clever> this appears to be a valid command, according to the man page
<clever> luksOpen --master-key-file foo
<clever> but if the slots are corrupt, dumping the master key is your only hope of saving the data on the disk
<clever> and if you can decrypt a slot, you can load the master key into ram, and open the disk
<clever> pie_: the master key is held in the key slots, encrypted with each passphrase you can unlock with
<clever> oh, that might do it
<clever> thats what luksDump does
<clever> it sounds liek the master key is at risk, and if you shutdown, the disk is essentially wiped
<clever> luks should be able to dump while mounted
<clever> cryptsetup does have a command to backup the luks header, but its a bit late
<clever> headers survived, weird
<clever> pie_: if you blkid the luks partition, what does it say?
<clever> pie_: backup everything, asap, dont shutdown
<clever> pie_: you did backup the tables to a different disk, right? :P
<clever> pie_: and the partition start is the same between the backup and main disk?
<clever> most partition editors will refresh automatically when you save&quit
<clever> does lsblk show the device as bigger?
<clever> yeah, lol
<clever> lookup the specs on how gpt is laid out
<clever> and a protective mbr
<clever> gpt has a backup copy of the whole table at the end of the partition
<clever> ah, maybe thats why i cant find it in my usual stuff, lol
<clever> i remember writing one, and found it in my nix store, but cant find the nix expr!!
<clever> binwalk is great, but i havent found a nix package of it yet
<clever> for the luks volume, correct
<clever> the partition uuid is only used in the efi vars, to tell the bios which ESP to boot from
<clever> linux operates entirely on fs uuid's
<clever> the partition and fs uuid
<clever> thanks to gpt, every fs has 2 uuid's
<clever> pie_: but the part uuid is almost never used, efi is about the only thing to use it
<clever> pie_: some editors have the abilitty to set the part uuid
<clever> pie_: yeah
<clever> aws machines run that on the rootfs, on every boot
<clever> ,locate growpart
<clever> pie_: there is also the aws resize tool
<clever> ,locate cgdisk
<clever> danderson: ls -l /run/{current,booted}-system/kernel
<clever> make 100% sure you get the partition offset and index the same
<clever> pie_: not many partition editors support resize
<clever> pie_: gparted wont let you do it for unsupported things
<clever> pie_: ah yeah, thats the first step
<clever> pie_: first, youll need to research how to expand a luks volume
<clever> jlv: or edit the requirements
<clever> and thats likely what its checking for
<clever> jlv: there are special version symbols in a library, which you can see with readelf
<clever> jlv: try googling the error?
<clever> jlv: the library must be in lib, not lib/x86_64-linux-gnu
<clever> jlv: what is the output of ldd, what are the contents of the lib dir on the package you made?
<clever> jlv: run ldd on the binary your trying to patch
<clever> jlv: is it named the same as what ldd shows?
<clever> jlv: first, is the fixup phase enabled? did you set phases= ?
<clever> jlv: have you read the source for autoPatchelfHook ?
<clever> worldofpeace: qemu -cdrom foo.iso i think
<clever> so its not testing the iso layer things
<clever> and build-vm boots it very differently
<clever> ah
<clever> one of those should already import that for you
<clever> infinisil: what about the attrs of release.nix?
<clever> exarkun: your welcome :)

2019-08-07

<clever> exarkun: fetchTarball wants the unpacked sha256, so you need nix-prefetch-url --unpack
<clever> exarkun: the module is setting some overlays, so you cant use pkgs when fetching it
<clever> exarkun: try using builtins.fetchTarball instead of pkgs.fetchFromGitHub
<clever> exarkun: can you pastebin your configuration.nix file?
<clever> samueldr: the "editor" is slack :P
<clever> alienpirate5: the target isnt supported by those scripts
<clever> ,tofu
<clever> danderson: yeah

2019-08-06

<clever> so it doesnt know the luks is required
<clever> aiverson: ah, yeah, nixos-generate-config has trouble finding the path from fs->lvm->luks
<clever> aiverson: what FS is ontop of the luks?
<clever> aiverson: gist helps when dealing with multiple files at once
<clever> aiverson: if you pastebin both the configuration.nix and hardware-configuration.nix, i can take a look at them
<clever> aiverson: you can boot the install ISO again, luksOpen, and mount everything back under /mnt/
<clever> aiverson: can you pastebin your configuration.nix ?
<clever> pie_: and more likely to work via nixos-rebuild
<clever> aiverson: what problem are you having?
<clever> pie_: i would just make my own foo.nix, that has both common-modules and configuration.nix under imports
<clever> Hedgework: nix-env -q
<clever> exarkun: sounds like a good use for disabledModule, and then file a PR once its working nicely
<clever> exarkun: one min
<clever> i'm not that familiar with the internals of the cross-compile stuff yet
<clever> arianvp: ahh, thats probably a bug in nixpkgs then
<clever> > pkgsCross.armv7a-android-prebuilt.hello
<clever> arianvp: ah, i missed those, you can try that one also
<clever> > pkgsCross.aarch64-android-prebuilt.hello
<clever> arianvp: youll either want to fix nixpkgs to support the android ndk, or fix nixpkgs to support aarch64 muslc
<clever> arianvp: and anything built normally with nix expects a /nix/store/, so you either need to do some funny stuff to make the libraries co-operate with /system/lib/ or just go full static
<clever> arianvp: android doesnt obey the FHS, and all the libraries are in /system/lib i believe
<clever> arianvp: pkgsCross.muslpi will cross-compile static armv6l binaries, which can then run on most android devices
<clever> arianvp: this is the only option i can see existing right now, armv7 would be better but i dont see a preset entry for it
<clever> > pkgsCross.muslpi.hello
<clever> zeta_0: which is already in PATH, just run `cheatsheet`
<clever> zeta_0: home-manager installs the packages to ~/.nix-profile/bin/
<clever> zeta_0: if you run the cheatsheet binary in bin, it will tell you where to find the pdf
<clever> petercommand: cant think of anything else to check
<clever> petercommand: doesnt look like youve done anything wrong
<clever> petercommand: you may need to run yarn outside of nix to update the lock file
<clever> petercommand: maybe its not in the yarn.lock file?
<clever> petercommand: yarn --offline
<clever> that allows the build slaves to use their own cache config
<clever> 246 extraOptions = ''
<clever> 250 builders-use-substitutes = true
<clever> 213 nix = {
<clever> averell: one sec...
<clever> zeta_0: any package in nix can have multiple outputs, which can be GC'd independently
<clever> > "${haskellPackages.CheatSheet.data}"
<clever> > haskellPackages.CheatSheet.outputs
<clever> zeta_0: split output packages
<clever> the rpath on the binary must be modified before it can run
<clever> emilsp: then the rpath isnt being set right, how are you currently doing it?
<clever> emilsp: what error is it giving?
<clever> emilsp: that
<clever> > lib.makeLibraryPath [ zlib ]
<clever> __monty__: #nix-darwin is already a channel
<clever> emilsp: zlib is the one you want
<clever> ,locate libz.so
<clever> __monty__: your telling nix to copy your entire /Applications and /share into /nix/store/
<clever> __monty__: pathsToLink should be a list of strings, not actual paths
<clever> zeta_0: the ONLY thing the binary does, is print the path you want!
<clever> zeta_0: $data has the pdf in it, but there is no easy way to access it, but that path will be in the Paths_CheatSheet.datadir :: String, which the code may make use of
<clever> zeta_0: the $out has a bin/cheatsheet so you could probably run that binary
<clever> __monty__: can you gist your current nix expr?
<clever> iqubic: all of nixpkgs, search it for makeWrapper
<clever> iqubic: it has to be added to PATH using makeWrapper
<clever> iqubic: makeWrapper
<clever> detran: youll need to override part of closure to use jdk11, check the default.nix for closure first
<clever> detran: run `nix-store -qR` on the path of the closure binary
<clever> you could do similar to get just gcc and clang, without the many utils they also contain
<clever> this is how i get just strings and readelf, without getting all of binutils
<clever> one min
<clever> Mateon1: it wont be able to find any other library youve installed
<clever> and you dont need to write a nix file, just `nix-shell -p foo`