<clever>
Henson: you could use the 1st one, to confirm your additions can phone-home on bootup
<clever>
Henson: the 2nd script, will then run qemu against the same disk, but without forcing the kernel/initrd, to confirm the bootloader works right
<clever>
Henson: the 1st one, runs the same kernel/initrd as kexec, but directly in qemu, for testing purposes (mainly to test justdoit)
<clever>
Henson: if you `nix-build simple-test.nix -A legacy_sata`, you will get a directory with 2 shell scripts
<clever>
lovesegfault: you just need a simple `DIRT = builtins.currentTime`
<clever>
lovesegfault: what happens if you build -A llvm ?
<clever>
it should be causing infinite recursion
<clever>
should be
<clever>
that would also count the build-time of llvm as well
<clever>
lovesegfault: the cut-off point between stuff you would expect to be in the cache (the host stdenv and gcc) and the stuff your trying to profile
<clever>
now it will differ every single time!
<clever>
> builtins.currentTime
<clever>
lovesegfault: use builtins.currentTime in the overlay
<clever>
lovesegfault: simplest is to just do a useless override at some point (using an overlay) so it has to rebuild that thing, and everything that depended on it
<clever>
lovesegfault: define "full", do you want to start at gcc?
2020-05-26
<clever>
> {a=42;} == {}
<clever>
hexagoxel: you need --read-write-mode to make the changes persist
<clever>
hexagoxel: nix-instantiate is read-only when you --eval
<clever>
ritchan: can you pastebin the entire dmesg output?
<clever>
ritchan: what does `dmesg` say?
<clever>
ritchan: local means nix will just open files in /nix/store directly
<clever>
jbox: no, nix-channel --update
<clever>
jbox: also, --add only takes effect when you --update
<clever>
jbox: you can reasonably assume that the names are the same between every channel
<clever>
jbox: it just uses the names from `nix-channel --list`
<clever>
jbox: nix-env -iA unstable.hello
<clever>
srid: as long as it has a kernel you control, it should work
<clever>
and you can start directly from the rescue shell, no need to install debian first
<clever>
once you are in, you just format and install like you would locally
<clever>
restoring the original OS
<clever>
if you get it wrong, you wont be able to ssh in, and it will reboot itself at the end of the hour
<clever>
youll want to edit the configuration.nix in there, to include the static ip config
<clever>
yeah
<clever>
srid: it will likely be much simpler, and you could skip step 1 entirely, if you use kexec
<clever>
srid: so you would have to use the kexec stuff i wrote
<clever>
srid: you need to wipe the disk to setup FDE, and that requires / to not be mounted
<clever>
ldlework: youll want to use a shell.nix that pins nixpkgs
<clever>
no need for any docker
<clever>
yeah, just nix-shell --pure and youll get the same tooling everywhere
<clever>
srid: yeah
<clever>
srid: the changes wont take effect until after you reboot manually
<clever>
srid: boot will just write to /boot and do nothing else
<clever>
srid: and things must be mounted in the right place before you `nixos-rebuild boot`
<clever>
its wrong because you moved things and didnt regen the file
<clever>
srid: mount them back to the correct place, and re-run nixos-generate-config to fix it
<clever>
srid: your hardware-configuration.nix is wrong, and it mounted the wrong things on bootup
<clever>
srid: you likely have the wrong device at /boot
<clever>
srid: double check what is mounted where
<clever>
srid: also, make sure you fix your hardware-configuration.nix first, with nixos-generate-config
<clever>
srid: you wanted `nixos-rebuild boot && reboot`
<clever>
srid: then youll want to reboot, for the if renaming to take effect
<clever>
betawaffle: this is something i did a while back, that runs a few nixos services in docker
<clever>
evanjs: then you didnt include the drivers for the block device in the initrd
<clever>
evanjs: does the block device exist in /dev/ ? or /proc/partitions?
<clever>
evanjs: if its using grub, you can add that without a regen
<clever>
srid: you can set the pw if you chroot in, or just edit $root/etc/shadow by hand
<clever>
evanjs: you may need to add boot.shell_on_fail i think it was to the kernel cmdline
<clever>
evanjs: what does blkid report?
<clever>
aveltras: it will depend on if your using stdenv.mkDerivation or cabal2nix, how you would add it
<clever>
aveltras: any attribute you add to the derivation becomes an env var
<clever>
aveltras: your using TH then? can you just read an env var at TH time and decide beteen $FOO or default to ../static ?
<clever>
aveltras: ah, was mixing file-embed up with another similar util
<clever>
aveltras: or a cmdline flag?
<clever>
aveltras: and why cant it be an env var you read at runtime?
<clever>
aveltras: which path are you trying to embed?
<clever>
ramses_: you can skip right to `nix-build '<nixpkgs/nixos>' -A system` to just build nixos and skip everything else
<clever>
ramses_: weird, i would try maybe `bash -v $(which nixos-rebuild) build` i think?
<clever>
ramses_: ah, not sure then...., what about nixos-rebuild build --fast ?
<clever>
ramses_: run $thatpath/bin/switch-to-configuration switch, how slow is it?
<clever>
ramses_: then its not network issues, now run `nix-build` normally on the drv, and it should product another storepath
<clever>
eyJhb: --list and --update use ~/.nix-channels but everything else uses ~/.nix-defexpr/
<clever>
eyJhb: yeah
<clever>
ramses_: what if you run `nix-build --dry-run` on the drv from instantiate?
<clever>
eyJhb: which channels you use are in ~/.nix-channels, but the actual data created by `nix-channel --update` is in /nix/var/nix/profiles/per-user/clever/channels/
<clever>
ramses_: is nix-instantiate slow to eval?
<clever>
ramses_: it will mainly tell you what function is being ran a lot
<clever>
,profiling ramses_
<clever>
srid: try the rescue system first, and then mount the rootfs, does it have logs?
<clever>
bqv: ovh lets you force reboot and switch to a rescue env
<clever>
you need to re-run nixos-generate-config every time you change what is mounted where
<clever>
srid: did you re-run nixos-generate-config when changing the mountpoint of things?
<clever>
srid: what did you tell nixos to mount as / ?
<clever>
srid: boot current, is in refernece to what is currently running, not the default
<clever>
srid: nixos is already first in the boot order
<clever>
srid: yeah, you want to adjust the order
<clever>
check the efibootmgr manpage, and you should see how to change the default
<clever>
before the cmd
<clever>
srid: ah, no, its NIXOS_INSTALL_BOOTLOADER=1
<clever>
srid: you have to add --install-bootloader to the previous cmd i think
<clever>
srid: also, you didnt clear the ESP before runnning boot
<clever>
srid: does `efibootmgr -v` also show things as configured?
<clever>
srid: my nas has a 64mb usb stick for /boot, lol
<clever>
srid: nixos wont create its own ESP, you have to make it yourself
<clever>
but its simpler to ditch the ext4 and put ESP right at /boot
<clever>
boot.loader.efi.efiSysMountPoint = "/boot/efi"; would let you keep /boot and ESP seperate
<clever>
srid: p2 was your old ext4 /boot, and p1 was the ESP at /boot/efi
<clever>
srid: and that ESP you mount to /boot should also be empty
<clever>
emily: you only delete the contents, you leave it as an ESP partition and fs
<clever>
morgrimm: or just --add-flag foo=bar ?
<clever>
srid: when using lustrate, the "switch-to-configuration boot" step should regenerate /boot/
<clever>
morgrimm: you could just --add-flag --foo --add-flag value
<clever>
morgrimm: check the source for wrapProgram, it should be there
<clever>
its able to cross compile brick, some lens stuff, and basic haskell code