<clever>
booglewoogle: my first guess is that you need to enable a winewow build
<clever>
it may be simpler to just load the modified nix file with callPackage
<clever>
and you would need to remove wine64 from the middle of the string
<clever>
booglewoogle: you would need to be altering the postInstall attribute with overrideAttrs
<clever>
jabranham: doesnt matter that much, nixos-unstable updates a little less often, because it waits for the nixos tests to pass, but nixpkgs-unstable can also hang because it waits for darwin things to pass
<clever>
booglewoogle: i notice that the commit is not in any branch
<clever>
the above hook will run strip on all binaries, if dontStrip = true; is absent
<clever>
roflik: justdoit.nix itself is a nixos module, so you can just add it to the imports section of any nixos, live or normal
<clever>
nix can also be used to generate a disk image with a full install, rather then a live env
<clever>
roflik: also, rather then using a liveusb, you could do a proper nixos install to the usb, then you can just edit whatever you want, nixos-rebuild, and the changes will persist
<clever>
roflik: it can be overcome by just tweaking justdoit.nix to accept the file as a param
<clever>
roflik: if you control the network, then ipxe is also an option
<clever>
which was giving a full gui for installing, along with an editor for configuration.nix, that could show option descriptions
<clever>
its main limitation right now, is that you have to remake the entire iso and usb if you want to change the initial configuration.nix
<clever>
roflik: so you literally boot the machine, and type justdoit on a shell, and your done
<clever>
roflik: that is similar to justdoit, the current version of justdoit has a minimal configuration.nix baked into it, and then the whole justdoit is baked into the iso you dd to something
<clever>
Moredread: it generally has to be done with overlays, but you can sometimes use nixpkgs.config.feature = true;
<clever>
tilpner: sounds like a problem fairly low-level within the keyboard drivers
<clever>
tilpner: oh, and does ctrl+alt+f1 give a working console?
<clever>
headphone jacks give insert/remove events, my wireless headset has volume events for the knob, keyboard/mouse do what you would expect
<clever>
tilpner: if you run `evtest` as root, you can select any event source, and then see the raw events coming from it
<clever>
evtest would be one of the next steps then
<clever>
then youll have a "usable" keyboard to open logs and debug it further
<clever>
tilpner: in theory, you can steal letters from random open apps, to assemble `nix-env -i onboard` and `onboard`, though enter is harder (or just do it fast after bootup?)
<clever>
tilpner: using left mouse, you can select text, and middle mouse to paste text
<clever>
> onboard.meta.description
<clever>
tilpner: one min, i have a crazy idea...
<clever>
tilpner: got a usb keyboard?
<clever>
tilpner: oh, the keyboard stops, not the whole pc
<clever>
tilpner: does the cpu feel abnormally hot?
<clever>
tilpner: is the cpu fan spinning?
<clever>
things have probably improved since i last ran into this issue
<clever>
yeah, just noticed that in its --help
<clever>
maybe it was objdump that couldnt
<clever>
oh, interesting, the x86-64 readelf can also see that field now
<clever>
this is what happens if i run the armv6 readelf against itself, under qemu-user
<clever>
Tag_CPU_arch: v6
<clever>
/nix/store/4snh8f34408x61x6lpwqcri86cq829jw-binutils-2.30/bin/readelf -A /nix/store/4snh8f34408x61x6lpwqcri86cq829jw-binutils-2.30/bin/readelf
<clever>
yeah, it is fairly slow
<clever>
and then your machine can magically run aarch64 binaries
<clever>
this nixos module allows you to just qemu-user.aarch64 = true;
<clever>
nix will normallize the hash when display, so it may not display what was in the nix file
<clever>
use the nix-hash util to convert it
<clever>
elvishjerricco: base16 vs base32 hash
<clever>
elvishjerricco: another solution is to compile the TH with a different ghc
<clever>
hmmm, but ghc may still have trouble targeting 2 arm at once
<clever>
elvishjerricco: yeah, you would need a non-ios arm os, to run iserv under
<clever>
elvishjerricco: if your TH is touching ios objects, your probably doing something wrong
<clever>
elvishjerricco: yeah, you would need to use qemu-user-arm, and not a real ios device
<clever>
dhess: i think angerman has done x86->ios cross-compiles with TH
<clever>
dhess: running iserv-proxy under nodejs solves it for ghcjs, and under wine solves it for linux->windows
<clever>
dhess: iserv-proxy can help with TH
<clever>
pareidolia: can you pastebin the whole output of nixos-rebuild when it fails?
<clever>
elvishjerricco: only for valid outputs
<clever>
the rpi doesnt have pci or sata
<clever>
pareidolia: that allows you to inspect it and see why its wrong
<clever>
pareidolia: it leaves it in the store, but doesnt register it as valid
<clever>
then its not a 404 page
<clever>
pareidolia: try just less then, is it binary?
<clever>
pareidolia: what does `file /nix/store/b532v0f48jbhw151h7v8v6ab8vshlj4z-autoconf-2.69.tar.xz` output?
<clever>
elvishjerricco: nice
<clever>
yeah
<clever>
19.03 is the name of nixos-unstable, which will eventually become 19.03 next march
<clever>
git checkout ca2ba44cab4
<clever>
pareidolia: you may also want to `git checkout` the rev shown by `nixos-version`
<clever>
pareidolia: nix-env -iA nixos.git ?
<clever>
pareidolia: `nixos-rebuild -I nixpkgs=/path/to/nixpkgs test` i believe
<clever>
pareidolia: edit it in a `git clone` of nixpkgs
<clever>
elvishjerricco: but grub itself wont be encrypted, and is still a weak point
<clever>
elvishjerricco: another factor of secureboot, is that the kernel should probably confirm signatures on all loadable modules
<clever>
typetetris: edit the config on /boot
<clever>
elvishjerricco: ah, that might be it, i was expecting it to just load it as a file, and then pass control over without using the efi specs
<clever>
typetetris: ah, that implies systemd-boot does support secureboot
<clever>
typetetris: step 4 sounds like the chicken in the egg problem i mentioned
<clever>
so systemd-boot is probably running unsigned code
<clever>
a quick google implies that systemd-boot also doesnt support secureboot by itelf
<clever>
which means grub is not verifying the next stage (linux) and is running unsigned code
<clever>
in my case, i was able to whitelist only grub, and then it booted
<clever>
yeah, my laptop gives me that
<clever>
and custom has zero options
<clever>
secureboot is either microsoft, or custom
<clever>
my desktop doesnt even give me the option to whitelist a file
<clever>
typetetris: many bios also horribly mislabel things in the options
<clever>
typetetris: wasnt aware that actually worked
<clever>
typetetris: oh, your in nixos, with secureboot and systemd-boot?
<clever>
pareidolia: usually /tmp
<clever>
and /boot needs to be a fat32 partition, flagged as the efi system partition, in the gpt tables
<clever>
boot.loader.grub.efiInstallAsRemovable = true; gets around it, by claiming your on a removable disk
<clever>
chicken in the egg problem
<clever>
you need to boot with efi to config the efivars, to be able to boot with efi
<clever>
and if they revoked those keys, every single install disk would become invalid
<clever>
so the M$ keys are basically useless now
<clever>
typetetris: oh, the bootloader M$ signed with those keys, they forgot to disable a debug option that leads to executing unsigned code
<clever>
you can still use uefi without secureboot
<clever>
apple too
<clever>
typetetris: yeah, M$ gets away with it being easy, because the kernels are compiled and signed in a secure place, and the end-user never has the keys
<clever>
and ensure systemd-boot validates the kernel before booting it
<clever>
typetetris: if using public/private keys, then you just need to add the public to the bios once, and then sign everything with the private
<clever>
uefi also suffers from that, if secureboot is off
<clever>
typetetris: and then its basically imposible to detect what its doing
<clever>
typetetris: when booting in legacy, a virus can in theory replace your bootloader, and then boot your OS inside a VM
<clever>
Acou_Bass: when downloading a .nar and unpacking it, the entire nar was held in a std::string
<clever>
it barely had room for 2 nixos generations
<clever>
ive ran nixos on a machine with 4gig of SSD, and thats it
<clever>
cant shrink zfs*
<clever>
and you cant resize a zfs device either, so you need a new disk
<clever>
you need a real partition if you have zfs
<clever>
elvishjerricco: did you hear about the supermicro stuff going around?
<clever>
lingeeal: the attrpath is probably yesod.bin
<clever>
elvishjerricco: then they can give grub the pw they just set
<clever>
elvishjerricco: oh, but what if an attacker just wipes /boot and makes their own custom /boot with luks, and they know the pw?
<clever>
elvishjerricco: yeah, that could work, as long as you ensure the verified grub.efi loads from the luks device
<clever>
elvishjerricco: efi requires a plaintext fat32
<clever>
elvishjerricco: and how do you verify that your grub.cfg hasnt been tampered with?
<clever>
elvishjerricco: you could, but then its not really secureboot anymore, and something custom
<clever>
elvishjerricco: it looks like grub doesnt support secureboot, and needs a shim to help out
<clever>
elvishjerricco: secureboot has to be enabled within grub, to verify the hashes of the next binary with the uefi firmware
<clever>
magnetophon: just dont run ldconfig
<clever>
so you can just hit E at the grub screen, and boot a malicious linux, or edit grub.cfg
<clever>
but the major problem right now with secureboot in my laptop, is that grub doesnt verify the next stage (linux)
<clever>
magnetophon: ldconfig doesnt work on nixos
<clever>
the desktop only has an on/off switch, and i cant even load custom public keys
<clever>
as for secureboot and nixos, my laptop allows me to whitelist a binary by its hash
<clever>
and then your in a vm and dont even know it
<clever>
secureboot is more to protect against malware that replaces your bootloader with a hypervisor
<clever>
depends on the motherboard
<clever>
you may need to desolder the chip that the config is stored on
<clever>
elvishjerricco: if you can wipe the bios config by force, yes
<clever>
but, if you had used TPM and measured boot, i would need to crack the TPM itself, which is designed to be resistant to such things
<clever>
and i can modify that
<clever>
there must be a plaintext binary somewhere on the hdd, to decrypt /boot
<clever>
and next time you login, your screwed
<clever>
but also, if i have physical access, i could do a bios reset to disable secureboot, and then mess with your /boot to save the luks password to the disk in plaintext
<clever>
elvishjerricco: yeah, you need to go into some kind of special configure mode, and then play a sequence of hashes to it, by actually booting
<clever>
but then anybody can just shove in a bootable usb, and use it
<clever>
i think the tpm can also work without measured boot
<clever>
yeah, they can both be used seperately
<clever>
(which includes a maliciously modified bootloader/kernel)
<clever>
secure boot is different, in that the bios will refuse to even run an unauthorized os
<clever>
sphalerite: so if somebody boots an unauthorized os, the tpm just doenst unlock
<clever>
and if you replay the same sequence of hashes, the TPM unlocks, and you can use it to do things like decrypt the hdd
<clever>
measured boot is reporting the hash of the next binary to the TPM, before you execute it
<clever>
the official iso has MBR tables and works on a usb stick
<clever>
gleber_: probably
<clever>
glasserc: if you have the .drv for each generation (nix-store --query --deriver) you can use nix-diff to see how the compile directions differed
<clever>
that should allow you to change profiles while it is playing audio
<clever>
and then you regain the built-in audio, and it switches back
<clever>
then when you change profiles, it will loose the built-in audio sink, switch to the null
<clever>
`pactl load-module module-null-sink` to temporarily load one