<clever>
nh2: ive only ran haskell-init in qemu, but i used it as the ramdisk init, so it is the VERY FIRST userland thing to run, and nothing else is mounted
<clever>
nh2: there may also be kernel flags to pre-mount /dev/ for you
<nh2>
clever: yes, I linked them in the issue I filed on your repo :D
<clever>
heh
<nh2>
clever: I have now subdued the chromebook to boot an Ubuntu root FS that I made with debootstrap
<clever>
nh2: sounds like i just need to catch the exception and ignore that already being mounted
<nh2>
clever: but I still need a little help making a NixOS root FS
<clever>
nh2: one min
<clever>
nh2: ext4, zfs, or squashfs?
<nh2>
clever: technically I just need a directory that I can rsync over to the SD card, which is already pre-formatted
<{^_^}>
systemd/systemd#11974 (by nh2, 5 weeks ago, closed): The getrandom() feature check is insufficient on some kernels and triggers assertion failure
<samueldr>
I'm eyeing a new model which isn't yet in the supported builds from mrchromebox, and it annoy me... only because maybe there's a reason other than "not got around to it" it wouldn't be supported :/
<nh2>
samueldr: found a but created by ChromiumOS not picking kernel patches from upstream correctly
<samueldr>
oof!
<nh2>
samueldr: I'm using this device only because I got it for free from Google once and my mom has been using it as a laptop since then; the last OS upgrade destroyed the ChrUbuntu it had since 12.04 so it's time to set this device up anew from first principles
<nh2>
samueldr: read the bug summary at the end if you want a horror story
<samueldr>
yeah, the oof! was from the summary
<nh2>
samueldr: I'm only doing this because I hate throwing away perfectly-working hardware; for any new device I think I would just not bother with all the effort and buy a used Thinkpad, and save the 100 hours that ChromeBooks have cost me so far
<samueldr>
I personally like the hardware and firmware effort of those machines; mainly how they upstream everything (or did) as a principle... few devices ship with a coreboot-based firmware which can be securely changed
<samueldr>
but that's with experience only from those which support the tianocore based builds
<nh2>
samueldr: yeah, I certainly am in a frustrating spot because mine is probably one of the hardest to tame
<samueldr>
sounds like it, that's pre depthcharge AFAIUI
<samueldr>
and without a legacy rom boot option possibly?
<nh2>
right, it can't do that
<nh2>
I had to recompile the chromiumos kernel just to get console output to see why stuff doesn't work, did all debugging with a fully black screen before that
<nh2>
samueldr: using the length of `sleep()` to figure out what's happening :D
<nh2>
and measure how long it takes for the device to reboot from boot
<samueldr>
far from the now apparently ubiquitous case-closed-debugging :)
<nh2>
samueldr: so I may be preoccupied, perhaps buying one of the new ones IS a good way to support devices that are as open-source as possible and with coreboot supported off-factory
<samueldr>
I'm not sure there is a good way to *signal* that's why they're bought :/
<samueldr>
which annoys me a bit
<nh2>
samueldr: when I get some time in some years I'll produce my own phone and laptop
<samueldr>
though in a weird twist of fate, my specific needs in a laptop makes the chromebook option the cheaper and more flexible option ¯\_(ツ)_/¯
<clever>
nh2: any ethernet or serial port?
<nh2>
clever: no and no. Apparently the things have a serial port somewhere if you disassemble them
pie_ has quit [Ping timeout: 258 seconds]
<nh2>
samueldr: I just want to give somebody 2k $ and get a fully OS device without blobs. Like the Raptor Talos, but for phone and laptop and with good form factors. If nobody does it, I'll have to do it myself
<nh2>
samueldr: I already have some contacts in China; apparently they do you a proper assembly line already for 1M revenue, so at $2k I'd have to kickstarter only 500 units
<samueldr>
but it's 32 bit and not in production anymore iirc
<samueldr>
nh2: oh neat
<clever>
novena also has an FPGA onboard
<samueldr>
yeah, the novena was sweet looking
<samueldr>
a real "heirloom" type thing
<clever>
samueldr: yeah, that looks sweet
<samueldr>
speaking of allwinner, nh2, while not blob-free pine64 is gearing up to produce an allwinner-based phone
<samueldr>
though I say that, I think allwinner will be mostly blob free starting with Kernel 5.2... something about Lima finally hitting mainline
<nh2>
samueldr: as time progresses, the topic of what to put _into_ the phone seems to slowly go away, for example the Librem 5; for me what's missing beyond that is the outer part (I'd like a small 4.5 inch phone like the Moto X I have, and a laptop that has a Thinkpad X220 keyboard)
<nh2>
so I hope that by the time I make my assembly line the OS interior parts are already ready :D
<samueldr>
you must know about those franken thinkpad from china
<nh2>
samueldr: of course, my friend got one. We even reverse-engineered its fan control assembly and made the first open-source replacement: https://github.com/bitonic/x62-fancontrol
<samueldr>
:)
<samueldr>
(those too can run coreboot!)
<nh2>
unfortunately the display died when he tried to put xiph.org's LED display backlight
<clever>
samueldr: would you consider the rpi blob-less if the blobs where replaced with open-source?
<nh2>
(we expected that but it was still a bummer)
<samueldr>
clever: I personally am less annoyed by blobs, as long as they are obvious and freely pokable and replaceable
<samueldr>
which is why I think the librem 5 is just beyond crazy
<clever>
the only blob you cant replace on the rpi is the boot rom in OTP, but that is freely readable
<clever>
but i think its also got a license or something on it, and your not supposed to share the image
<clever>
so all youll find online is directions on how to dump it
<nh2>
clever: I still need some more guidance on how to do this: Right now I have a file that describes my NixOS configuration, as in `{config, pkgs, ...}:{ services.nginx.enable = true; }`. Now how must I combine that with `callPackage <.../make-system-tarball.nix>`?
<samueldr>
to (hopefully) achieve RYF, they hide the DDR training blobs into a separate storage, accessible from a processor which won't be "touchable" by the end-user
<samueldr>
so basically saying "yuck I don't want to touch it so you shouldn't be able to touch it"
<clever>
nh2: you want to pass callPackage a derivation, such as system.build.toplevel, or a regular old writeScript that somehow refers to system.build.toplevel
<clever>
nh2: pass make-tarball?
<clever>
s/?/*/
<clever>
lol, typo on the typo!
<samueldr>
though as far as "blob free" I think it goes on a scale, most of the time the CPU will have the initial boot program burned in; hard to not have it as a blob :) though source would be fine
<clever>
nh2: if you toss me a link to your github and files, i could look at what has to change
<samueldr>
then, up to the "firmware", e.g. u-boot+ATF, I'm fine if there's a bit of blobbyness, but I expect to be able to poke at it and change it, even if it mean writing to a flash chip
<clever>
samueldr: i think the assembly for the allwinner rom is on a wiki, lol
<clever>
samueldr: the rpi boot rom will search for "bootcode.bin" on the nand-flash, spi-flash, sd card (2 busses), usb mass-storage, and usb-ethernet
<samueldr>
it doesn't really count if it's a disassembly of the blob :) though helps
<samueldr>
yeah, the booting from the raspberry pi is a bit blobby, but not too much annoying imo, the main misfeature is having it live on the main storage media
<clever>
samueldr: the official bootcode.bin can then load start.elf from SD, mass-storage or ethernet
<samueldr>
(but that's not a Freedom of Blobbyness issue)
<clever>
and there is a second "bootcode.bin" that causes the pi to behave like a mass-storage device
<samueldr>
believe me, I know all too well about how the raspberry pi boots :)
<clever>
oh, and the boot rom can load bootcode.bin over usb, as a slave (rather then master), so a PC can push it over
<nh2>
clever: right now I have only 1 file, let's call it `configuration.nix`, and contains only:
<nh2>
clever: I can successfully builds it as `toplevel` using:
<nh2>
` nix-instantiate '<nixpkgs/nixos>' -A config.system.build.toplevel -I nixos-config=configuration.nix`
<samueldr>
though yeah, my point with the librem 5 is, if you're going to have a blob, cordon it off in a way where you can exhibit it, change it, don't hide it in some weird sketchy way :(
<nh2>
clever: couple questions: what's the symlink for? Can I also just put `config.system.build.toplevel` into `contents` instead and have no symlink, or something like that?
<clever>
nh2: how will you know where init is in /nix/store/ ?
<nh2>
clever: ah, I see. I had somehow assumed I could/should have the contents of `toplevel` in the top-level of the tarball as well
<clever>
nh2: needs interpolation, so it points to the init inside toplevel
<nh2>
clever: btw, when I build `toplevel`, there's also an `/init` at the root. So perhaps that does work?
<nh2>
though the kernel sources don't indicate it
<clever>
nh2: directly in / or in result/init ?
<nh2>
clever:
<nh2>
/nix/store/9w6cd4qxfjn84ip0k2zafhv7hjf33kgp-nixos-system-nixos-19.09.git.05a53ec/init: a /nix/store/yjkch3aia9ny4dq42dbcjrdwqb1y8c33-bash-4.4-p23/bin/ba script, ASCII text executable
<nh2>
clever: so what I meant is, that script sits directly at $result/init of that .toplevel nix-build
<clever>
yeah
<clever>
"${config.system.build.toplevel}/init" will then be the absolute path of that script
<nh2>
I was wonderig whether that suggests that the kernel can boot it from /, or not
<clever>
it would be in /nix/store/foo/init
<clever>
so you would have to init=/nix/store/foo/init in your kernel config
<clever>
and update that config after every nixos-rebuild!
<nh2>
OK, so `.toplevel` could not just be `cp -r`d on the root fs if no `init=/init` kernel arg was given, even if we had something that also copied /nix over (which .toplevel doesn't do)
<nh2>
clever: but then `ln -fs $systemConfig/init /init` is incorrect, right? Perhaps `/init` works only on docker?
<clever>
that $systemConfig is refering to the $out, aka result, aka toplevel
<clever>
so its should be correct
<clever>
but you may want to change it to /bin/init as well
<clever>
i'm doing that in my mega-example
<nh2>
clever: yes, I meant the second positional argument `/init`, not the one with `$systemConfig/init`
<clever>
yeah
<clever>
too many inits!
<nh2>
clever: quite obscenely large my nginx-only tarball with its 842 MB
<clever>
my image with nothing at all (base nixos) is 997mb in ext4 form!
<nh2>
clever: a lot of it seems to be locales in a big variety of languages, e.g. gtk+3 has 11 MB object files and 26 MB locales
<clever>
line 11 will mount whatever device has NIXOS_ROOT on it, as / (but its only really there to make systemd happy, so it wont try to remount crap)
<nh2>
clever: my original question was rather whether I can strip away the unneeded locales from all the packages though, ideally while not forsaking the binary cache
<colemickens>
I guess nixos-unstable updated, maybe it's in now.
<nh2>
I'm quite certainly on something older than that
jtojnar has joined #nixos-chat
iqubic has joined #nixos-chat
iqubic has quit [Client Quit]
iqubic has joined #nixos-chat
<nh2>
clever: this Chromebook is successfully running NixOS now!
<clever>
nh2: yay!
<clever>
nh2: now to document what you had to do, and try to reproduce it from factory defaults!
<nh2>
clever: can't log in though. I tried `users.users.root.initialPassword = "";` but it doesn't accept the empty password, says it's wrong
<clever>
nh2: initialPassword only works on the first boot
<nh2>
clever: but I'm on the first bot
<nh2>
boot
<clever>
nh2: did you delet shadow and passwd?
<clever>
any previous attempts make it "not first"
<nh2>
clever: I untar'd the tarball onto the root partition
<nh2>
clever: regarding documentation, right now I'm creating an SD card, so I want to turn this into something that can just create a whole SD with the partitions that Chromebooks expect, so it can be directly plugged into any Chromebook and boot and use NixOS from the SD card (the Chromebooks will boot straight from USB and SD plugged in in dev mode)
<clever>
nh2: ah
<nh2>
when I'm done with that, I want to install it on the SSD (but just `rsync`ing it over from the SD card will be enough for that)
<clever>
by omiting the start position, it lays them out in the order i listed them, one after another
<samueldr>
cgpt might have uses outside chromium; it has built-in handling to make holes, useful e.g. for allwinner or rockchip boards with hardcoded locations for bootloader things :)
<samueldr>
(iirc)
<clever>
samueldr: i would just make a bios boot partition at the right offset
<clever>
samueldr: it handles basically the same duty on x86
<samueldr>
clever: the offset is within the GPT
<clever>
samueldr: why!? lol
<samueldr>
clever: which is why it needs the hole
<samueldr>
clever: because of bad "engineering" :)
<samueldr>
otherwise yes, bios boot partition for those
<clever>
samueldr: is it a hole in the gpt, or just a shorter gpt table?
<samueldr>
I'd need to re-read about it
<nh2>
samueldr: thanks
<samueldr>
nh2: though it's a starting point, it's for the arm boards... but AFAICT depthcharge seems to boot that mostly the same way?
<clever>
wikipedia says gpt extends from LBA 0 to LBA 33, and has 128 entries
<clever>
and last time i used an allwinner, it was at 8kb, almost smack in the middle!
<samueldr>
nh2: I guess that that zero'd file is either arm specific, or it's also for x86_64 depthcharge and a compatibility thing with your bootstub thing
<clever>
"The UEFI specification stipulates that a minimum of 16,384 bytes, regardless of sector size, are allocated for the Partition Entry Array.[4] Each entry as the size of 128 bytes. Thus, on a disk with 512-byte sectors, sector number 34 is the first usable sector on the disk.
<clever>
"
<clever>
samueldr: oh, "and the GPT header has a pointer to the partition table (Partition Entry Array), typically at LBA 2."
<clever>
so, you would need to make the main list start after the SPL+Uboot
<clever>
and that would require knowledge of how big that will be
<clever>
and then your bios-boot is before the gpt tables!!
<nh2>
samueldr: the ChromiumOS kernel package emits this `bootstub.efi`. Do you know if a normal NixOS kernel also builds it?
<samueldr>
clever: it's not cgpt, it's gptfidks which has the feature
<samueldr>
nh2: sorry :/ out of my knowledge realm
<samueldr>
I just remembered when seeing the page you linked how thefloweringash has that depthcharge setup
<samueldr>
clever: yeah, I think I remember where I saw that
<clever>
,locate gptfdisk
<{^_^}>
Couldn't find in any packages
<nh2>
my root login still doesn't work, even with `users.users.root.password = "asdfasfd";`
<nh2>
clever: OK, password didn't work because I had to wipe /etc/shadow indeed
<nh2>
now empty password for root works
<nh2>
clever: have to sleep, thanks a lot so far! Next comes doing the kernel, either with the partition or with a kexec first
<nh2>
samueldr: thanks to you as well!
<clever>
nh2: yep
tdeo has quit [Quit: Quit]
tdeo has joined #nixos-chat
thePirateKing has joined #nixos-chat
<MichaelRaskin>
infinisil: pie_: in lci you can define S/K/I and use it as a REPL for SKI.
endformationage has quit [Quit: WeeChat 2.4]
drakonis has joined #nixos-chat
drakonis_ has quit [Ping timeout: 268 seconds]
diamondb has joined #nixos-chat
diamondb has quit [Remote host closed the connection]
hedning_ has joined #nixos-chat
thePirateKing has quit [Remote host closed the connection]
__monty__ has joined #nixos-chat
<sphalerite>
jD91mZM2: thanks for the xidlehook fix! Backported it to 19.03 :)
<joepie91>
oooo
<joepie91>
xidlehook looks nice
<joepie91>
jD91mZM2: +100 for the great documentation for xidlehook, especially the "why is this better than _____" section and the caveats / special cases like exported variables and socat example :)
pie_ has joined #nixos-chat
hedning_ has quit [Quit: hedning_]
pie_ has quit [Ping timeout: 258 seconds]
hedning_ has joined #nixos-chat
hedning_ has quit [Client Quit]
__monty__ has quit [Quit: leaving]
pie_ has joined #nixos-chat
jasongrossman has quit [Remote host closed the connection]
jtojnar has quit [Remote host closed the connection]
<jD91mZM2>
joepie91: Thanks for the feedback :)
<gchristensen>
I wonder what a browser experience would be like if by-default, every website was loaded in its own "container" like firefox does
<gchristensen>
like firefox's container plugin*
jasongrossman has joined #nixos-chat
<joepie91>
gchristensen: share buttons would break
<gchristensen>
great!
<pie_>
i need to try that again, it had some UI annoyances last i used it
<gchristensen>
I have a container for basically every common website already, I wish I didn't have to actively set one up
<MichaelRaskin>
Actually, not much changes, I think
<MichaelRaskin>
Source: when I do use firefox, it is single-tab container-isolated single-use-profile windows
<gchristensen>
sounds nice
<pie_>
hm
<andi->
wasnt there a firefox plugin that ran each tab in a dedicated container without setup?
<andi->
elimantes any kind of state but that might be what you are after
<gchristensen>
oh?
<sphalerite>
YES
<sphalerite>
ELIMINATE ALL THE STATE
<andi->
isn't it also elimate all the stateS ? ;-)
<andi->
might be the wrong channel for that tho..
<MichaelRaskin>
Even if you eliminate the state, in the modern world some new state arises there…
<MichaelRaskin>
Applies to both cases, actually
<jD91mZM2>
In #emacs, I hear the opposite... They say you shouldn't restart emacs because it's like a lisp state machine
<gchristensen>
assuming it also works with named containers and "always open in this container", it looks great
<andi->
there was some rules you could configure IIRC. Never actually invested the time to set it up..
jtojnar has joined #nixos-chat
<andi->
some day I'll mod my kinesis2 to have a trackball/trackpoint/some kind of mouse built-in.. Forgot my external mouse at home.. stuck without one for a few days
<MichaelRaskin>
keynav!
<pie_>
it would be great to have a nipple instead of a spacebar with two thumbs
<andi->
doesn't work with wayland I guess.. like all the input simulations (xdotool, …)
<pie_>
well ok split keyboards have two separate keys for the two separate thumbs
<andi->
my main frustration regarding a missing mouse is the failing keyboard shortcuts in firefox that cause me to reach for the trackpoint every few minutes..
jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-chat
hedning_ has quit [Quit: hedning_]
jtojnar has quit [Remote host closed the connection]
__monty__ has joined #nixos-chat
jtojnar has joined #nixos-chat
drakonis_ has joined #nixos-chat
drakonis has quit [Ping timeout: 252 seconds]
Myhlamaeus has quit [Ping timeout: 252 seconds]
jtojnar has quit [Remote host closed the connection]
das_j has joined #nixos-chat
thePirateKing has joined #nixos-chat
shoky_ has joined #nixos-chat
<nh2>
clever samueldr: I've now packaged the software that creates bootstub.efi, and that works (I can use it instead of the bootstub.efi that the ChromiumOS source build gave me
<nh2>
I've also written a derivation that creates the signed kernel. But that doesn't work yet: The chromebook immediately reboots
<nh2>
perhaps some config settings are missing in the NixOS kernel that the Chromebook needs
<nh2>
I also tried kexec'ing it; I could load it, but `kexec -e` to start the new kernel immediately hung the device
Myhlamaeus has joined #nixos-chat
das_j has quit [Ping timeout: 268 seconds]
das_j has joined #nixos-chat
<eyJhb>
There one was something called something like "code wars", where there were two teams of three battling to code X project using HTML, CSS and JS, and the better design with the most criteria fullfilled won. But I cannot find it?! Anybody got a clue?
<__monty__>
Yes, this was a dream.
drakonis has joined #nixos-chat
<eyJhb>
__monty__:?
<__monty__>
I'm joking that you dreamed this. I know of nothing like this though.
<clever>
nh2: sort of need serial to debug low-level things like that
<eyJhb>
__monty__ would be a weird dream, but I cannot find a single trace of it?! And it really annoys me
<eyJhb>
Maybe I am going crazy ;)
endformationage has joined #nixos-chat
thePirateKing has quit [Quit: Leaving]
Drakonis__ has joined #nixos-chat
__monty__ has quit [Quit: leaving]
Drakonis__ has quit [Read error: Connection reset by peer]
<pie_>
tfw im constructing commands with nix and thinking this is going to break horribly at some point
<nh2>
clever samueldr: but I do have a problem: It's only working with the upstream Chromebook kernel config. NixOS's kernel config doesn't boot. I must bisect somehow which options make it work. Do you have any idea how I could do that the fastest?
<samueldr>
no :(
<samueldr>
kernel config only or kernel source?
<nh2>
config only
<samueldr>
if kernel source, go to the mainline equivalent
<samueldr>
ah
<samueldr>
then definitely no
<samueldr>
I'm currently battling with kernel config fun with the pinephone :)
<nh2>
maybe I should first set myself up so I can use incremental builds using `make` instead doing a full nix build on every config change (which takes 7 minutes each time)
<clever>
nh2: maybe start by taking a diff of the kernel configs, let me find something of use
<samueldr>
kernel config diff should probably pass through make oldconfig
<samueldr>
(so they've been "remangled" by the same kernel source tree)
<clever>
using the above stackoverflow, you can extract the nixos config from a built kernel
<clever>
so you can see whatever mangling nixos has done to things
<clever>
that file is also in /proc/config.gz, but only if you can boot it
<samueldr>
(and if the option is enabled)
<clever>
oh right, x86, so you can just boot it on any qemu guest
<samueldr>
fun bit, many (most?, all?) android kernels don't have /proc/config.gz :)
<clever>
the chromeos config file works on the nixos kernel source, and he is already adding custom entries to it
<clever>
so it only takes 1 more entry to have config.gz on both
<clever>
then its just a matter of running a diff and reviewing
<samueldr>
yeah, most likely should work fine then
<nh2>
clever: `extract-ikconfig` works, so I can diff
<nh2>
(I had enabled the option already, but I cannot boot it)
<samueldr>
fun thing I learned today, (outside of the nixos kernel options system) CONFIG_whatever=n apparently doesn't disable options with kernel config options :/
<nh2>
samueldr: what _does_ it do then?
<samueldr>
I'm not sure how it handles it, but it ended up being like =y AFAICT
<samueldr>
I spent a good while changing stuff, seeing nothing different... until it dawned on me that one of the option REALLY should have changed something
<samueldr>
changed all =n$ to be commented out, then it really changed things
<pie_>
wha..? /me files "kernel config options are not necessarily intuitive" in the back of his mind
<nh2>
samueldr: I got tricked by me setting stuff to `=y` and then being disabled on-the-fly by ChromiumOS's kernel build system