<clever>
you would need to import the file directly, and not use an overlay
<clever>
yeah
<clever>
then either import its file directly, or add them to pkgs?
<clever>
your probably better off just editing nixpkgs directly, and maybe filing a PR
<clever>
ldlework: ive tried pointing <nixpkgs> to a default.nix before, and it causes weird problems, because of the fact that you can <nixpkgs/lib/options.nix>
<clever>
*looks up*
<clever>
my laptop has 512mb, and ran out due to rescue_boot, lol
<clever>
it also recently got full, and i had to disable my rescue_boot
<clever>
most of it is kernels and initrds
<clever>
66M /boot/kernels
<clever>
9.6M /boot/grub
<clever>
sophiag: my /boot on the laptop is using 79mb right now
<clever>
yeah, thats why you need the boot.loader.efi.efiSysMountPoint = "/boot/EFI"; option in nixos
<clever>
ah
<clever>
emily: the kernel would be in /boot or /nix/store, not /boot/efi
<clever>
sophiag: i think you could get away with 1mb, lol
<clever>
-rwxr-xr-x 1 root root 119K Oct 29 2017 /boot/EFI/BOOT/BOOTX64.EFI
<clever>
[root@system76:~]# ls -ltrh /boot/EFI/BOOT/BOOTX64.EFI
<clever>
if your using ext4 for /, then you can put the ESP at /boot/efi and just omit the /boot partition entirely
<clever>
uefi shouldnt have issues like that
<clever>
sophiag: that problem is also part of why you may find /boot on older legacy machines, the bios cant read the entire root fs
<clever>
sophiag: thats more about the start of the boot partition on the disk, and its only an issue for legacy booting
<clever>
then you are free to make /boot ext4, or even use the /boot directory of /
<clever>
but, you can also mount the vfat to /boot/efi, and set boot.loader.efi.efiSysMountPoint = "/boot/efi";
<clever>
when doing efi on nixos, the default is a vfat mounted to /boot and /boot/efi is just a normal directory
<clever>
sophiag: yeah
<clever>
in my case, there is traces of the original OS left behind
<clever>
Boot0004* UEFI OS HD(1,GPT,27c99b08-455d-4dfe-a44f-6150cbc09ef8,0x800,0x100000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
<clever>
the above efibootmgr command will print the current efi vars
<clever>
so if you boot a USB stick in legacy mode, it cant setup the efi vars
<clever>
sophiag: canTouchEfiVariables only works if you have booted via uefi
<clever>
[root@system76:~]# nix run nixpkgs.efibootmgr -c efibootmgr -v
<clever>
ah
<clever>
then you are booting via uefi
<clever>
sophiag: if you run `mount`, do you see this being mounted?
<clever>
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
<clever>
v0latil3_: yeah, but then you need to deal with managing secrets in /nix/store/
<clever>
i also didnt bother setting a bios password, so you can just turn secure-boot back off
<clever>
just a hash of the grub binary
<clever>
but grub will happily run anything you point it at :P
<clever>
so my laptop can only ever run the grub.efi file nixos installed, and nothing else
<clever>
v0latil3_: however, the grub binary itself, doesnt have any security enabled, and will happily run unsigned things, so it doesnt really protect you much
<clever>
which just adds the hash of the binary to the whitelist
<clever>
v0latil3_: i recently experiemnted with my laptop bios, and you can "enroll" any unsigned efi binary
<clever>
sophiag: one of my haskell programs leaks memory at a fairly low rate, but after a few weeks or uptime, it has leaked 64gig or more :P
<clever>
Henson: /tmp + "/foo"
<clever>
v0latil3_: my desktop has 32gig of ram and 32gig of swap, and i soemtimes have to enable an extra 64gig swap parittion
<clever>
sophiag: i tend to make my boot partitions either 512mb or 1gig
<clever>
sophiag: how big is it?
<clever>
ldlework: overlays
<clever>
"it boots windows, ship it"
<clever>
sophiag: but some bios are so stupid, they even ignore the vars, and boot the filename windows puts the bootloader at :P
<clever>
sophiag: with some bios firmware, you can manually edit those vars in the UI, which can help
<clever>
booting from a uefi USB stick is one way to bootstrap that whole mess
<clever>
sophiag: and if you move the hdd to another box, it wont boot, because the vars are missing
<clever>
sophiag: so, you must boot via uefi, to configure it to boot via uefi, have fun! :P
<clever>
sophiag: and you can only set those vars if you boot via uefi
<clever>
sophiag: about the only thing i can think of, is that booting uefi generally requires some special vars being set in the firmware
<clever>
sophiag: uefi booting required an efi system partition, with vfat, mounted to /boot (or maybe /boot/efi with the right config)
2018-09-06
<clever>
which is just obeying the --prefix passed to configure
<clever>
Henson: its usually generated by the makefiles of the project
<clever>
and repeat for each path that fails to download
<clever>
rsa: you will need to download that file manually, and then run `nix-prefetch-url file:///path/to/patch` to import it
<clever>
rsa: why does it not have internet?
<clever>
rsa: you could try adding `--option substituters ''` to disable it contacting anything
<clever>
and if you updated the nixpkgs, they cant be reloaded, because the kernel versions would conflict
<clever>
kernel modules arent reloaded when you rebuild-switch
<clever>
yeah
<clever>
then it will natively have unstable on every boot
<clever>
tobiasBora: though for the netboot image i gave you, you can also set boot.zfs.enableUnstable = true directly in the nix expression that builds the initrd files
<clever>
normally, you would just reboot to apply that updat,e but the livecd resets to defaults then
<clever>
tobiasBora: rmmod all zfs and spl ones, then reload them with modprobe
<clever>
tobiasBora: you need to reload the kernel modules
<clever>
das_j: in my case, hydra is pre-building the whole thing against the latest nixos-unstable, so i can see if the new version breaks things before i try to update
<clever>
ixxie: but you can use `nixops modify -I nixpkgs=/path/to/something` to override that
<clever>
on my laptop, that does a left drag
<clever>
ixxie: also, try a quick tap, followed by a press and hold
<clever>
also, try moving with 2 fingers
<clever>
ixxie: now try with 3 fingers
<clever>
ixxie: what happens if you tap with 2 fingers at once?
<clever>
but you will loose the ability to see its output
<clever>
yorick: the ssh dying will almost never kill the program within, linux retries the tcp send a lot, and can buffer a few mb of output
<clever>
in my case, i'm using the toxvpn IP for some machines, so the IP is static, even if it changes to another interface
<clever>
ixxie: the activate may finish on its own, but you will never see its output
<clever>
ixxie: the wifi is more likely to change the IP, which then breaks all current ssh sessions
<clever>
this can happen any time the nixpkgs rev changes
<clever>
ixxie: see if ssh works now, and try re-running deploy
<clever>
gchristensen: its also too late for the 18.09 branch, but we may want to cherry-pick it over, since the client refuses to connect to the older server
<clever>
Shell: start by comparing the git revs at the end of the names
<clever>
tobiasBora: id need more time to study that before i can see what its doing
<clever>
Shell: and what does `nix-channel --list` report?
<clever>
Shell: and then run fsck to see if there is anything wrong with your disk
<clever>
Shell: are you able to boot an older generate by selecting one at grub?
<clever>
tobiasBora: and its less likely that you will break that 2nd nixos, so you can use it as a rescue system
<clever>
tobiasBora: rescue_boot.nix is just putting the "netboot" files into /boot and adding a grub option, so you basically have a 2nd copy of nixos in /boot
<clever>
and if you get it wrong, the machine will either forget how to boot, or systemd will drop you into rescue mode immediately, and wait for local input
<clever>
you need to manually copy it to the nixops machine, and include it in the deployment files
<clever>
ixxie: for which backend?
<clever>
probably not, but it would likely need to me heavily modified to work with the stage-1 in nixos
<clever>
yeah
<clever>
it may also take longer to boot, since it has to copy the entire thing to ram
<clever>
tobiasBora: so it will need more ram to boot, but once booted, you can just unplug the usb stick your booting from
<clever>
tobiasBora: the major difference between an ISO and netboot, is that the netboot copies the entire (compressed) rootfs into ram
<clever>
<nixpkgs/nixos/modules/installer/cd-dvd/installation-cd-graphical-kde.nix> i think
<clever>
tobiasBora: yeah, just add another thing to the imports field
<clever>
tobiasBora: and it has many of the defaults an installer has, like auto-login for root
<clever>
tobiasBora: the netboot stuff is a variant of the ISO, that puts the rootfs into the initrd
<clever>
tobiasBora: you can even test the above from the live usb
<clever>
tobiasBora: try running nix-build against that file now
<clever>
pushed again
<clever>
wait, that made it worse, lol
<clever>
fix pushed
<clever>
oh, but the filenames are off a tad
<clever>
tobiasBora: run `nix-build multi-boot-helper.nix` and you will get a result symlink containing a kernel, initrd, and grub config file
<clever>
tobiasBora: nixos doesnt use root=, but embeds that into the initrd
<clever>
ixxie: so you can just > ~/.ssh/authorized_keys to allow yourself on a new machine
<clever>
ixxie: something that is very handy, `curl https://github.com/cleverca22.keys` will output every ssh key you authorized to your github
<clever>
tobiasBora: so it will expect a kernels directory on the EFI partition
<clever>
tobiasBora: line 3 sets $drive1 to whatever FS C863-2483 matches
<clever>
tobiasBora: can you pastebin the entire grub.cfg file?
<clever>
wdanilo: nix just cant have that problem (when using source everywhere), because a change of the .h file would trigger a rebuild of anything using it
<clever>
wdanilo: for example, if the size of a field in a .h file changes, then the ABI for calling functions in that library will be different, and things break in fun ways if you mix the versions up
<clever>
wdanilo: the reason nix rebuilds things is for purity, there may be unknown changes in the .so, that impact things at compile or link time, and just changing the search path can break things
<clever>
wdanilo: or for darwin, otool
<clever>
wdanilo: you can use the patchelf program to do those changes
<clever>
21686148-6449-6E6F-744E-656564454649 is just the hex for "Hah!IdontNeedEFI"
<clever>
ixxie: the bios boot partition one is more fun :P
<clever>
the real type code is C12A7328-F81F-11D2-BA4B-00A0C93EC93B
<clever>
also, those numbers are just for the menu in fdisk
<clever>
its the very first type in the list :P
<clever>
1 EFI System C12A7328-F81F-11D2-BA4B-00A0C93EC93B
<clever>
wdanilo: and the exact search path is specific to the versions your using as inputs
<clever>
wdanilo: yeah, its mainly the rpath field, which has a list of dirs to search for the libs
<clever>
ixxie: shift+pageup works in the bare text console
<clever>
wdanilo: due to the lack of a /usr/lib directory, nix needs the path to put the paths like /nix/store/hash-name/lib into the ELF headers
<clever>
ixxie: did you check the list of type codes, near the start?
<clever>
tobiasBora: yeah, it should be possible to patch plasma, its just that nobody has bothered yet
<clever>
adamantium: vim
<clever>
though the error isnt clear, and claims the fs is wrong
<clever>
and the error even mentions ESP
<clever>
ixxie: sda2 must be set to the EFI system partition type
<clever>
ixxie: why is sda2 set as a bios boot partition? thats only for legacy
<clever>
tobiasBora: the problem is that plasma doesnt expect things to be under a symlinked directory, and is watching for changes on the wrong thing
<clever>
ixxie: and also `fdisk -l /dev/sda`
<clever>
tobiasBora: you usually need to logout and back in for plasma to detect that, it may also need to be in systemPackages
<clever>
wdanilo: yeah
<clever>
ixxie: can you pastebin the output of `mount ; df -h` ?
<clever>
wdanilo: /proc/self is a linux thing, so something must be broken with the --store based chrooting on darwin
<clever>
adamantium: but, if you slowly increase the allocations, the zfs ARC shrinks in response, and it works fine
<clever>
adamantium: one thing ive noticed, is that qemu tries to allocate several gig at once, and can hard-fail because my laptop lacks enough swap
<clever>
ixxie: and did you mount it to /mnt/boot/ ?
<clever>
ixxie: that was the exact error it gave?
<clever>
yeah
<clever>
tobiasBora: i would go with just plain ext4
<clever>
tobiasBora: yeah, that sounds right
<clever>
srhb: ah, ive not done any special setting, just zfs create, mkswap, and swapon
<clever>
srhb: yikes
<clever>
my current machine has 32gig of ram, and 32gig of swap, over 4 swap partitions
<clever>
ixxie: and if you decide you dont want swap, comment it out, rebuild-switch, then delete the file, and you get your space back
<clever>
ixxie: the above will automatically create a 16gig swap file and activate it