gchristensen changed the topic of #nixos-chat to: NixOS but much less topical || https://logs.nix.samueldr.com/nixos-chat
yurb has joined #nixos-chat
<gchristensen> adding parallel builds to r13y shaved 6hrs off the build
emily__ has joined #nixos-chat
emily__ has quit [Client Quit]
emily has joined #nixos-chat
nand0p has joined #nixos-chat
elvishjerricco has joined #nixos-chat
tazjin has joined #nixos-chat
manveru has joined #nixos-chat
andi- has joined #nixos-chat
NinjaTrappeur has joined #nixos-chat
edef has joined #nixos-chat
pie__ has joined #nixos-chat
pie___ has quit [Ping timeout: 250 seconds]
drakonis has quit [Quit: WeeChat 2.3]
ivan has quit [Quit: lp0 on fire]
harrow has quit [Quit: Leaving]
ivan has joined #nixos-chat
harrow has joined #nixos-chat
endformationage has quit [Quit: WeeChat 2.3]
<iqubic> So, I'm using Proton to play my games, and I'm wondering where on earth the game's files are.
<iqubic> Nevermind I just figured it out.
ivan has quit [Quit: lp0 on fire]
harrow has quit [Read error: Connection reset by peer]
ivan has joined #nixos-chat
jackdk has quit [Ping timeout: 250 seconds]
harrow has joined #nixos-chat
iqubic has quit [Ping timeout: 268 seconds]
<colemickens> If I'm understanding that right... :/
jasongrossman has joined #nixos-chat
__monty__ has joined #nixos-chat
__Sander__ has joined #nixos-chat
obadz has quit [Quit: WeeChat 2.3]
obadz has joined #nixos-chat
jasongrossman has quit [Ping timeout: 246 seconds]
jasongrossman has joined #nixos-chat
<kgz> colemickens: but hopefully no one uses docker as a security measure
<tilpner> But plenty of people are installing random binaries from ~~the internet~~ Docker Hub
<tilpner> But grahamc is "pretty sure NixOS is not vulnerable" (check #nixos-security logs)
<srhb> NixOS shouldn't be, but yeah. Opened a PR anyway.
<srhb> This is not the first time it happens, and it won't be the last. I sure hope people don't allow root in their containers (but I know they do...)
<joepie91> [11:15] <kgz> colemickens: but hopefully no one uses docker as a security measure
<joepie91> a lot of people do
<joepie91> the belief that Docker provides secure isolation is really widespread unfortunately
<srhb> "secure" is a scale..
<srhb> Until it isn't :-)
<joepie91> "secure" in the sense of "secure against malicious users/programs as root"
<joepie91> (which Docker isn't designed to be)
<srhb> Not sure their marketing department would agree. :-P
<gchristensen> what shykes said in a singel citeable HackerNews comment 4years ago does not reflect what their marketing department would say
<gchristensen> you know it, he knows it, we know it, consumers of docker marketing probably don't
<lejonet> What, you mean that containersation isn't a security boundry? :O I thought it was just lightweight VMs! </sarcasm>
<lejonet> (I still don't understand what part of "Root in container is root on host" that people don't understand... root in the container has the same rights to modify the kernel usually... (unless userns, then its a little bit less but not much)
<joepie91> gchristensen: aye, I just don't assign any value to marketing drivel
<joepie91> :p
<joepie91> lejonet: that is not true for OpenVZ though
<lejonet> srhb: secure is a weighted scale, against a threat model... so I can design 150% secure system, as long as my threat model is bad enough xD
<lejonet> joepie91: OpenVZ is a different beast than docker, rkt and LXC for example :)
<joepie91> aye, but it's containers nevertheless
<joepie91> you *can* design containers that can run untrusted code as root safely
<joepie91> (for a reasonable value of 'safely')
<srhb> I think we're all in violent agreement here.
<lejonet> As they've actually gone in and done more work in the kernel to ensure separation and so (I'm not that familiar with OpenVZs details so don't qoute me on that)
<joepie91> lejonet: yeah, basically they've heavily modified the kernel to fence off ~everything that could be abused
<lejonet> joepie91: ofc, its all about what and how you separate :)
<lejonet> srhb: Mhm, that is my analysis too
<lejonet> joepie91: it could be argued, if you're allowed to abuse some terminology, that OpenVZ is a "true container" whereas docker, rkt and LXC is just "glorified, namespaced chroots"
<joepie91> aye
<joepie91> well
<joepie91> supposedly unprivileged LXC can be equivalent to OpenVZ?
<lejonet> Its still mainly based on namespacing, it still wouldn't have the hardening in kernelspace that OpenVZ has, but yeah, its not THAT far away
<lejonet> namespacing + capabilities gets you fairly far honestly
<lejonet> One of the biggest problem with root in containers is the fact that the uid 0 has some special handling in kernelspace, regardless of stuff enforced in userspace
<lejonet> In some cases, its treat differently than "just" a uid
<__monty__> Are rkt and openVZ vulnerable to the CVE? Sounds like openVZ isn't?
<lejonet> (at least that is what I've been told, I haven't investigated what and where it'd be)
<__monty__> I wonder why nspawn isn't though.
<joepie91> __monty__: OpenVZ doesn't use runc
<joepie91> nor even mainline kerneel
<joepie91> kernel*
<joepie91> at least, OpenVZ <7 didn't
<joepie91> dunno about 7
<lejonet> __monty__: allegedly nspawn isn't vulnerable due to them handling the namespacing differently
<lejonet> But I haven't investigated the CVE all that thoroughly outside of the mail sent to openwall
<joepie91> OpenVZ basically has (had?) its entire own customized kernel specifically for OpenVZ, based off 2.6
<joepie91> with its own containerization implementation
<joepie91> far predates the cgroups stuff etc. in Linux :P
<elvishjerricco> Serious question: Containers are *supposed* to be secure though, even with uid = 0, aren't they? Any vulnerability is a bug? I.E. the problem is the shear size of the attack surface area, not the container model?
<tilpner> Depends on which definition of container you use. If you ask kata containers, they'd probably say yes
<tilpner> (But then, some people wouldn't call them containers)
<elvishjerricco> Yea for instance systemd-nspawn still explicitly says it should not be considered secure IIRC
<__monty__> Funny how it turns out to be toward the more secure end of the spectrum, at least for the moment : )
<joepie91> elvishjerricco: I'd say that the base purpose of containers is protection against accidental(!) environment contamination
<joepie91> not intentional contamination (ie. breakouts)
<elvishjerricco> How does systemd determine when a unit has successfully "activated"? I've got one stuck in an `activating (start)` state.
<joepie91> elvishjerricco: this is dependent on how the unit is defined, I believe; eg. a unit can be configured to wait for an active completion signal from the application
<elvishjerricco> joepie91: Oh wait, does `BusName=...` imply `Type=dbus`? I guess that'd make sense, since there's no type line in this unit file.
<elvishjerricco> In that case... I guess the daemon is failing to acquire the bus name
<joepie91> elvishjerricco: hm, I'm not aware of systemd doing implicit anything. but possibly
<joepie91> aha
<joepie91> Behavior of dbus is similar to simple; however, it is expected that the service acquires a name on the D-Bus bus, as configured by BusName=. systemd will proceed with starting follow-up units after the D-Bus bus name has been acquired. Service units with this option configured implicitly gain dependencies on the dbus.socket unit. This type is the default if BusName= is specified.
<joepie91> so it DOES do things implicitly
<elvishjerricco> Now to figure out why it's not getting the bus name...
<lejonet> Take this with a grain of salt but I think the notion of containers supposed to be secure, from a breakout/security perspective, mainly comes from people that don't really know what techniques that at least LXC, runc and rkt uses to "make" the containers
<lejonet> I think it stems from the confusion of containers being "like a VM, but lighter on system resources"
<lejonet> Whereas in reality, it doesn't share much but the logical separation with VMs, everything else is different
<lejonet> However, as has been pointed out, you _can_ use containers securely, but they aren't in and off themselves any more secure than having say a chroot that gets some namespacing done for it
drakonis has joined #nixos-chat
endformationage has joined #nixos-chat
<gchristensen> http://ix.io/1ARn reproducibility data!
<gchristensen> todo: generate a report out of it :|
<averell> it would be pretty sweet if that could someday be part of the build plan. Oh you made an irrelevant whitespace change? I don't need to rebuild 4000 packages.
<gchristensen> you want RFC-17! https://github.com/NixOS/rfcs/pull/17
<{^_^}> rfcs#17 (by wmertens, 1 year ago, open): [RFC 0017] Intensional Store
<samueldr> "adding the quiet option cut 18 seconds off the boot time [of some machines]"
<joepie91> lejonet: sounds about right
<samueldr> (server hardware; power 9 mainly)
<gchristensen> hilarious
etu has quit [Ping timeout: 250 seconds]
etu has joined #nixos-chat
__Sander__ has quit [Quit: Konversation terminated!]
<lejonet> samueldr: I cut down kernel compile time with like 40 min by switching console on a server I have xD (it has a pre-KMS enabled AST chip for VGA...)
obadz has quit [Ping timeout: 272 seconds]
obadz has joined #nixos-chat
srhb- has joined #nixos-chat
{^_^} has quit [Ping timeout: 240 seconds]
drakonis has quit [Ping timeout: 240 seconds]
ma27 has quit [Ping timeout: 240 seconds]
sphalerite has quit [Ping timeout: 240 seconds]
lopsided98 has quit [Remote host closed the connection]
srhb has quit [Read error: Connection reset by peer]
andi- has quit [Ping timeout: 240 seconds]
srhb- is now known as srhb
{^_^} has joined #nixos-chat
ma27 has joined #nixos-chat
lopsided98 has joined #nixos-chat
drakonis has joined #nixos-chat
sphalerite has joined #nixos-chat
andi- has joined #nixos-chat
kgz has quit [Ping timeout: 250 seconds]
kgz has joined #nixos-chat
hedning has quit [Remote host closed the connection]
__monty__ has quit [Read error: Connection reset by peer]
__monty__ has joined #nixos-chat
__monty__ has quit [Remote host closed the connection]
__monty__ has joined #nixos-chat
lopsided98 has quit [Remote host closed the connection]
drakonis has quit [Ping timeout: 240 seconds]
sphalerite has quit [Ping timeout: 240 seconds]
drakonis has joined #nixos-chat
lopsided98 has joined #nixos-chat
sphalerite_ has joined #nixos-chat
<elvishjerricco> So here's the stupidest NixOS config I've ever written: https://www.irccloud.com/pastebin/aHFTXIaB/
<gchristensen> interesting
<elvishjerricco> gchristensen: I was playing around with using systemd for initrd, since I really don't like the ad-hoc crappy device/filesystem dependency management we have now. Eventually got fed up trying to basically build an OS from scratch and just put NixOS in an initrd :P
<gchristensen> nice :P
<elvishjerricco> If I can get it small enough and disable enough services, there's a slim chance this could be usable
<elvishjerricco> I was surprised to find it worked on the first try, whereas my other attempt took a while to get anywhere
<samueldr> stupidest or wisest?
<samueldr> I mean, you have a system to build a linux-based operating system *right there*
sphalerite_ is now known as sphalerite
<elvishjerricco> samueldr: The reason I even started down this path is even stupider: Linux as the bootloader so that encrypted /boot doesn't take ages to unlock and for support for arbitrary file systems
<samueldr> :)
<sphalerite> oh but then you'll also need a smaller linux for your firmware ;)
<samueldr> that's not stupid; I think mobile-nixos will need to act that way to work on the current targeted platforms
<samueldr> sphalerite: https://www.linuxboot.org/ :)
<sphalerite> OTT: does anyone know things about configuring the kernel to be tiny
<elvishjerricco> sphalerite: Heh, linux all the way down
<sphalerite> samueldr: yep that's the reason I asked that question just there x)
<sphalerite> samueldr: would be awesome to get that running onmy chromebook
<elvishjerricco> samueldr: Is there a mobile-nixos plan?
<samueldr> not really
<samueldr> currently the plan is to get myself a platform up and running to continue developing
<elvishjerricco> Maybe if plasma-mobile becomes usable soon, we can open an RFC or something.
<samueldr> since I lost the use of my cellphone
<samueldr> but do note that I'm not really aiming for stage-2 experience right now; that's left as an exercise to the reader
<sphalerite> if only I had more free time x)
<joepie91> sphalerite: talk to clever, probably, re: tiny kernel
<samueldr> sphalerite: u-boot just merged (like a week ago?) support for a gru device
<sphalerite> my oneplus one partly-broke during FOSDEM, in a way that makes it very suitable for mobile-nixos experiments
<sphalerite> samueldr: ooooooh
<samueldr> maybe that'll help getting a more standard boot?
<sphalerite> samueldr: but linuxboot is cooler :p
<samueldr> yes :)
<elvishjerricco> `363M initrd` This is fine
<sphalerite> clever: joepie91 says you're probably one to talk to about a tiny kernel?
<sphalerite> (tiny in this case meaning small enough to combine with coreboot and a little linuxboot initrd into 8MB)
<samueldr> sphalerite: oneplus devices are probably good devices for mobile-nixos
<samueldr> depending on the model, maybe it's trivial enough
<elvishjerricco> Is there a way to just disable networking in nixos? I wanna try to remove as many services as possible from this initrd
<samueldr> sphalerite: you're 98% of the way done if there's already postmarketOS work that's been done
<samueldr> (though I've been moving away from the postmarketOS things so it's not plug and play or anything)
<sphalerite> ah nice
<samueldr> oh, though it's 32 bit
<clever> sphalerite: one min
<samueldr> not that it won't work, but you know the pain of userland 32 bit nixos
<clever> this is a random project i did back at bayhack
<clever> its a haskell based init system, in the initrd, and now staticly linked
<clever> its <2mb in size currently
<sphalerite> elvishjerricco: disable the tasks/network-interfaces.nix module and all the other modules that doing so breaks?
<sphalerite> clever: it's about the kernel, not the initrd
<clever> sphalerite: *looks*
<clever> -r--r--r-- 1 root root 4.2M Dec 31 1969 /run/current-system/kernel
<clever> [clever@amd-nixos:~/apps/nixpkgs]$ ls -lh /run/current-system/kernel -L
<clever> current nixos kernel is 4.2mb without any config changes
<clever> i have seen it <1.4mb, back in the 2.6 days
<sphalerite> clever: yeah but I need one with all the modules needed for the hardware built in
<clever> sphalerite: which hardware? which modules?
<sphalerite> gru bob chromebook (rk3399 chipset)
<clever> are you able to cross-compile it under nix-shell?
<sphalerite> haven't tried, but compiling it natively works fine
<samueldr> sphalerite: might want to borrow the config from chromeos'?
<clever> sphalerite: i currently lack powerfull arm machines, so i would need to do testing under cross
<sphalerite> clever: community box? :)
<sphalerite> samueldr: oh hm
<samueldr> (not sure where that would be though)
<clever> sphalerite: oh, i forgot, lol
<samueldr> and alternatively
<samueldr> cross-compiling the kernel works fine :)
<clever> sphalerite: and i'm in!
<clever> sphalerite: ok, what config flags are needed?
<sphalerite> clever: good question :p
<samueldr> clever: I guess the maximally required config options are in the penultimate previous link
<samueldr> probably possible to cut things for a firmware (do you need wifi?)
<clever> [clever@aarch64:~]$ nix-shell -E 'with import <nixpkgs> {}; linux.overrideAttrs (drv: { nativeBuildInputs = drv.nativeBuildInputs ++ [ ncurses ]; })'
<clever> 3
drakonis has quit [Quit: WeeChat 2.3]
<clever> [nix-shell:~/linux-4.14.95]$ make menuconfig
<sphalerite> clever: I know how to configure and build a kernel, just not which options (are safe) to twiddle
<clever> sphalerite: its mostly a guessing game
<sphalerite> also I usually use with import <nixpkgs> {}; linux_latest.overrideAttrs (o: {src = null; nativeBuildInputs = o.nativeBuildInputs ++ [pkgconfig ncurses bison flex]; })
<clever> [nix-shell:~/linux-4.14.95]$ export NIX_BUILD_LDFLAGS="${NIX_BUILD_LDFLAGS} -lncurses"
<sphalerite> for the shell
<sphalerite> that way it finds ncurses itself without that hack
<clever> ah, pkgconfig is used
<clever> but it wont complain if pkgconfig is missing
<sphalerite> yep
<sphalerite> it also needed bison and flex for something or other at some point I think, maybe kconfig parsing stuff? idk
<clever> do you count the compressed or uncompressed size?
<sphalerite> idk, whatever coreboot can use as a payload is fine :p
<clever> i suspect that both will work, and the compressed just has a stub to unpack itself
<clever> .....
<clever> either this community box is crazy powerful, or i just havent built a kernel by hand in a decade
<clever> it built in 15 seconds
<sphalerite> it has 64 powerful cores
<clever> it usually took 10mins or more....
<clever> `time` does report 6mins of userland usage
<clever> -rw-r--r-- 1 clever users 1.4M Feb 12 22:25 arch/arm64/boot/Image.gz
<clever> 1.4mb with entirely default configs
<sphalerite> by "powerful" I mean more powerful than the thunderx cores, not sure
<sphalerite> default as in make defconfig?
<clever> not even that, i just went directly to `make menuconfig`, and then exited with zero changes
<sphalerite> I wonder if that actually boots :p
<clever> /home/clever/linux-4.14.95/arch/arm64/boot/Image.gz
<clever> do you have access? i could throw it into /tmp/ for you?
<clever> [nix-shell:~/linux-4.14.95]$ sha256sum /home/clever/linux-4.14.95/arch/arm64/boot/Image.gz
<clever> 0c4b91f5eed477d65eda1ee7f19dd7a9fae6c0a9b92e4952be720ddcb9f03160 /home/clever/linux-4.14.95/arch/arm64/boot/Image.gz
<clever> [nix-shell:~/linux-4.14.95]$ cp /home/clever/linux-4.14.95/arch/arm64/boot/Image.gz /tmp/
<clever> you can now scp it down from the community box
<clever> i'll poke around in the config
<sphalerite> is that without any modules?
<clever> i ran `make Image.gz` so it just didnt build the modules
<sphalerite> it also won't be fun without appropriate dtbs :p
<clever> part of the point of dtbs is to be interchangable, so try using your old ones?
<sphalerite> I thought they vary from kernel version to kernel version
<clever> CONFIG_EMBEDDED looks like a good flag to start with, but technically its just controling the visibility of others
<sphalerite> incompatibly
<sphalerite> samueldr: didn't you say that?
<clever> sphalerite: i'm using the 4.14.95 kernel from nixpkgs, so if you use the same build?
<clever> do you want swap support?
<clever> CONFIG_SWAP=n may be of use
<clever> -rw-r--r-- 1 clever users 1447364 Feb 12 22:31 arch/arm64/boot/Image.gz
<samueldr> sphalerite: I said nothing about config options, just asked "do you need wifi?"
<samueldr> or uh
* samueldr re-reads
<samueldr> [17:29:36] <clever> part of the point of dtbs is to be interchangable, so try using your old ones?
<samueldr> [17:29:51] <sphalerite> I thought they vary from kernel version to kernel version
<samueldr> you're both righr
<samueldr> right*
<clever> namespace support?
<samueldr> device trees are *supposed* to be a 1:1 representation of the hardware
<samueldr> so they shouldn't change
<samueldr> but fixes, either bug fixes or additions are often made after the fact in the kernel tree
<clever> CONFIG_NAMESPACES=n, -rw-r--r-- 1 clever users 1443636 Feb 12 22:33 arch/arm64/boot/Image.gz
<samueldr> I don't know if they have strong backwards and forwards compatibility guarantees though
<clever> 3kb reduction
<clever> sphalerite: CONFIG_NAMESPACES costs you 3kb!
<sphalerite> so much :p
<clever> initrd support is off by default, you likely want it on?
<sphalerite> yeaaaaah…
<clever> and i'm guessing youll only want gzip support for the initrd
<clever> by default, it supports ~6 compression algos for the initrd
<clever> -rw-r--r-- 1 clever users 1455103 Feb 12 22:35 arch/arm64/boot/Image.gz
<sphalerite> idk, I'd guess that lzma would make it smaller
<sphalerite> and smaller is always nice
<clever> 11kb cost for gzip initrd
<clever> -rw-r--r-- 1 clever users 1449347 Feb 12 22:36 arch/arm64/boot/Image.gz
<clever> 5kb savings if you switch from gzip to lz
<clever> oh right
<clever> [nix-shell:~/linux-4.14.95]$ find -name built-in.o -print0 | xargs -0 du -h | sort -h
<clever> sphalerite: linux will merge every .o file in a given directory into a built-in.o
<clever> and then recursively go that, up the tree
<clever> 24K ./drivers/built-in.o
<clever> so i can see that something in drivers is costing 24kb
<clever> 4.0K ./drivers/nvme/target/built-in.o
<clever> i dont think you want nvme support?
<sphalerite> you probably want --apparent-size?
<clever> 11K ./drivers/media/built-in.o
<clever> 11K ./drivers/media/rc/built-in.o
<clever> and why is remote control stuff enabled??
<clever> 24K ./drivers/built-in.o
<clever> CONFIG_RC_CORE=n is likely wanted
<samueldr> probably don't need audio, unless you want to make it go "bong"
<sphalerite> oh it needs to go "bong"
<sphalerite> also holy crap the chromebook boots so much faster off the emmc than off the sd card :(
<clever> sphalerite: uefi support?
<sphalerite> to the extent that uefi is necessary with coreboot? :)
<clever> -rw-r--r-- 1 clever users 1374564 Feb 12 22:41 arch/arm64/boot/Image.gz
<clever> 74kb savings!
<clever> CONFIG_EFI=n shaved 74kb off
<clever> CONFIG_SUSPEND=n i really doubt you want suspend on here
<clever> -rw-r--r-- 1 clever users 1353850 Feb 12 22:46 arch/arm64/boot/Image.gz
<clever> CONFIG_SUSPEND=n shaves another 20kb off
<elvishjerricco> Is there a way to forcefully remove services added via `systemd.packages`?
<clever> sphalerite: CONFIG_PRINTK, you could disable printk, lol
<clever> -rw-r--r-- 1 clever users 1281884 Feb 12 22:49 arch/arm64/boot/Image.gz
* samueldr is thinking
<clever> CONFIG_PRINTK=n shaves another 70kb off, at the cost of zero possibility of debug
<samueldr> since I anyway broke my (armv7) chromebit, I could maybe use it as a starting point for depthcharge support ni mobile-nixos
<samueldr> broke my setup on the chromebit*
<sphalerite> samueldr: do you know about thefloweringash's depthcharge nixos module? https://github.com/thefloweringash/kevin-nix/blob/master/modules/depthcharge.nix
<samueldr> yes, though I'm thinking that having the mobile nixos thing there makes sense if I need to deal with generations in the initrd anyways for phones
<samueldr> (also thinking to make a standard UEFI mobile-nixos initrd to dogfood it)
<clever> sphalerite: oh, lol, this kernel doesnt have module support enabled!
<samueldr> probably not an issue if the goal is to kexec into a bigger badder kernel
<sphalerite> clever: yeah, I strongly suspect that a config pieced together like that won't boot on here
<sphalerite> clever: not because it doesn't have module support but because it doesn't have the hardware support
<clever> sphalerite: it would help if i had a .config to start with, oh, the one you linked may help
<sphalerite> :p
<elvishjerricco> I can't even find the part of NixOS that deals with `systemd.packages`...
<sphalerite> ,find system/boot/systemd.nix
<{^_^}> ,find is temporarily unimplemented
<sphalerite> whaaaaat
<sphalerite> elvishjerricco: nixos/modules/system/boot/systemd.nix
<elvishjerricco> sphalerite: I checked systemd.nix but I don't see it there
<elvishjerricco> Like I see the option definition but no usage of it
<clever> sphalerite: switched to that config, now it takes more then 15 sec to build, lol
<clever> -rw-r--r-- 1 clever users 5984019 Feb 12 22:56 arch/arm64/boot/Image.gz
<clever> and its a full 5mb!
<sphalerite> elvishjerricco: oh hm
<sphalerite> elvishjerricco: nixos/modules/system/boot/systemd-lib.nix
__monty__ has quit [Quit: leaving]
<elvishjerricco> sphalerite: Yea, but there's still a gap in between; where is systemd.packages actually converted to the `units` list?
<elvishjerricco> Oh wait I think I found it
<clever> sphalerite: do you want ext4 support?
<sphalerite> elvishjerricco: it's not :)
<clever> btrfs?
<elvishjerricco> Yea, there's a bash loop elsewhere
jasongrossman has quit [Quit: ERC (IRC client for Emacs 26.1)]
<sphalerite> clever: btrfs, ext4 and luks!
<clever> -rw-r--r-- 1 clever users 5781241 Feb 12 23:01 arch/arm64/boot/Image.gz
<clever> removing audio and rc support shaved some off
<sphalerite> but, but, bong!
<clever> removing fuse and f2fs
<clever> removing iso 9660 support
<clever> and UDF
<clever> fat?
<clever> nfs?
drakonis has joined #nixos-chat
<sphalerite> nfs could be cool, although that would probably also require wifi or ethernet stuff to be useful
jasongrossman has joined #nixos-chat
<clever> CONFIG_IKCONFIG=m, -rw-r--r-- 1 clever users 5613672 Feb 12 23:14 arch/arm64/boot/Image.gz
<clever> sphalerite: that option was baking the entire .config file into the kernel image
<clever> sphalerite: does the board have a PCI bus?
<sphalerite> yeah, only for the wifi though I think
<clever> sphalerite: what does lspci say when ran on the board?
<sphalerite> pci bridge and ethernet controller
<clever> then you def want pci support
<sphalerite> why?
<sphalerite> said "ethernet controller" is the wifi card
<sphalerite> well, "card"
<sphalerite> but yeah, I don't think I need a wifi driver in the firmware
<sphalerite> of course I'll want it in the OS kernel
<sphalerite> but that only gets kexec'd by linuxboot, which itself doens't need to talk to it
<clever> oh, then i should turn on kexec
jackdk has joined #nixos-chat
<clever> -rw-r--r-- 1 clever users 5621967 Feb 12 23:28 arch/arm64/boot/Image.gz
<sphalerite> anyway, I need to sleep for now
<sphalerite> thanks for the help!
<sphalerite> Gnight
pie___ has joined #nixos-chat
pie___ has quit [Remote host closed the connection]
pie__ has quit [Ping timeout: 246 seconds]
pie__ has joined #nixos-chat