<clever>
joko: min-free+max-free will trigger automatically when you hit min-free bytes, and will raise it to max-free, so it doesnt suffer from those 2 problems, though it currently has bugs that can break the eval
<clever>
joko: and its going to delete garbage, no matter how little there is, so it may wind up deleting the same 5kb every time, if the machine is very idle
<clever>
joko: but the problem with this method, is that it will only run once (or twice in this case) per day, and if you consume more then 128gig in that 12 hour period, it can still fail poorly
<clever>
which then stops at ~128gig free
<clever>
joko: so if 100gig is free, it will tell nix to GC 28gig worth of garbage
<clever>
joko: that is computing the difference between 128gig and how much is currently free
<clever>
adamantium: not sure
<clever>
adamantium: my intimate knowldge of nix in here is what got me a job at iohk.io :P
<clever>
if you supply a wrong hash, that matches an old version, nix wont notice, and will keep using the old version
<clever>
adamantium: id also recomend zero'ing out a few digits of the hash
<clever>
adamantium: yeah
<clever>
so the sha256 only changes if the gitrev changes
<clever>
adamantium: the hash is over the source tree, and the tree is fixed for a given git rev
<clever>
wdanilo: that script is using used to ship a .app bundle, which contains haskell binaries that nix had compiled
<clever>
adamantium: whatever revision you want, previously you used the latest master, so that would work
<clever>
wdanilo: thats some haskell code that will automatically copy libs from the nix store and run otool to make things run without nix
<clever>
wdanilo: you would need to run otool on the binaries to mutate the search path, and then just ship a lib dir and a binary that looks in the right path
<clever>
adamantium: you must also supply a valid revision from the git repo
<clever>
wdanilo: i dont know of any way to do it on darwin
<clever>
wdanilo: for linux, you can use user namespaces to automatically chroot things, nix-user-chroot and nix-bundle do that
<clever>
orivej: that example is for linux
<clever>
You can use the dd utility to write the image: dd if=path-to-image of=/dev/sdb.
<clever>
ixxie: yeah, that looks like a mac only thing
<clever>
adamantium: yeah, that would be the correct hash
<clever>
wdanilo: yeah
<clever>
wdanilo: yeah
<clever>
thats why it failed
<clever>
ixxie: rsda is a regular file in /dev, not a device
<clever>
ixxie: and your /dev/ fs is full, it didnt write to any block devices
<clever>
ixxie: `ls -ltrh /dev/` is missing
<clever>
ixxie: i see no mention of that in the dd man page
<clever>
adamantium: no, it probably hasnt tried to download homemanager yet
<clever>
ixxie: `ls -ltrh /dev/ ; df -h ` into a pastebin
<clever>
ixxie: what offset was it at when it failed?
<clever>
ixxie: how big is the device in `lsblk`?
<clever>
adamantium: you must first put a hash of a valid length into the nix, like 0000000000000000000000000000000000000000000000000000
<clever>
adamantium: can you gist the error?
<clever>
adamantium: you have to manualy look at the error when you first build it, then copy that hash into the nix code, and build it again
<clever>
look at what {^_^} said above
<clever>
nix will also give the url and hash when the dl fails
<clever>
nix-prefetch-url --unpack
<clever>
adamantium: fetchTarball doesnt need a hash
<clever>
adamantium: the length of the hash must be correct
<clever>
,tofu
<clever>
wdanilo: if you build nix without using nix (just ./configure && make), you can ship that nix binary around, and then use --store with it, that may help
<clever>
[root@nas:~]# time ls -l /nix/store/ | wc -l
<clever>
ive got a 3 drive raidz1, let me check its numbers...
<clever>
minutes, every boot, because the kernels involve navigating /nix/store/
<clever>
yeah
<clever>
so it has to iterate over every single folder in /nix/store/
<clever>
ive heard of grub slowing down by minutes, because it cant understand the b-tree indexes in zfs
<clever>
now that i see how to get gpt to work both ways, i always do a gpt install on every machine, no excuse not to
<clever>
yeah
<clever>
EFI doesnt have a 1.5, since the UEFI firmware provides fs access drivers
<clever>
for a GPT disk with legacy, it will use the dedicated bios boot partition to hold 1.5
<clever>
oops, MBR table
<clever>
for an MBR fs, 1.5 goes between sector 1 and partition 1, in the "unused" space
<clever>
adamantium: when grub is doing a normal install, it will concat the grub kernel, and the drivers for the /boot FS, to create a stage 1.5
<clever>
lol
<clever>
adamantium: i never put /boot on ZFS
<clever>
so you need to pre-load the "ubuntu" version of those modules, before you source it
<clever>
though, nixos's config will try to load modules built for the nixos grub, which fails
<clever>
so you can then source it from another grub
<clever>
if you set boot.loader.grub.device = "nodev";, then nixos will create a grub config file, but not install into any MBR
<clever>
adamantium: one thing ive done before, was just putting a source statement into the other grub config, to source the nixos grub config
<clever>
if you already have an easy way to boot the target into an installer
<clever>
and if your going to upload the entire closure anyways, you might as well have the option of shippimg that base image that wont be of much use
<clever>
adamantium: main thing i'm thinking of, is that if you create a machine from a base image, 90% of the time, the nixpkgs will differ, and it will have to re-upload the entire closure on the first nixops deploy
<clever>
so you can populate an entirely blank /mnt dir with a nixos build
<clever>
adamantium: after mounting everything under /mnt as normal, you can build the nixos on another box (possibly even with nixops), and then copy it over ssh, directly into /mnt
<clever>
adamantium: i also recently found another trick with nix copy
<clever>
adamantium: ah, a lot like my justdoit
<clever>
adamantium: what does themelios do?
<clever>
adamantium: you may be able to solve it by switching to `(import <nixpkgs> { config={}; overlays=[]; }).fetchFromGitHub`
<clever>
tokudan[m]: i also remember something about libffmpeg.so being just a different build mode, where it puts all the libs into one .so file
<clever>
hmmm, it has many, but not an ffmpeg
<clever>
it may help to see how it compares to the library ffmpeg provides
<clever>
tokudan[m]: it doesnt appear to be part of any proper package, it just happens to be included with a bunch of random things that shipped their own libffmpeg.so
<clever>
,locate libffmpeg.so
<clever>
cransom: i have had plans to just replace the entire board with something like a esp8266, and just make it purely wifi based :P
<clever>
and your shoulder is going to be in the way :P
<clever>
the LED is pointing down and backwards
<clever>
the low battery LED is imposible to see if you are actually using the headset
<clever>
so linux just lacks a low battery warning, and the headset just dies
<clever>
it measures the battery level via an unknown method, and then just plays a beep over the audio channel
<clever>
joko: the only anoying part, is that the low battery beep, is implemented by windows-only software
<clever>
joko: the usb keyboard bits allow it to report volume up/down events when i scroll the volume knob, and previous, play/pause, next, when i push the G1/G2/G3 buttons
<clever>
so pulseaudio wont crap its pants and disconnect applications in a damaging way
<clever>
and unlike a lot of bluetooth users, the capture/playback device is still present when the headset disconnects
<clever>
logitech g930 is the model
<clever>
other then some problems with the capture buffer building up latency in pulseaudio, it has never had any serious driver or connection problems
<clever>
joko: my wireless headset uses a proprietary USB dongle, it claims to be a usb sound card with HID features, so it just appears as a normal device in alsa, and also acts like a usb keyboard at times
<clever>
elvishjerricco: try that when its working, and see if it recovers on its own
<clever>
elvishjerricco: what if you simply `pactl exit` ?
<clever>
though nix-env -qA can also do it
<clever>
d1rewolf: thats a job for nix-instantiate
<clever>
ixxie: and what does the hardware-configuration.nix look like?
<clever>
ixxie: lspci, lsmod
<clever>
ixxie: and depending what your wifi drivers are, enable the right options to install them
<clever>
ixxie: run wpa_passphrase to generate a /mnt/etc/wpa_supplicant.conf
<clever>
ixxie: then fix the config in /mnt/etc/nixos and re-run nixos-install
<clever>
ixxie: ah, then first thing id recomend is to `systemctl stop autoreboot.timer`
<clever>
ixxie: the main install, or the kexec image itself?
<clever>
tobiasBora: in my bios, i can browse the filesystems, and select any .efi binary, and just execute it immediately, with no changes to config
<clever>
once nixos is booted, another round of `nixos-rebuild switch --install-bootloader` should correct the config
<clever>
i was thinking about doing a one-time override, to just select the grub binary and boot it
<clever>
tobiasBora: do you see grub files in the nearby directories?
<clever>
tobiasBora: you may be browsing into the wrong ESP
<clever>
tobiasBora: i'm able to do that when on my laptop
<clever>
tobiasBora: if you can find the right bios option, try browsing for a custom .efi file, and just manually select /boot/EFI/BOOT/BOOTX64.EFI for a one-time boot
<clever>
then you just have to handle the bootloader installation via switch-to-configuration+nixos-enter or maybe nixos-install -s
<clever>
dhess: this allows you to copy a pre-built nixos closure to the /mnt of a remote machine, which can even be a freshly formatted disk
<clever>
dhess: ive also recently been experimenting with `nix copy`, and it may be possible for nixops to deploy into a machine that was booted into any "install media"
<clever>
Takes a size in bytes, optionally suffixed with the usual K, G, M, and T suffixes, to the base 1024 (IEC)
<clever>
RuntimeDirectorySize=
<clever>
NickHu_: the docs for that option also point to `man logind.conf`
<clever>
NickHu_: once you find the right flag for the config file, services.logind.extraConfig
<clever>
NickHu_: systemd-logind i believe
<clever>
dhess: the signing is more about updating things without having to redo the ipxe binaries/config
<clever>
and it will only ever be able to boot what you signed (line 57 of the file)
<clever>
dhess: so you could pop a ipxe.efi into a EFI sys partition, whitelist its hash in the bios, and set a bios password
<clever>
dhess: oh, and i also recently noticed a secureboot, that you can whitelist the hash of a .efi file, without having to deal with keypairs at all
<clever>
dhess: nope, none of my machines support flashboot writing
<clever>
dhess: and the main script.ipxe is loaded over the network (and signed) so you can still dynamically reconfigure ipxe remotely
<clever>
dhess: so, assuming you can verify the ipxe binary (my original idea was to bake it into coreboot), every file loaded afterwards is signed by the keypair
<clever>
dhess: and line 88 then runs ipxe (using the linux-kernel format, via -kernel), and sets up a tftp server with qemu
<clever>
dhess: line 64 generates a custom build of ipxe, that has a script embeded into it (which permenantly enables requiring signatures), and embeds the certs
<clever>
dhess: line 50 creates an ftp dir, with signed kernel, initrd, rootfs, and script.ipxe files
<clever>
dhess: line 4 is a ipxe script with a complete menu, and the script itself is signed