2021-03-08
17:55
<
clever >
ixxie: there is also a flag when creating the sdimage, to make the fat32 larger, but that needs a reinstall
17:51
<
clever >
ixxie: mostly, but make sure it finishes copying before you reboot
17:39
<
clever >
ixxie: fdisk -l /dev/mmcblk0, mount the fat32 fs
17:39
<
clever >
ixxie: then its not mounted, mount it, and then nixos-rebuild switch
17:38
<
clever >
ixxie: mount | grep boot
17:38
<
clever >
nix-shell will build things for you, as it evals
17:37
<
clever >
so that path wont be in the nix store
17:37
<
clever >
however, that just evals, it doesnt build
17:37
<
clever >
the old api is still stable
17:37
<
clever >
"/nix/store/nm7d7i9jlqf25nwvan7ghlv3jafnbryj-hello-2.10"
17:37
<
clever >
[root@amd-nixos:~]# nix-instantiate --eval -E 'with import <nixpkgs> {}; "${hello}"'
17:37
<
clever >
qbit: the api for the new nix command is in beta and constantly changing
17:34
<
clever >
ixxie: then the bootloader isnt working right, is the fat32 fs mounted to /boot before you run nixos-rebuild?
17:31
<
clever >
ixxie: it only tries to load the firmware at boot, if you reboot, is the firmware still there?
17:28
<
clever >
ixxie: if /boot isnt mounted right, the reboot undoes everything
17:27
<
clever >
ixxie: rebuild switch, and then check again
17:26
<
clever >
ixxie: the firmware should be in here, check if the file it wants is present
17:26
<
clever >
[root@amd-nixos:~]# ls /run/current-system/firmware
17:25
<
clever >
until you --update
17:25
<
clever >
so it will be using whatever nixpkgs the iso itself was made from
17:24
<
clever >
the config says 20.09, but the iso has a copy pre-fetched, and baked into it
17:24
<
clever >
shla: because its using the copy of the channel that was packaged into the iso
17:24
<
clever >
shla: you may need to nix-channel --update before you install
17:22
<
clever >
ixxie: check dmesg again, any firmware errors like before?
17:20
<
clever >
ixxie: does `ip link` show the wifi now?
17:20
<
clever >
shla: it installs whatever the current channel is, so you can change it with nix-channel before you nixos-install
17:05
<
clever >
maybe, give it a try
17:05
<
clever >
zalaare: there is an option to do that for you
17:04
<
clever >
networking.interfaces.<name>.ipv4.routes
17:04
<
clever >
List of extra IPv4 static routes that will be assigned to the interface.
17:03
<
clever >
zalaare: that looks correct
16:45
<
clever >
hardware.firmware = [ pkgs.raspberrypiWirelessFirmware ];
16:45
<
clever >
ixxie: pkgs.raspberrypiWirelessFirmware
16:44
<
clever >
ixxie: your missing the firmware
16:44
<
clever >
[ 12.996512] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43430-sdio.bin failed with error -2
16:41
<
clever >
ixxie: this should also show 2
16:40
<
clever >
root@pi400:~# find /sys -name ios
16:40
<
clever >
ixxie: does `dmesg | grep mmc` show 2 mmc busses?
16:39
<
clever >
ixxie: step 1, check if `ip link` can see the wifi
16:34
<
clever >
if its already booting with the nixpkgs build, you can keep that
16:33
<
clever >
ixxie: i was doing that mostly to skip the compile times
16:26
<
clever >
ixxie: kinda
16:18
<
clever >
but u-boot breaks overlays
16:18
<
clever >
u-boot instead allows the kernel/initrd to be on the /boot dir of an ext4 fs
16:18
<
clever >
the firmware bootload requires the kernel/initrd on the fat32 fs
16:17
<
clever >
ixxie: yeah, fkms works on all models
16:12
<
clever >
ixxie: ive also only been able to get graphics to work using the fkms overlay, and the firmware loader
16:12
<
clever >
ixxie: also cehck the X log in /var/log
15:56
<
clever >
,libraries veleiro
15:16
<
clever >
i prefer using UUID's
15:14
<
clever >
so nixos-generate-config doesnt know to include the stuff providing /dev/tank/root
15:14
<
clever >
but lsblk doesnt understand that / is /dev/tank/root
15:14
<
clever >
lsblk understands the lvm and luks, and knows that /dev/tank/root (an lvm dev) is on /dev/root (a luks device), which is on /dev/nvme0n1p2
15:13
<
clever >
and i think zfs is the breaking point
15:13
<
clever >
i suspect its using lsblk to figure it out
15:12
<
clever >
this config, plus the normal fileSystems stuff, will get it all working
15:12
<
clever >
luks.devices.root = {
15:12
<
clever >
name = "root"; device = "/dev/nvme0n1p2"; preLVM = true;
15:12
<
clever >
initrd = {
15:11
<
clever >
jboy: certain combinations of luks, lvm, and zfs, will break the auto-detection of what devices are needed
13:49
<
clever >
thats involved in copying paths between 2 machines
13:49
<
clever >
cmdAddToStoreNar
13:49
<
clever >
angerman: though, its only used in a single place!
13:49
<
clever >
src/nix-store/nix-store.cc: SizedSource sizedSource(in, info.narSize);
13:46
<
clever >
angerman: `nix-store --verify --check-contents`
13:46
<
clever >
angerman: run it under gdb and `catch throw` to catch it
13:45
<
clever >
never seen it before though, you would need to get a backtrace
13:45
<
clever >
and it somehow didnt have enough bytes
13:45
<
clever >
angerman: this lets you wrap a source (like the pipes in haskell), to create a new source, that can only consume N bytes before creating a fake eof
13:44
<
clever >
if (this->remain <= 0) {
13:44
<
clever >
throw EndOfFile("sized: unexpected end-of-file");
13:44
<
clever >
size_t read(char * data, size_t len)
13:44
<
clever >
struct SizedSource : Source
13:44
<
clever >
src/libutil/serialise.hh: throw EndOfFile("sized: unexpected end-of-file");
11:24
<
clever >
to copy ${firstdrv}/foo.deb $out
11:24
<
clever >
simplest option, just wrap it in a second drv, runCommand
11:24
<
clever >
CMCDragonkai: yep, there it is, line 242 of vm/default.nix
11:24
<
clever >
mkdir -p -m 0700 $out
11:23
<
clever >
CMCDragonkai: if $out is already a directory for any reason, cp puts a file in the dir
11:23
<
clever >
cp out/make/deb/x64/*.deb $out
11:22
<
clever >
can you pastebin the full expr?
11:20
<
clever >
$out is still whatever you make it to be
11:19
<
clever >
CMCDragonkai: set -x will make it more obvious what is happening
11:11
<
clever >
CMCDragonkai: toss a `set -x` in, to see what its doing
11:04
<
clever >
options may exist to change that in bash, but ive not bothered looking into them
11:04
<
clever >
mananamenos: same rules as normal, the history gets commited to ~/.bash_history when the shell exits, and read when the shell starts
11:02
<
clever >
CMCDragonkai: if you run `env | grep 62` in the `buildPhase` does that path come up anywhere?
11:02
<
clever >
mananamenos: thats how env vars work
11:01
<
clever >
mananamenos: you would have to run tmux inside the nix-shell
10:52
<
clever >
CMCDragonkai: try raising memSize more
10:48
<
clever >
mananamenos: not sure then, ive not played with zsh much
10:47
<
clever >
CMCDragonkai: `no space left on device` is a disk error, but it could be a tmpfs, try increasing memSize also
10:45
<
clever >
CMCDragonkai: just add it to the derivation you passed to the vm tools
10:45
<
clever >
mananamenos: nix-shell requires bash, because all of the functions within nixpkgs assume you have bash
10:44
<
clever >
so add size=8192;
10:44
<
clever >
its just another attr to the derivation
10:44
<
clever >
CMCDragonkai: or disk size, line 404
10:40
<
clever >
CMCDragonkai: there are also dedicated tools just for dealing with rpm's
10:37
<
clever >
CMCDragonkai: it will use /dev/kvm if it can find it, and fall back to software emulation if it cant
10:36
<
clever >
CMCDragonkai: yeah
10:34
<
clever >
CMCDragonkai: then it gets ran as root in a vm, and has free access to a fake /, but only the products in $out will persist
10:34
<
clever >
CMCDragonkai: run vmTools.runInLinuxVM on the derivation
10:33
<
clever >
angerman: that happens if something in /nix/store was modified after building, you must either `nix-store --delete` it, or `nix-store --repair-path` it
10:17
<
clever >
yeah, anywhere before $HOME gets used
10:16
<
clever >
CMCDragonkai: yeah
10:08
<
clever >
CMCDragonkai: you can just shove this somewhere in the derivation
10:08
<
clever >
mkdir home
10:08
<
clever >
export HOME=$(realpath home)
09:25
<
clever >
yeah, and you can just run nix-instantiate with the same args (if its not -p based)
09:24
<
clever >
nix-copy-closure --include-outputs on a drv file
09:23
<
clever >
if you want the build-time deps of that drv, you need to map over every attr of the drv, and write them with pkgs.writeText
09:22
<
clever >
angerman: other way around, nix-shell always gives you an env that represents a derivation
04:13
<
clever >
rmcgibbo[m]: gccStdenv i believe
2021-03-07
21:00
<
clever >
boom, its systemd
20:59
<
clever >
za1b1tsu: that will tell you exactly which binary is to blame for the error msg
20:59
<
clever >
za1b1tsu: one fancy trick thats easier on nixos, `grep 'Error switching console mode' $(nix-store -qR /run/curent-system)`
20:39
<
clever >
on both ends
17:17
<
clever >
dmesg would tell you
17:15
<
clever >
its probably a hash of the contents, not a commit sha1
17:13
<
clever >
ive not tried that yet
17:11
<
clever >
but its missing on a diff box, i think it got moved
17:11
<
clever >
Miyu-saki: that filename, is a hash of the url, and where nix used to store that data
17:11
<
clever >
"96e789b05d2bd60881c221dfba38f0fe"
17:11
<
clever >
[root@system76:~]# cat .cache/nix/tarballs/1x6i5cafxg5kx9rc18w2cmq5y8jcn9b49cfq9bpnpjysdhl7j2hw.info
17:09
<
clever >
which gives me an idea...
17:09
<
clever >
Miyu-saki: if its been over an hour since the last fetch, nix will try to re-fetch it, but i think github etag based caching will let it reuse the old tar, if the rev hasnt changed
17:06
<
clever >
tarball-ttl = 3600
17:06
<
clever >
[root@system76:~]# nix show-config | grep ttl
17:03
<
clever >
Miyu-saki: that just refers to the tip of the nixos-20.09 branch
17:02
<
clever >
bisect time!
16:59
<
clever >
Miyu-saki: this is something ive used before
16:59
<
clever >
default.nix: # nix build -L -f ~/apps/rpi/rpi-tools/ pkgsCross.armv7l-hf-multiplatform.pkgsStatic.msd.rootDir
16:58
<
clever >
Miyu-saki: you can mix pkgsStatic and pkgsCross together
13:51
<
clever >
Reventlov: hydra says it took 2h 8m
13:24
<
clever >
Reventlov: this is how i changed the temp dir, when on non-nixos, similar can be acheived via systemd.services.nix-daemon
13:24
<
clever >
Environment="TMPDIR=/mnt/tmp"
13:24
<
clever >
pi@pi400:~ $ cat /etc/systemd/system/nix-daemon.service
13:06
<
clever >
ixxie: set it to false, and they go away
13:06
<
clever >
ixxie: aha! config.boot.initrd.includeDefaultModules
13:06
<
clever >
ixxie: yeah, thats the quickest solution
12:39
<
clever >
ixxie: run a `git grep ahci` on nixpkgs/nixos, and see where its being added
12:39
<
clever >
ixxie: all of the search utils hide packages with duplicate .name values
12:39
<
clever >
ixxie: you have to search using tab-completion in `nix repl '<nixpkgs>'`
12:34
<
clever >
ixxie: nope, that tells modprobe to not load it, but the fault is with nixos trying to copy the module into the initrd
12:31
<
clever >
or one of its related lists
12:31
<
clever >
ixxie: you need to remove it from the boot.loader.initrd.availableKernelModules somehow
12:31
<
clever >
ixxie: thats a driver for sata controllers, its not needed, but a recent bug in nixpkgs makes missing modules fatal
12:17
<
clever >
you would need to either paste an edited copy of this somewhere, or overrideAttrs the name
11:44
<
clever >
ixxie: that sounds like the image was for a larger device
11:27
<
clever >
ixxie: SD cards can fail
10:49
<
clever >
ixxie: try linuxPackages_rpi3 ?
10:47
<
clever >
the images need a bit of work, ive been wanting to go over all of them and make sure its all good
10:47
<
clever >
ixxie: by default, the nixos images want to use u-boot, and configuration.nix must be configured correctly, or it wont update things properly
10:44
<
clever >
ixxie: i just use plain zfs + nfs on my nixos nas
10:37
<
clever >
ixxie:
*digs*
08:46
<
clever >
ar: or making use of the protective mbr
08:39
<
clever >
viric: with care (or the right tooling), you can then align the gpt and iso partitions up on the same blocks, so one fs is seen by both
08:38
<
clever >
viric: the iso filesystem starts something like 32kb into the image, plenty of room to shove in either an mbr or gpt header
07:58
<
clever >
patagonicus: `nix show-derivation` will translate it to json
2021-03-06
19:27
<
clever >
if its in the cache, that will re-fetch it
19:27
<
clever >
ronthecookie: run ldd on the binary, then run `nix-store -r` on the relevant missing paths
19:23
<
clever >
back when i still ran gentoo, and had to compile firefox
19:23
<
clever >
viric: ah, rust wasnt even started (i think), when i first had such linker problems
18:48
<
clever >
hpfr: yeah
18:47
<
clever >
hpfr: /proc/PID/maps, shows all libraries mapped by a given pid, mesa should be in that mix
17:14
<
clever >
probably a lack of people using console mode
17:10
<
clever >
fbcon also complicates matters
16:54
<
clever >
viric: the scrollback buffer is lost if you change to a different tty
15:51
<
clever >
rather then doing multi-lib or cross, nixos just makes a 100% pure 32->32 env
15:51
<
clever >
nixos doesnt give you that option right now
15:51
<
clever >
yeah, cross-compile from 64->32 is one simpler option
15:49
<
clever >
viric: i had the same issue many years ago, just running the linker alone required over 3gig of ram
15:27
<
clever >
viric: ive not seen any that mount over http(s)
15:26
<
clever >
isaacr24: assuming default.nix is using the overrides on line 31 right, that should work
15:26
<
clever >
viric: sometimes, its simpler to just rip the hdd out, mount it elsewhere, nixos-install, and then boot that back in the target
15:24
<
clever >
viric: ack, irc cut it short
15:24
<
clever >
viric: this gets it down to 502mb before the squashfs
15:24
<
clever >
[clever@amd-nixos:~]$ nix-build '<nixpkgs/nixos>' -A config.system.build.toplevel --arg configuration '{ lib, ... }: { imports = [ <nixpkgs/nixos/modules/installer/netboot/netboot-minimal.nix> ]; hardware.enableAllFirmware=false; hardware.enableRedistributableFirmware = lib.mkForce false; system.extraDependencies = lib.mkForce []; disabledModules = [ "installer/cd-dvd/channel.nix" "profiles/base.nix" ]; nixpkgs.overlays = [ (self: super: { grub=self.utilli
15:23
<
clever >
isaacr24: can you pastebin that whole file?
15:22
<
clever >
isaacr24: if you are applying an overlay correctly, it should change the time-compat used by everything
15:19
<
clever >
viric: 655mb -> 531mb!
15:18
<
clever >
viric: profiles/base.nix looks like more fat to trim...
15:15
<
clever >
viric: it just does an overrideCabal, with doCheck = false;
15:13
<
clever >
[clever@amd-nixos:~]$ nix-build '<nixpkgs/nixos>' -A config.system.build.toplevel --arg configuration '{ lib, ... }: { imports = [ <nixpkgs/nixos/modules/installer/netboot/netboot-minimal.nix> ]; hardware.enableAllFirmware=false; hardware.enableRedistributableFirmware = lib.mkForce false; system.extraDependencies = lib.mkForce []; disabledModules = [ "installer/cd-dvd/channel.nix" ]; }'
15:13
<
clever >
viric: down to 670mb now
15:10
<
clever >
system.extraDependencies shaved another 100mb off
15:10
<
clever >
removing the firmware dropped mine from 1.4gig to 900mb
15:06
<
clever >
[clever@amd-nixos:~]$ nix-build '<nixpkgs/nixos>' -A config.system.build.toplevel --arg configuration '{ imports = [ <nixpkgs/nixos/modules/installer/netboot/netboot-minimal.nix> ]; }'
15:04
<
clever >
viric: swap
15:03
<
clever >
viric: why does this system have so little ram?
15:02
<
clever >
viric: grub shouldnt be needed, try removing it entirely?
15:00
<
clever >
yeah, but a lot of the tools need special options, due to the kernel being more limited in its unpacking
15:00
<
clever >
viric: i ran into similar problems with the cpio used to make an initrd, it needs `-H newc`
14:52
<
clever >
delete!, delete!
14:52
<
clever >
modules/installer/netboot/netboot.nix: else [ pkgs.grub2 pkgs.syslinux ]);
14:48
<
clever >
may need an override, setting grub2 = super.grub2.override { zfsSupport = false; };
14:47
<
clever >
where is grub becoming a dep?
14:47
<
clever >
viric: try the config first? and then override grub2 if that isnt enough
14:47
<
clever >
boot.loader.grub.zfsSupport
14:46
<
clever >
[clever@amd-nixos:~/apps/nixpkgs]$ man configuration.nix
14:46
<
clever >
9 , zfsSupport ? false
14:46
<
clever >
[root@amd-nixos:~]# nix edit -f '<nixpkgs>' grub2
14:36
<
clever >
so you can skip having to run one
14:36
<
clever >
qemu can also emulate a tftp server
14:35
<
clever >
-net user,tftp=${config.system.build.ftpdir}/
14:35
<
clever >
the .lkrn file, is ipxe packaged to look like a linux kernel
14:35
<
clever >
viric: there it is, -kernel ${config.system.build.ipxe}/ipxe.lkrn
14:34
<
clever >
oh, where did i put it...
14:34
<
clever >
and qemu can run it
14:34
<
clever >
ipxe has a dozen build targets, including what looks like a linux kernel
14:34
<
clever >
you can test on a non-root dir first, to figure out what args are needed
14:33
<
clever >
viric: in theory, just do fileSystems."/" = something; and it will just work
14:31
<
clever >
and all 1000 of them started fighting over ram at once
14:31
<
clever >
when i got home, turned the laptop back on, every single df woke up
14:31
<
clever >
and they slowly slipped into swap
14:30
<
clever >
ehmry: every 5 mins, cron would run `df -h`, and it would deadlock, and 1000's of them built up
14:30
<
clever >
ehmry: in the past, ive has nfs deadlock because i shutdown the server (a laptop) and took it with me on a trip
14:09
<
clever >
viric: the qemu test framework is using 9p's virtio backend, to mount a host fs in the guest, and skip any block devs
14:05
<
clever >
iscsi can support multiple writers, but you need an fs that allows it, and a server to coordinate writes
14:05
<
clever >
and iscsi only lets 1 client write at a time, preferably 1 client with entirely exclusive access
14:05
<
clever >
nfs has caused me troubles randomly
14:04
<
clever >
ive also been wanting a better file level network fs
14:03
<
clever >
grub thinks its an internal hdd!
14:03
<
clever >
witout any netboot support
14:03
<
clever >
plain grub can then boot from that block device
14:02
<
clever >
viric: so anything doing legacy bios calls to read the internal disk, will wind up reading iscsi instead
14:02
<
clever >
viric: if you do this in ipxe, it will hijack the legacy bios routines for reading a hdd, and map an iscsi device to it
14:02
<
clever >
sanboot iscsi:192.168.2.11:::1:iqn.2016-01.laptop-root
14:02
<
clever >
viric: oh yeah, and you dont even need to serve the kernel/initrd over ipxe, when using iscsi
14:00
<
clever >
but i'm not sure how much i woudl trust it, it would lead to inode collisions
13:59
<
clever >
nfs does have an option to just truncate the inode numbers to 32bits
13:59
<
clever >
and you just never notice, if your not using something like xfs on a huge disk
13:59
<
clever >
and a lot of packages just didnt opt-in
13:59
<
clever >
it has to be enabled by the configure script (by default)
13:59
<
clever >
if it returns non-zero, it must be the end of the dir!
13:58
<
clever >
viric: because nobody expected readdir() to return an actual error! lol
13:58
<
clever >
viric: so it randomly tells you, file not found, when the file clearly is found
13:58
<
clever >
viric: half of the bootstrap code in nixpkgs is built without that.....
13:58
<
clever >
viric: a 32bit userland then goes EOVERFLOW when you try to ls a dir with 32bit tools, that had been built without large-file support
13:57
<
clever >
viric: nfs will happily carry those inode numbers over the network
13:57
<
clever >
viric: if you are using xfs, with a disk over 1tb in size, then you wind up with inode numbers over 32bits long
13:57
<
clever >
viric: ive discovered that nfs can be problematic when the client is 32bit, and the server has certain fs combinations
13:56
<
clever >
viric: so i can expose a zvol to my windows box, and windows just says "sure" and treats it like another block dev, toss ntfs on, and your apps are all happy
13:56
<
clever >
viric: ive found nbd to be rather unreliable, iscsi surprisingly even has windows support
13:55
<
clever >
viric: and the server end, which is still buggy, it completely breaks the link if nixos-rebuild tries to restart tgtd
13:54
<
clever >
viric: but to create the rootfs itself, you would need to either build a disk image and share that, or connect it to a temporary box, and nixos-install to it
13:54
<
clever >
viric: you would build a config using fileSystems."/" = { device = "UUID=whatever"; iscsi = { enable = true; host="1.2.3.4"; lun = "something"; }; };
13:53
<
clever >
viric: tgtd and iscsi
13:43
<
clever >
yeah, mkforce should do it
13:35
<
clever >
i think its a bit of both
13:35
<
clever >
to avoid compatability problems from using the wrong versions
13:34
<
clever >
but its also mixing in some libs from debian
13:34
<
clever >
the FHS env used by things like steam, just symlinks them to look like a normal /usr/bin, but it still has the normal nix RPATH
13:33
<
clever >
viric: you could just build it the nix way, and then use patchelf to un-nix it
13:33
<
clever >
viric: the gcc that comes with nix has been heavily patched, to actively reject /usr/lib and to add rpath's into the store
13:28
<
clever >
viric: on my box, gzip, bzip2, lzma, xz, lzo, lz4
13:27
<
clever >
[root@amd-nixos:~]# cat /proc/config.gz | gunzip | grep CONFIG_RD
13:27
<
clever >
[root@amd-nixos:~]# modprobe configs
13:25
<
clever >
viric: havent seen that before, how big is the initrd? put the gz back?
13:15
<
clever >
viric: 20.09 is just using a stray var in a let block, so you cant force it off, but you can still use disabledModules to just omit zfs support from nixos entirely
13:09
<
clever >
viric: this module will try to detect if zfs is in the supportedFilesystems lists, you could maybe mkForce it to false, or disabledModules it
13:07
<
clever >
viric: you can mkForce those back to false, and the firmware will go away
13:06
<
clever >
nix why-depends ./result /path/to/python
13:06
<
clever >
`nix why-depends`
13:06
<
clever >
kill it with fire!
13:06
<
clever >
but if you just add yourself to the kvm group, it should work
13:05
<
clever >
that + means there is an acl in place also
13:05
<
clever >
CFS: but if you look at the default permissions, it may be in a group you could join
13:05
<
clever >
CFS: on nixos, its got write to everybody
13:05
<
clever >
crw-rw-rw- 1 root kvm 10, 232 Mar 4 21:52 /dev/kvm
13:04
<
clever >
CFS: you need write permissions to /dev/kvm