<samueldr>
coming soon a "follow-up", but independent PR, where I'm adding useful kernel modules to the initrd modules for SBCs and family
h0m1 has quit [Ping timeout: 260 seconds]
h0m1 has joined #nixos-aarch64
<colemickens>
what a mess, we should make a new bootloader
* colemickens
kids, but also looks at linux/petitboot
<samueldr>
colemickens: hm?
<samueldr>
I don't understand
<colemickens>
it was sort of a n+1 joke, but then I switched gear and was thinking linuxboot+kexec seemed nice. bit of random thoughts that slipped out :/
<samueldr>
right, I wondered how it was related
<samueldr>
I'm finally doing what has been simmering in my mind for now more than three years
<samueldr>
fixing the "story" about UEFI and AArch64 on NixOS
<samueldr>
I want the happy path on "SBCs for general use" to be the same as on x86_64
<samueldr>
I've done this installation on an allwinner platform, raspberry pi, amlogic
<samueldr>
pinebook pro has the display issue in kernel that stops me from "just" doing it
<samueldr>
and right now it's great, grub mostly just works
<Irenes>
ooh, exciting
<samueldr>
though right now I'm in a bad situation, where I need to slow that down to continue working on Mobile NixOS stuff :/
<samueldr>
it's taking just a bit longer than expected
siraben has quit [Ping timeout: 245 seconds]
siraben has joined #nixos-aarch64
<Irenes>
I really admire how much work you put into all this though
<Irenes>
it's been years since I've been able to focus on projects I wasn't being paid for, sigh
<Irenes>
(trauma sucks)
<Irenes>
I'm still working on the project we talked about a year ago. just... very slowly.
<samueldr>
I don't remember what it was about if it was with me that you talked about it
<Irenes>
secure boot with user-controlled keys on sunxi SoCs
<samueldr>
ah, right
<samueldr>
and the main reason I guess, here, is that I don't have a job sapping my work-spoons away
<Irenes>
sure, makes sense
globin_ has joined #nixos-aarch64
globin has quit [Ping timeout: 240 seconds]
<Ke>
one soc per try?
<Ke>
selectable read only boot source <3
<samueldr>
Ke: "one soc per try"?
<samueldr>
I don't get what "selectable read only boot source <3" is about too, though :/
<Ke>
I mean fusing in keys can only be done once
<Ke>
selectable read only is mostly ro jumper on spi-nor
<Ke>
like chromebooks have
<Irenes>
yes
<Ke>
but can be any number of implementations that prevent running OS from updating the fw
<Irenes>
one SoC per try
<Irenes>
I'm trying to get my tooling to reasonbly good confidence before I burn the efuses
<samueldr>
oh, yeah, now I see it
<samueldr>
I thought it was about how I tried different SoCs when working on the UEFI thing
<Irenes>
I want to be able to do what chromebooks do, but beholden to me as an end user not to a hegemonic megacorp that I have personal history with
<samueldr>
that's nice indeed
<Irenes>
yeah. it was pointed out to me that it's in many ways the opposite of why many people like the FOSS ecosystem, and I get that, but I think people who have real security needs will appreciate it
<Irenes>
it's a change in thinking
<samueldr>
I don't see how it's the opposite of FOSS
<Ke>
jnettleton mentioned that at least honeycomb should be able to trust zone isolate the spi-nor from the OS, though if you could break into trust zone that would still break
<Irenes>
because you can't just try out a zillion different distros on the device, once you've done this to it
<samueldr>
leaving the end-user in control, is probably my first goal
<Irenes>
it'll have to be very carefully integrated with any distro that wants to support it
<samueldr>
it's not something like a key that you can sign anything with later on?
<DigitalKiwi>
Irenes: are you Irenes (many)?
<Irenes>
it is a key that you can use for multiple things
<Irenes>
DigitalKiwi: yes hi :)
<samueldr>
(I don't know the details about sunxi's security)
<DigitalKiwi>
ohhi
* DigitalKiwi
ArchKiwi
<Irenes>
yeah the sunxi part is really just the first stage
<Irenes>
good to see you here!
<Irenes>
you have to have a chain of trust all the way to the end user OS
<samueldr>
so I don't really see how that prevents you from using other distros?
<samueldr>
ah
<samueldr>
*that*, yes
<Irenes>
it doesn't do you much good to know that the bootloader itself is verified if the bootloader then doesn't make it its business to verify the thing it's loading
<samueldr>
but as the end-user, in control of that, it's not counter to FOSS?
<Irenes>
I don't think it's counter to FOSS, or I wouldn't be doing it
<Irenes>
it's counter to expectations though
<samueldr>
sure, but as the end-user you could sign a u-boot to boot anything
<Irenes>
yeah
<samueldr>
I meant, the way you told that some say it's counter to it
<Irenes>
that'st rue I guess
<Irenes>
*true
<Irenes>
you can always un-restrict your device by signing a bootloader that doesn't verify the later stages
<Irenes>
well, good :)
<samueldr>
though if you're selling a product to the end-user with such security, then it's... yuck!
<samueldr>
because we all know most of the time it's actually for DRM
<Irenes>
yes, agreed
<Ke>
well nowadays google seems to be happy with a tpmish chip and measured boot
<Ke>
se secure boot for DRM is no longer being pushed there
<samueldr>
yeah, the fundamental reason, more than actual uses
<Ke>
tpm chip only needs to control the very first step and it can let go
<samueldr>
I'm curious what the upcoming qualcomm hardware will look like as an end-user
<samueldr>
chromeos hardware*
<Ke>
the remote attestation chip could even power off, if it was not needed
<Ke>
I could see the appeal of secure boot on nixos, since many of us already have excellent separation of "text" (/nix/store) and "data" (tmpfs rootfs)
<samueldr>
there's daniel//rf[m] who worked on it a bit
<Irenes>
yeah for my own needs I definitely plan to be using nixos :)
<Ke>
store could just be put on a dm-verity and other parts not on disk
<samueldr>
oh no, wrong subject
<samueldr>
that was boot counting
<samueldr>
#53901 is what I had in mind
<Ke>
though realistically most parts still have ample writable data that gets accessed by the kernel
<samueldr>
though I think daniel//rf[m] *does* have plans for dm-verity stuff
<Irenes>
there's also the question of, like... supposing you manage to make the nix store read-only
<Irenes>
how do you upgrade it
<Ke>
like on-disk format filesystem attack, which don't seem to be talked about much, but fairly sure there is an attack surface there
<samueldr>
Irenes: produce A/B read-only images / snapshots
<Irenes>
yeah, that's my best thought right now
<samueldr>
I was thinking about it a bit, but not for "security" reasons
<Irenes>
I guess if you want to use the machine as a build host despite /nix being read-only, you can tell it to use a store somewhere else for the builds it does
<samueldr>
if someone was to build a product on top of NixOS + mobile boot toolchains, how would you ship updates to end-users?
<Ke>
Irenes: whatever system, where you can create a bunch of files with nixos-install
<samueldr>
they probably won't nixos-rebuild!
<Irenes>
signed rootfs images
<samueldr>
yeah, something like that, make images, nix store being just an artifact of the build process
<Irenes>
yeah
<Irenes>
I thought a bunch about whether it would make any sense to verify individual things in the store, but I don't think it does, I think verifying the whole filesystem is a lot less work
<samueldr>
that was my thoughts if I was to "pitch" it for product uses
<samueldr>
could it make sense to overlay multiple snapshots/images too?
<Irenes>
not something I'd personally want because it's attack surface
<Irenes>
that's what Android does though
<Ke>
I do eg. have all my nixos systems installed on all my systems
<Ke>
all being only 2 now
<samueldr>
so let's say you have your upgraded "B" snapshot of the nix store, have it mounted/overlaid by the same processes used to mount it initially
<Ke>
I symlink the system to /etc
<Ke>
if I want to restore one of my systems I can just nixos-install on an other system
<samueldr>
then you could activate it... but I'm not thinking about overlaying a writable store
<samueldr>
that wouldn't bring much good for security
<Irenes>
then of course you want to deal with rollback attacks on all of this, but for systems where it's safe to assume you have network access, you can run a roughtime client in stage1 or something
<Irenes>
and use that to expire too-old images
<Irenes>
as long as you're okay with your computer failing closed
<Irenes>
and if you aren't, you probably shouldn't be doing this
<samueldr>
right, rollbacks are annoying
<Ke>
if you have a custom build you are protected from rollback attacks by obscurity
<samueldr>
I wonder if that's the reason qualcomm phones' hwclock is immutable from first power on [until power loss]
<samueldr>
power loss being actually drained battery
<Irenes>
seems entirely possible
<Ke>
of course if you were to install nixos signing keys or something, sure
<Irenes>
time is an important input into lots of security stuff these days
<Irenes>
Ke: yeah I intend to set up a custom splash screen and so on ;)
<Irenes>
just to make my build that much more distinctive
<samueldr>
surprised me to see that the watch hardware from qualcomm had mutable hwclocks
<Irenes>
but that's not the hard research part, that's the fun part, so it comes after the essentials work
<Ke>
well you also need to log somewhere the last successful boot to prevent rollback?
<Ke>
unless you make the hw brick after a while?
<Irenes>
that's a nice thought but it's not easy to do
<Ke>
well I guess there could be a warning about old fw
<Irenes>
the efuses don't have that much space
<samueldr>
there's the "nintendo" way
<Irenes>
oh yeah lol
<Ke>
Some systems had space for this
<samueldr>
burn a fuse only when you know there's a known exploit
<Irenes>
I'm aware of the Nintendo trick
<Ke>
maybe on eMMC special region?
<Irenes>
that does seem reasonable
<samueldr>
yeah, rpmb is something I still need to read about
<Irenes>
hm... I don't know enough about eMMC special regions, my assumption would be that an attacker could re-write it
<Irenes>
is that not the case?
<samueldr>
and that's something I *believe* often is protected into trustzone on ARM
<samueldr>
but yeah, good question, that's something I would like to learn more about
<Ke>
Irenes: eMMC has many irreversible settings like the enhanced partition
<samueldr>
it's called "replay protected memory block"
<samueldr>
which I don't know what it actually means :)
<Ke>
me neither
<Ke>
I knew the acronym also
<Ke>
enhanced partition we have played with at work
<samueldr>
seems to imply involvement with a TEE (trustzone)
<samueldr>
similarly, the boot partitions in eMMCs, it'd be nice to know is SoCs could use it to treat it as a dedicated initial boot firmware storage
<Ke>
why would you specifically want this?
<samueldr>
not thinking about security, but robustness
<samueldr>
having a
<samueldr>
oops
<Irenes>
interesting
<Irenes>
the acronym makes it sound relevant for sure :)
<samueldr>
having a `cfdisk -z /dev/mmcblk0` blow the boot firmware away is rude!
<Irenes>
that would be nice!
<samueldr>
or how the fedora installer *absolutely* wants to obliterate the partition table
<Ke>
hmm I thought bootloaders use fixed locations?
<samueldr>
I uh... sinned this week-end
<Irenes>
I've seen stuff like that with Windows, heh
<Ke>
not partitions
<samueldr>
exactly, if you make a partition on top of the fixed location, it'll break it!
<Irenes>
like laptops with nvme disks sometimes have a uh "partition" at the nvme layer
<Irenes>
so it appears to the kernel like two separate disks
<samueldr>
Irenes: LUN
<samueldr>
available on eMMCs too
<Irenes>
ah! yeah
<samueldr>
e.g. oneplus3 has many LUNs
<samueldr>
but not all phones do this
<Ke>
samueldr: but hw partition does not protect the software partitions in any way afaik?
<samueldr>
you're right
<samueldr>
but if the initial boot firmware is on a distinct block device
<samueldr>
it's more robust against accidental overwrites
<Irenes>
yeah the way Windows uses it is not for the regular boot process but for the recovery process
<samueldr>
if you want to repartition/format/reinstall your SBC, no need to worry
<Ke>
well at least UFS can do a completely separate device
<samueldr>
it's all about separation of concern
<Ke>
but afaik overwriting eMMC main will also overwrite the hw partitions
<samueldr>
the way your run-of-the-mill SBC will put what amounts to the "bios" of the computer on the same storage medium as the operating system is terrible
<Ke>
ie. hw partitions are just pointers to the main device
<Irenes>
I prefer it over the firmware being somewhere totally inaccessible to the user except through proprietary tools
<Irenes>
yeah I clicked through when you linked that earlier
<Irenes>
very exciting!
<samueldr>
>> This article or section needs expansion.
<samueldr>
this is the exciting part
<Irenes>
I'm sure
<samueldr>
but as a teaser... I'm working on a "abstracting" the concepts in a common manner for all SBCs/SoCs with docs backing it up
<samueldr>
and it's hell
<Ke>
well in general I think it's only terrible, because there is no easy to access recovery, but there are typically proprietary recovery tools
<samueldr>
also why I sinned and installed Fedora this week-end
<samueldr>
(testing generic UEFI with not-nixos)
<Ke>
I would rather limit the writable parts in a system for security
<Ke>
non-volatile
<samueldr>
oh, I'm not talking about limiting writes here, mainly about separating concerns
<Irenes>
when you say abstracting the concepts
orivej has joined #nixos-aarch64
<samueldr>
>> Getting an Initial Boot Firmware
<Irenes>
you mean stuff like SoCs looking at particular fixed offsets onto the drive
<Irenes>
and partition table hackery to make space for it?
<elvishjerricco>
TIL u-boot implements UEFI. That's interesting.
<samueldr>
I think all... literally ALL ARM distros are doing it wrong
<samueldr>
including NixOS (for now)
<Irenes>
I would love to hear your vision of the end state
<elvishjerricco>
samueldr: Define "wrong"
<samueldr>
>> not correct or true; incorrect.
<samueldr>
heh
<Ke>
Yeeaaahh!!
<samueldr>
generally speaking, what's the main issue someone has when approaching with an SBC?
<elvishjerricco>
i've been got :P
<Ke>
samueldr: things not being upstreamed and having to look for proper sources on github
<Ke>
imo
<Ke>
fragmentation into downstream projects
<samueldr>
Ke: almost touching about it, with fragmentation
<samueldr>
but generally it's "I turned it on and it does nothing"
<samueldr>
because the "bios" for SBCs is often on the same media as the operating system
<samueldr>
so distros generally will ship as many images as they support SBCs!
<samueldr>
which is totally absurd!
<Irenes>
yeah I've thus far never successfully brought up an SBC without resorting to a serial console to debug what's going wrong
<samueldr>
NixOS does it a bit better by shipping an image where you insert your own boot firmware into
<Irenes>
that needs to be streamlined for the general public
<samueldr>
but still, the boot firmware shouldn't really be managed by the distribution imo
<samueldr>
ideall the vendors, like libre.computer do, would ship a proper mainline-based U-Boot
<elvishjerricco>
That makes sense to me
<samueldr>
ideally*
<samueldr>
and ideally in a dedicated storage
<samueldr>
like your laptop (if it's not a windows on arm qualcomm laptop)
<samueldr>
you can `dd if=/dev/zero of=/dev/storagenode`
<samueldr>
and it still boots to something
<samueldr>
e.g. the initial boot firmware's interface
<Ke>
:asterisk:) blkdiscard
<samueldr>
Ke: doing it wrong is more funlier
<Irenes>
hmm
<Irenes>
yeah I see your point
<elvishjerricco>
I guess it's kinda cool to have the boot firmware on a detachable storage device since you can just swap it out whenever you want to switch between a few quickly. But like... who the hell does that?
<samueldr>
and why is it you don't install your SBC's distro by just flashing the UEFI iso to USB?
<Irenes>
ooh, indeed
<samueldr>
that's what I've been doing these past few days
<samueldr>
installing NixOS from a unique iso on USB
<samueldr>
tested successfully on amlogic, allwinner, raspberry pi boot chains
<samueldr>
sure, mainline support is still an issue
<samueldr>
but that's something we can assume to be solvable
<elvishjerricco>
Getting a consistent boot mechanism is wonderful though
<samueldr>
and it's not like it's harder to produce a customized kernel iso than a customized kernel sd image
<Irenes>
wait, this is after you've installed a u-boot somewhere, right?
<samueldr>
Irenes: yes
<Irenes>
right, okay
<Irenes>
I didn't think they could find it on the USB device
<samueldr>
my usb stick has no concept of "board", it's just the same as on x86_64
<Irenes>
that sounds great
<samueldr>
it's literally the same derivation, but for aarch64
<elvishjerricco>
Whoa
<elvishjerricco>
that's awesome
<Ke>
fwiw many distros ship EFI installer?
<samueldr>
fedora does
<Ke>
or like I don't get what you mean here
<samueldr>
theirs work*
<samueldr>
* (will blow away the partition table if you're not careful, and thus probably your firmware )
<Ke>
I believe I installed debian on mcbin a long time ago
<samueldr>
yeah
<Ke>
from an installer
<samueldr>
great!
<samueldr>
was it an installer for mcbin, or generic?
<samueldr>
because yeah
<samueldr>
distros do it
<samueldr>
but it's not the usual way you install to an SBC
<samueldr>
even for those that do
<samueldr>
like SUSE
<samueldr>
SUSE produces an aarch64 UEFI iso
<samueldr>
but still assumes strongly you'll use a per-board image
<Ke>
well it was a generic installer, but had patches for mcbin
<samueldr>
UEFI?
<samueldr>
but yeah, I'm not saying it's new or anything
<Ke>
afaik the changes were upstreamed and you can now install debian from unpatched installer
<samueldr>
nice
<elvishjerricco>
why didn't uefi become the standard convention on arm like it did x86_64?
<samueldr>
it is the standard convention
<samueldr>
SBCs are non-standard
<elvishjerricco>
oh
<samueldr>
the mcbin is SBBR or SBSA compatible~ish IIRC
<samueldr>
which is UEFI
<elvishjerricco>
then s/arm/sbcs/ :P
<samueldr>
and that's why Ke was able to do that
<samueldr>
because vendors don't care!
<elvishjerricco>
oof
<samueldr>
there's EBBR that was written-up recently to help
<Irenes>
yeah SBCs are not consumer products
<Irenes>
which
<Irenes>
to me
<Irenes>
is exciting
<Irenes>
because it means the community gets to decide how to make them useful to consumers, you know?
<Irenes>
we have a blank slate
<samueldr>
#119974 has a few fixes for the iso, but nothing *required* :)
<Ke>
vendors probably have engineers who have experience with u-boot, I guess
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<edrex>
is anyone else here interested in outdoor (sunlight, durable, long battery life) writing/terminal devices? I have a hacked Kindle PW2 with an XFCE Alpine chroot and USB Y with external battery and wireless kb/mouse.. i need to put some time into building a housing for it.. But it's always confounding there aren't open hw epaper devices I can put something like NixOS on.
<gchristensen>
I amw
<edrex>
gchristensen: yay allies :)
<gchristensen>
do you have a picture of your setup? I'mhaving a hard time imagining it
<edrex>
mm, i can take one. The only hardware bits are a micro-usb Y adapter with a 2-cell 18650 batter taped to the back, and a logitech wireless keyboard/trackpad
<edrex>
would probably be better to use a low-profile lion pack but 18650s are what I have
<edrex>
also, a y adapter with one of those low-profile right-angle microusb ribbon connectors would be less fragile, so the cable can wrap around to the back.
<gchristensen>
gotcha
<gchristensen>
I guess a picture might get interesting once it had a housing? :)
<edrex>
the Paperwhite 4 has bluetooth, so that would be an option if you could manage to get one with an old FW or root via serial. but IDT anyone has done the work to get the right bt kernel modules/userspace built/loaded. I think the usespace could be from the chroot env. But it's so painful working with old vendor kernels etc
<edrex>
Yeah, a traditional clamshell is the obvious choice but I actually want to do some sort of tripod (probably just use my trekking pole as a monopod for now actually) and then the input device goes in your lap.
<edrex>
ergonomics :D
<gchristensen>
that sounds cool!
<edrex>
Yeah! rugged, long battery, ergo, and really sunlight optimized
<edrex>
anyway, sorry </ot> just thought I'd make the connection
<gchristensen>
I'm dying for something e-ink-ey
<gchristensen>
my front lawn is nice to sit in but too bright :)
<edrex>
Some people have also had success using ereaders as a remote display with VNC.
<edrex>
but that seems too flakey for me, didn't bother trying
<edrex>
It would be great if someone made an open hardware laptop screen replacement module. There is a driver board from eink that allows LVDS input, as a proof-of-concept: https://shopkits.eink.com/product/lvds-tcon-driving-kit/
<gchristensen>
wow!
<gchristensen>
$600 for the board is steep though :)
<edrex>
Ideally though, I just want a tablet I can put mainline linux on.
<edrex>
my pw2 was $20 shipped on ebay :)
<edrex>
idt there's any hope of getting mainline linux running on it
<edrex>
i wonder if there's a room on freenode or matrix for this kind of stuff..
AmandaC has joined #nixos-aarch64
rajivr has quit [Quit: Connection closed for inactivity]
AmandaC has quit [Remote host closed the connection]
AmandaC has joined #nixos-aarch64
justan0theruser has quit [Ping timeout: 245 seconds]
orivej has joined #nixos-aarch64
alpernebbi has quit [Quit: alpernebbi]
zupo has joined #nixos-aarch64
<flokli>
gchristensen: I recently got a dasung eink display
<flokli>
you can plug it into hdmi and usb (for light+touchscreen)
<flokli>
and effectively stash it in front of the normal laptop display
sciamp has joined #nixos-aarch64
<flokli>
works in very bright sunlight. beach-approved :-P
<gchristensen>
nice!!
<gchristensen>
which one?
<gchristensen>
aren't they 1 arm + 1leg?
<simpson>
...Am I misparsing, or is "1leg" like a DSP of some sort?
<gchristensen>
1 leg*
<simpson>
Oh, like "an arm and a leg", the idiom. Sorry, got it.
<gchristensen>
:)
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<edrex>
Spending some time getting back to where I was last summer with the kindle hack. Kinda like taking summer clothes out of storage :D
zupo has joined #nixos-aarch64
jumper149 has quit [Quit: WeeChat 3.1]
<edrex>
samueldr: i have a moto xt1644 (msm8952) for testing on. pmoswiki says it's mainlinable, cool
<samueldr>
snapdragon 615, the CPU is arm64 AFAICT
<samueldr>
617*
<samueldr>
probably a pin compatible
<edrex>
pin compatible?
<samueldr>
a replacement CPU that's faster than the previous one
<edrex>
oh, got it
<samueldr>
sometimes you see some conflicting information about the CPU because of that :)
<samueldr>
if I search msm8952 I find snapdragon 615 info
<samueldr>
mainline or not, it's sometimes worthwhile to package both the vendor kernel and mainline
<edrex>
am I reading the situation about right that packaging for user envs like phosh is needing a maintainer? you have your hands full working on the bootloader/kernel stuff yeah?
<samueldr>
kind of, it's more not really the concern of the project, and a general Nixpkgs problematic :)
<edrex>
(not volunteering, just trying to understand)
<samueldr>
but I do have a plasma mobile PR in progress (oops, side-tracked doing other things)
<samueldr>
and there's a phosh PR opened by other users
<edrex>
seems like there's a phosh branch that's pretty far along, was just reading
<samueldr>
it's probably both a hard task and an easy task :)
<samueldr>
but really Mobile NixOS doesn't care about the end-user software, it aims to abstract the hardware quirks and features as much as possible
<samueldr>
so you run stock Nixpkgs packages in the end
<edrex>
re: kernels, currently it's running a custom rom called arrowos with a custom version of the vendor kernel with some tweaks. Is it preferable to package the pristine vendor kernel?
<edrex>
it was my daily driver a few years ago..
<edrex>
it's a very compelling goal, to make phones not special snowflakes at the system level
<samueldr>
ideally pristine vendor or well-known fork, e.g. LineageOS
<samueldr>
well-known forks might be preferrable
<samueldr>
because they end up working out issues often
<samueldr>
as with other motorola phones, they ship a 32 bit OS
<samueldr>
it's still unknown whether it is going to be an issue with drivers and such
<samueldr>
but it is known that building for aarch64 works
<edrex>
yeah, the rom i have is 64bit kernel+os
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<samueldr>
neat
<samueldr>
edrex: just as a note if interest, download and keep backups of the "motorola blankflash" files for your phone
<samueldr>
probably won't be needed ever
<samueldr>
but that way if you ever eff it up real good, you should be able to recover it
justanotheruser has joined #nixos-aarch64
sciamp has quit [Quit: Konversation terminated!]
<edrex>
this is good advice :) I think I have that on a backup volume. It's on one of those arm 32 HC1s. everything is broken, or depends on something that's broken :D
zhaofeng1 has quit [Quit: Bridge terminating on SIGTERM]
<colemickens>
Is anyone using the community box as a hydra builder? it's still not working for me, and I still suspect nixUnstable.
<gchristensen>
what is the error you get?
<colemickens>
it often looks like the build succeeds and then fails on transfer back: [31;1merror:[0m unexpected end-of-file (log, raw, tail)
<colemickens>
uncaught exception building ‘/nix/store/7kyq05lyzyjpqkh7gv6f74ijkh8jbip6-source.drv’ on ‘colemickens@aarch64.nixos.community’: std::bad_alloc