2018-02-17
21:02
<
clever >
i should just plug the thing back in and record it for historical purposes, lol
21:00
<
clever >
that should help with the googles
21:00
<
clever >
in my case, it was an asus p4b motherboard
21:00
<
clever >
and the win98 cd has an idiot mode, that chainloads the hdd, because you cant remove a silly cd
21:00
<
clever >
but it can still boot from cdrom
20:59
<
clever >
and the bios forgets how to boot from ide :P
20:59
<
clever >
but if you speak too slowly, it takes up too much space
20:59
<
clever >
you can record your own messages in windows, and reflash the bios with the .wav files
20:59
<
clever >
that same bios, also lacks bounds checking on its reflashing utils
20:58
<
clever >
Dezgeg: one day while messing with overclocking, it said, "no cpu found"
20:58
<
clever >
Dezgeg: on bootup, it says things, in english, via the sound card, giving you progress updates
20:58
<
clever >
Dezgeg: this reminds me, one of my older motherboards, it must have a micro-controller on it somewhere
20:57
<
clever >
Dezgeg: ah yeah, the initial random state would have crc failures everywhere
20:55
<
clever >
sphalerite_: yeah, that just makes no sense at all
20:54
<
clever >
but yeah, you still have to deal with the original POST
20:54
<
clever >
sphalerite_: another benefit, is that you cant really brick the machine, since the original bios can just be told to not netboot anymore, then reflash the nic again
20:53
<
clever >
sphalerite_: then coreboot finishes the job
20:52
<
clever >
sphalerite_: then you tell the existing bios to network boot, and it hands control over to that boot rom
20:52
<
clever >
sphalerite_: i had an idea yesterday, could a coreboot image that doesnt deal with dram/pci initialzation, be jammed into the boot rom of a network card
20:50
<
clever >
in a way that obeys the efi specs and grants all efi programs usage of those FS's?
20:50
<
clever >
how complex would it be to write an EFI driver for ext4 or ZFS, stick it on the fat32, and chain-load a 2nd bootloader?
20:50
<
clever >
i wonder...
20:47
<
clever >
ottidmes: its mostly about chance, was something writing at that moment
20:47
<
clever >
fsync between the 2?
20:46
<
clever >
Dezgeg: but the file still wound up 0 bytes in size
20:46
<
clever >
Dezgeg: it is, it writes to a .tmp, then uses rename to move it
20:46
<
clever >
ambro718: zfs just rolls back the entire change, leading to the old version
20:45
<
clever >
ambro718: improper shutdowns can truncate files
20:45
<
clever >
ambro718: ext4 puts more focus on the metadata, over the data
20:44
<
clever >
ambro718: just delete it and see if that fixes things
20:44
<
clever >
ambro718: it must have been corrupted
20:44
<
clever >
ambro718: that file is how nix remembers the semi-random uid mappings, so when you delete a user, then re-add it, it gets the old uid again
20:43
<
clever >
ambro718: we have been looking at the wrong json the entire time, lol
20:43
<
clever >
10 my $uidMapFile = "/var/lib/nixos/uid-map";
20:43
<
clever >
11 my $uidMap = -e $uidMapFile ? decode_json(read_file($uidMapFile)) : {};
20:43
<
clever >
ambro718: your error says line 11, look at line 11 of the perl script
20:43
<
clever >
ambro718: oh
20:41
<
clever >
gentoo mode :D
20:41
<
clever >
but deepfire was running without any cache
20:41
<
clever >
if the binary cache is enabled, it can just grab .doc from there
20:41
<
clever >
and now system() fails
20:41
<
clever >
leaving you with a /bin/sh that cant find its own libc
20:41
<
clever >
but if you are rebuilding the .doc for other reasons, the .lib is silently dropped
20:41
<
clever >
so a glibc impurity is always added to the sandbox
20:40
<
clever >
the problem, is that the /bin/sh in the sandbox, depends on the .lib for glibc
20:40
<
clever >
so nix doesnt have to rebuild them later
20:40
<
clever >
which prevents them from being GC'd
20:40
<
clever >
srk: but nix doesnt know that, and blindly keeps those outputs around
20:39
<
clever >
srk: absolutely nothing
20:38
<
clever >
srk: ah, that old error :D
20:37
<
clever >
search for user-group
20:37
<
clever >
ambro718: look inside /nix/store/pfbjhdbf33fx36j939hwx1gxlzlv27px-nixos-system-nixos-router-17.09.git.f7ae5ae/activate
20:37
<
clever >
ambro718: one min
20:36
<
clever >
ambro718: that will both give you a working perl, and also give you the exact perl that is having the issue
20:36
<
clever >
ambro718: read the perl script from the error, and also reuse the perl in its #!
20:35
<
clever >
ambro718: maybe?
20:34
<
clever >
codygman: temporarily switching to the nixos-17.09-small channel should fix your problem
20:33
<
clever >
codygman: and howoldis says that the channel changed 1 hour ago, to a commit from 18 days ago
20:33
<
clever >
codygman: and your on a commit from 18 days ago, aha
20:32
<
clever >
codygman: the tip of the 17.09 branch is from 4 days ago
20:32
<
clever >
codygman: the fix is from 9 days ago, and is on the 17.09 branch of -channels...
20:31
<
clever >
codygman: i think the problem is the the http mirror
20:29
<
clever >
codygman: what does sudo nix-channel --update say now?
20:29
<
clever >
codygman: c1d9aff56e0 is what your on already, and thats too old
20:29
<
clever >
ottidmes: you could try programs.info.enable = false;
20:28
<
clever >
and it just doesnt turn it into an image, lol
20:28
<
clever >
srk: the VGA card in the guest has a block of ram that is filled with raw text, and the GPU is responsible for turning that into an image
20:28
<
clever >
srk: curses is a weird one, because it doesnt use the serial port of the guest
20:27
<
clever >
codygman: this is the revision you have
20:26
<
clever >
srk: the flags appear to be -nographic for serial, and -curses for curses
20:25
<
clever >
then find the pkgs/applications/networking/browsers/mozilla-plugins/flashplayer/default.nix file
20:25
<
clever >
codygman: if you keep digging, youll find the entire nixpkgs tree
20:24
<
clever >
codygman: next, check what your own files say, in ~/.nix-defexpr
20:23
<
clever >
codygman: yeah, that looks the same, it should be working
20:22
<
clever >
codygman: this is what the channel follows
20:22
<
clever >
codygman: oh, and the repo you linked doesnt follow the channel, one min
20:21
<
clever >
codygman: which channel are you on?
20:20
<
clever >
srk: the 2nd, will scrape the console text buffer, then use ncurses to reproduce it over stdin/out
20:20
<
clever >
srk: qemu also has 2 modes that work for that, the 1st just routes the serial port to stdin/stdout, so qemu becomes a console program
20:18
<
clever >
but qemu just ignores the NIC entirely, and you can screenshot
20:18
<
clever >
srk: and you have to reboot real hardware, that lacks copy/paste while debugging
20:17
<
clever >
srk: this also adds the justdoit script to the installer, so you type justdoit, and its done
20:17
<
clever >
so you can verify the installation works
20:17
<
clever >
srk: qemu_test2 then boots the same disk drive, without the kernel+initrd
20:17
<
clever >
srk: qemu_test1 will build the netboot image from <nixpkgs> and boot its kernel+initrd inside qemu with a dummy disk drive
20:16
<
clever >
codygman: first step would be to find the new URL to download flash from
20:16
<
clever >
srk: also, i have some scripts that help a lot with testing the netboot
20:15
<
clever >
codygman: the problem is that adobe deleted the file on us again, it wont be fixed until nixpkgs is modified by a maintainer
20:13
<
clever >
phdoerfler: 3 packages provide a sendmail binary, youll need to pick the one you like the most
20:13
<
clever >
exim.out 0 s /nix/store/9a3gxna4qgwkfkg1cg633glrgy4nh201-exim-4.89/bin/sendmail
20:13
<
clever >
postfix.out 310,456 x /nix/store/pkix4gxx84py3197miaw9iw150nvjfz3-postfix-3.1.3/bin/sendmail
20:13
<
clever >
ssmtp.out 0 s /nix/store/r5sidvlw2jmajbdzwbkgaqyq1cmc7vjf-ssmtp-2.64/bin/sendmail
20:13
<
clever >
[clever@amd-nixos:~]$ nix-locate bin/sendmail
20:12
<
clever >
srk: that should work without the fstab manipulation
20:12
<
clever >
phdoerfler: that package doesnt exist
20:12
<
clever >
error: attribute ‘sendmail’ missing, at (string):1:1
20:12
<
clever >
nix-repl> pkgs.sendmail
20:09
<
clever >
dgpratt: gitFull includes tools like `git gui`, which depend on the X libs, causing it to take more disk space up
20:04
<
clever >
ambro718: ssh into the router, and run nix-store --verify --check-contents
20:04
<
clever >
next thing to check would be the store integrety
20:03
<
clever >
856 is in the middle of this string, from the list of groups
20:03
<
clever >
"nixbld27"
20:03
<
clever >
ambro718: does it still fail at offset 856?
20:01
<
clever >
either should work, since the hash is identical
20:01
<
clever >
ambro718: ok, can you run nix-shell -p gist, then `gist -p /nix/store/6fgl4qj260hi1h7ly2kh09nxgn7s5r9x-users-groups.json`
19:59
<
clever >
ambro718: and does that new json file now exist on the router?
19:58
<
clever >
ambro718: ok, now try the deploy again
19:58
<
clever >
ambro718: ah, it was -C
19:56
<
clever >
nix-shell -p jq then cat /nix/store/6fgl4qj260hi1h7ly2kh09nxgn7s5r9x-users-groups.json | jq --color
19:54
<
clever >
ambro718: what about nixops deploy --build-only, what does it output?
19:53
<
clever >
ambro718: ssh into the remote machine and check the same json file
09:19
<
clever >
hyper_ch: online?, no reboot?
08:17
<
clever >
and the 32bit variant of glibc likely includes it
08:17
<
clever >
genesis: it only gets included if your not doing a 64bit build
08:17
<
clever >
7 # include <gnu/stubs-32.h>
08:17
<
clever >
6 #if !defined
__x86_64__
08:12
<
clever >
hyper_ch: find supports -delete, stop wasting forks :P
08:08
<
clever >
lol, more just lazyness
08:07
<
clever >
i never throw shit out :P
08:07
<
clever >
no, spinning rust pata drive
08:06
<
clever >
i still have a 40mb and 80mb hdd
08:05
<
clever >
hyper_ch: i remember when a 300mb hdd was bit :P
08:04
<
clever >
hyper_ch: by not having 100's of gigs of data
03:58
<
clever >
DavidEGrayson: that also works
03:02
<
clever >
$NIX_REMOTE i mean
03:02
<
clever >
DavidEGrayson: ah, and openStore() can be ran with no args, it probably relies on $NIX_DAEMON, like all the tools
03:02
<
clever >
initNix(); initGC(); are involved in initializing the library
03:00
<
clever >
this function is involved in opening a connection to nix-daemon
02:59
<
clever >
DavidEGrayson: this function tells you if a path is valid
02:59
<
clever >
if (store->isValidPath(expectedStorePath))
02:59
<
clever >
DavidEGrayson: one min
02:59
<
clever >
DavidEGrayson: it would be better to use the nix bindings
02:19
<
clever >
DavidEGrayson: unfinished builds should come up as invalid
02:18
<
clever >
DavidEGrayson: i think you can run `nix-store --query --size` on the output
02:18
<
clever >
DavidEGrayson: hmmm, one min
02:07
<
clever >
joepie91: ah, that will do it
02:06
<
clever >
joepie91: was /mnt/boot mounted before you ran nixos-generate-config?
01:44
<
clever >
efi or legacy?
01:43
<
clever >
gpt or mbr?
01:43
<
clever >
it defaults to 50% of the ram
01:43
<
clever >
joepie91: you can still resize it, to allow it to consume more ram
01:42
<
clever >
joepie91: enabling swap can help, and you can resize the fs that has failed with mount /nix/.rw-store -o remount,size=3G
01:41
<
clever >
joepie91: its a bug in the current nixos-install
2018-02-16
23:40
<
clever >
LnL: we could make a nix-support file that says dont do this, and have nix-env test for it
23:39
<
clever >
and like gcc, pkgconfig doesnt work if nix-env'd
23:38
<
clever >
zfs.out 0 s /nix/store/qfcw3a2v5pp9i459jcmr0i9d6hyw2kx8-zfs-user-0.6.5.9/lib/libzfs.so
23:38
<
clever >
[nix-shell:~/.daedalus]$ nix-locate libzfs
23:37
<
clever >
if you need a shell.nix, with import <nixpkgs> {}; stdenv.mkDerivation { name = "name"; buildInputs = [ cargo libzfs ]; }
23:37
<
clever >
if you need a shell.nix, with import <nixpkgs> {}; stdenv.mkDerivation { name = "name"; buildInputs = [ cargo ]; }
23:37
<
clever >
which gives you a shell with gcc and cargo
23:37
<
clever >
infinisil: you can also just nix-shell -p cargo
23:33
<
clever >
;; nix-shell for Emacs.
23:33
<
clever >
Think of it as
23:30
<
clever >
and if emacs needs it, then you must run emacs inside the nix-shell
23:30
<
clever >
so you must run gcc inside nix-shell to make it work
23:29
<
clever >
and if you nix-env it, that doesnt happen
23:29
<
clever >
there are setup-hooks that nix-shell/nix-build run, which iterate over everything in $buildInputs, and add them to the -I path for gcc
23:28
<
clever >
infinisil: gcc breaks if you nix-env it
23:28
<
clever >
infinisil: use nix-shell
23:27
<
clever >
assertion should be safe
23:26
<
clever >
could be something else then
23:25
<
clever >
Lisanna: ive found that it does that if i ctrl+c an evaluation
23:24
<
clever >
and you could put any binary you want into the stage-1 script, possibly even Xorg, and it will happly jam the entire closure in, lol
23:23
<
clever >
and the initrd generator will then include the entire closure of those 4 files, at /nix/store/ inside the initrd
23:23
<
clever >
along with an mdadm.conf, and some modprobe configs
23:23
<
clever >
it configures the generator to create a /init symlink, pointing to the storepath of the stage-1 script
23:22
<
clever >
symphorien: here is the nix expression that generates the initrd
23:21
<
clever >
(also, nixos doesnt have a /bin/sh in the ramdisk)
23:20
<
clever >
but, there is also a rdinit=/bin/sh, which sets the ramdisk init
23:20
<
clever >
the stage-1.sh inside the initrd then chooses to obey it, and runs /bin/sh as pid 1, after mounting the rootfs to /
23:20
<
clever >
if you set init=/bin/sh, but are using an initrd, the kernel basically ignores it
23:18
<
clever >
booting via grub like i mentioned, would mount things for you
23:17
<
clever >
and that should drop you into a root shell with no systemd, then you can probably run /run/current-system/sw/bin/passwd to change the root pw
23:17
<
clever >
jmorriss[m]: you can also just hit E at grub, edit the init= to init=/bin/sh, then hit F10 to boot with those changes
22:50
<
clever >
Guest14344: you can also -I nixos-config=./configuration.nix
22:30
<
clever >
technically, nix-env does obey NIX_PATH, but it never tries to use it by default
22:29
<
clever >
or more, repeat the last one on every real channel!
22:29
<
clever >
and you can even do all 3, just add 3 channels to the test dir
22:29
<
clever >
or import (builtins.fetchurl foo) to grab things
22:28
<
clever >
you can also just import <nixpkgs> to obey $NIX_PATH
22:28
<
clever >
so nix-env -iA foo.cargo grabs it from the nixpkgs in ~/apps/nixpkgs
22:28
<
clever >
foo is the name of the channel
22:28
<
clever >
test is an invisible category, it just gives me a dir i can play in, where nix wont mess with things
22:27
<
clever >
import /home/clever/apps/nixpkgs
22:27
<
clever >
[clever@amd-nixos:~]$ cat .nix-defexpr/test/foo/default.nix
22:27
<
clever >
also, you can trivially add custom things
22:27
<
clever >
and yes, its weird, nix-env is the only tool in the entire toolbox to use defexpr
22:27
<
clever >
this one will obey nix_path
22:27
<
clever >
nix-env -f '<nixpkgs>' -iA cargo
22:26
<
clever >
infinisil: that looks in ~/.nix-defexpr/ for the nixos entry
22:26
<
clever >
infinisil: that command totally ignores $NIX_PATH
22:25
<
clever >
infinisil: what nix-env command did you run?
20:58
<
clever >
prooftechnique: you can then use that symlink in the config file and whatever else you want
20:58
<
clever >
prooftechnique: nix-build '<nixpkgs>' -A hello -o ~/hello will create a symlink at ~/hello that points to the resulting build
20:52
<
clever >
Guest14344: you can use config.nix or overlays to add new packages
20:40
<
clever >
Lisanna: neat
20:38
<
clever >
Lisanna: nix doesnt know which characters refer to a given derivation
20:36
<
clever >
nhill: i prefer using tab completion with nix-repl '<nixpkgs>'
20:36
<
clever >
sphalerite_: your dots randomly shrink? lol
20:35
<
clever >
sphalerite_: have you been touching lua? lol
20:35
<
clever >
and if you want a random package from hackage, nix-shell -p 'haskellPackages.ghcWithPackages (ps: with ps; [ shake ])' --run ghci
20:35
<
clever >
fragamus: nix-shell -p 'haskellPackages.ghcWithPackages (ps: with ps; [])' --run ghci
20:10
<
clever >
fragamus: you must use stack --nix mode
20:10
<
clever >
fragamus: /bin/bash doesnt exist on nixos
19:51
<
clever >
lejonet: yes
19:11
<
clever >
Aleksejs: ^^
19:03
<
clever >
sphalerite_: i modeled toxvpn on the feature-set that hamachi provided
19:03
<
clever >
sphalerite_: yep, that was it
19:02
<
clever >
lejonet: or put the private key into the nix store!
19:02
<
clever >
lejonet: i have to use socat to proxy it over
19:02
<
clever >
lejonet: that also makes it imposible to share the agent with the nixbld users on a case by case basis
19:00
<
clever >
lejonet: if you chmod the socket, and try to use the agent from the wrong user, it just flat out refuses to work
19:00
<
clever >
lejonet: ssh-agent does some neat things with those powers
18:59
<
clever >
lejonet: unix sockets can also query the pid and uid of the remote peer
18:59
<
clever >
lejonet: which allows users to audit the part needing root
18:59
<
clever >
lejonet: then a closed-source blob that doesnt directly need root, and does the VPN magic
18:58
<
clever >
lejonet: the VPN in question, had an open-source daemon, that shares /dev/tun handles via the unix socket, and manages configuring the IP on the interface
18:58
<
clever >
lejonet: its possible to pass an open file handle via a unix socket
18:57
<
clever >
lejonet: something else ive seen used by a vpn program ages ago, was a way to get a /dev/tun handle, without ever aquaring root directly
18:56
<
clever >
lejonet: and modprobe obeys env vars for the config, causing it to execute stuff the user supplied
18:56
<
clever >
lejonet: for example, fusermount is setuid root, and a few months ago, it was discovered that it will automatically `modprobe fuse` for you
18:55
<
clever >
lejonet: simiarly with setuid root binaries
18:55
<
clever >
lejonet: there are countless ways sudoers can be abused if your not 100% perfect
18:36
<
clever >
sphalerite_: i tend to go overboard and import <nixpkgs> { config={}; overlays=[]; }
18:35
<
clever >
sphalerite_: which may impact the fetchurl code
18:34
<
clever >
sphalerite_: now you have an impurity based on the config.nix in the current $HOME
18:30
<
clever >
gchristensen: lol
18:27
<
clever >
gchristensen: :C
18:25
<
clever >
sphalerite_: resulting in infinite recursion
18:25
<
clever >
sphalerite_: pkgs depends on config._module.args.pkgs, which depends on the entire imports tree
18:25
<
clever >
sphalerite_: i dont think imports can refer to pkgs
18:06
<
clever >
hyper_ch: in the old days, NIC cards came with a dos program on a floppy that handled this task
18:04
<
clever >
nope, still nothing
18:04
<
clever >
03:00.0 Ethernet controller [0200]: Qualcomm Atheros QCA8171 Gigabit Ethernet [1969:10a1] (rev 10)
18:03
<
clever >
00:19.0 Ethernet controller [0200]: Intel Corporation 82566DM Gigabit Network Connection [8086:104a] (rev 02)
18:02
<
clever >
let me check some older machines
18:02
<
clever >
same for my laptop
18:02
<
clever >
02:00.1 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 12)
18:02
<
clever >
but none of those cards are supported
18:02
<
clever >
which are visible in the list of supported devices in flashrom
18:01
<
clever >
[nix-shell:~]$ flashrom -L | grep -i 10ec
18:01
<
clever >
that shows the vendor and product id at the end
18:00
<
clever >
hyper_ch: use lspci -nn
17:59
<
clever >
03:00.0 Ethernet controller [0200]: Intel Corporation 82583V Gigabit Network Connection [8086:150c]
17:57
<
clever >
and because the original bios does all the hard work of booting, it will be more portable
17:57
<
clever >
configure the second bios to efi with a zfs based EFI boot partition :P
17:56
<
clever >
configure the original bios to network boot
17:56
<
clever >
hyper_ch: then flash that into the NIC
17:56
<
clever >
hyper_ch: and in theory, i could make a coreboot image, that assumes the pci/dram has been pre-configured, but has its own EFI implementation
17:56
<
clever >
hyper_ch: many network cards have a flash chip where you can store a network boot rom
17:55
<
clever >
hyper_ch: i just had an idea, what about jamming a partial coreboot into the NIC's boot rom?
17:53
<
clever >
then your config, and kernel/initrd
17:53
<
clever >
with core.img and ext2.mod, grub is able to open /boot/grub, and load the rest of itself
17:52
<
clever >
which is another 6kb
17:52
<
clever >
-rw-r--r-- 1 root root 5.8K Sep 20 16:05 /boot/grub/i386-pc/ext2.mod
17:52
<
clever >
core.img is also concat'd with the driver for /boot
17:52
<
clever >
and the LBA address of core.img is written to a magic location inside the boot.img copy
17:52
<
clever >
and then copy this file to the 2nd location
17:52
<
clever >
-rw-r--r-- 1 root root 26K Sep 20 16:05 /boot/grub/i386-pc/core.img
17:51
<
clever >
grub-install will then inteligently merge this file with the partition table in sector 0
17:51
<
clever >
-rw-r--r-- 1 root root 512 Sep 20 16:05 /boot/grub/i386-pc/boot.img
17:51
<
clever >
hyper_ch: for GPT disks, thats the dedicated "bios boot partition"
17:51
<
clever >
hyper_ch: i think for legacy booting, you need ~27kb of space for the "grub core", for MBR disks, thats between sector 0 and partition 1
17:49
<
clever >
hyper_ch: and then i would just put the kernel&initrd on that
17:49
<
clever >
hyper_ch: systemd-boot is EFI based, and must live on a filesystem that the bios supports (fat32 typically)
17:45
<
clever >
hyper_ch: grub with an ext4 /boot
17:39
<
clever >
so reads may be corrupt if you improperly shutdown
17:39
<
clever >
grub also does zero journal activity, on any journaled filesystem
17:39
<
clever >
and /nix/store makes that massively slower
17:39
<
clever >
so it has to iterate thru every single file in a directory
17:39
<
clever >
grub has poor zfs support, ive heard that it doesnt support the tree based directory structure at all