orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
Acou_Bass has quit [Ping timeout: 240 seconds]
Sonarpulse has joined #nixos-aarch64
SagnikS has joined #nixos-aarch64
<SagnikS> I'm getting a daemon not started error
<SagnikS> And the command it tells to use is
<SagnikS> Teamviewer --daemon start
<SagnikS> But when I run it, I get the error that the service first exist
<SagnikS> *don't e
<SagnikS> *doesn't
<SagnikS> Oh god this autocorrect
<gchristensen> on aarch64?
<SagnikS> Um?
<SagnikS> x86
<gchristensen> this channel is specifically for aarch64 :)
<gchristensen> you probably want #nixos
<SagnikS> Welp
<SagnikS> Just realised
<gchristensen> ^.^ no worries
<SagnikS> :P
SagnikS has quit [Quit: Page closed]
orivej has quit [Ping timeout: 260 seconds]
<gchristensen> Dezgeg: it sounds like the issues with the corrupted squashfs filesystem in the netboot is in the kernel somewhere, after having verified iPXE fetches the contents porperl
<gchristensen> Dezgeg: it sounds like the issues with the corrupted squashfs filesystem in the netboot is in the kernel somewhere, after having verified iPXE fetches the contents properly
<Dezgeg> huh
<gchristensen> Dezgeg: Scott from Packet theorizes a kernel module is writing a status bit somewhere it shouldn't
<Dezgeg> it's always possible of course
<Dezgeg> I guess you could try a CONFIG_KASAN=y kernel to see if someone is corrupting memory
<gchristensen> ooohh
orivej has joined #nixos-aarch64
<gchristensen> { linux_4_15 = pkgs.linux_4_15.override {
<gchristensen> extraConfig =
<gchristensen> ''
<gchristensen> KASAN y
<gchristensen> '';
<gchristensen> lgty?
<gchristensen> oh .15 isn't maintained
<Dezgeg> yeah
<Dezgeg> looks good
<Dezgeg> maybe slub_debug=FZP to kernelParams as well
<gchristensen> gerat
<gchristensen> doing a build now
Acou_Bass has joined #nixos-aarch64
elvishjerricco has joined #nixos-aarch64
<elvishjerricco> samueldr: Didn't know this channel existed :)
<samueldr> most android devices have a common way to boot their kernel
<samueldr> my knowledge isn't entirely accurate
<samueldr> but good enough for the big picture
<samueldr> and even those that are different mostly work the same, but with different software
<elvishjerricco> Ah, so you don't just throw u-boot at it?
<samueldr> I don't know of any android device that uses u-boot stock
<samueldr> most will have a bootloader, I think it's LK, which will do many things
<samueldr> one of those is fastboot
<samueldr> fastboot is a kind of "flashing" mode for the device
<samueldr> one of the things you can do is flash a partition, another is directly booting a kernel + initrd
timokau[m] has joined #nixos-aarch64
<samueldr> the biggest issue it seems, and that's a bit I don't know for sure
<samueldr> is that it seems that re-partitionning a device may cause it to be unrecoverable if done wrong
<elvishjerricco> yessh
<samueldr> maybe not all devices, but some, going from the reading I did for postmarketos
<elvishjerricco> yeesh*
<samueldr> so postmarketos is built around the assumption that partitions are untouched
<samueldr> in that setup, the kernel is imaged directly to a partition
<samueldr> instead of being a file living on a partition
<elvishjerricco> Huh
<samueldr> though, nothing would stop us from chainloading another kernel using kexec
<samueldr> and implementing a kind of bootloader
<elvishjerricco> Yea I wonder if you could just put u-boot in that position.
<samueldr> (which could be useful in other situations e.g. chromebook devices with depthcharge)
<samueldr> it's possible
<samueldr> there is an EFI implementation
<samueldr> though finding good information for porting is hard as they are currently rewriting how it builds and works seemingly
<samueldr> and though it looks like an android app, it's a full EFI environment
<elvishjerricco> whoa that's sweet
<samueldr> THOUGH, however it boots, there are many things that will be exactly the same in the end
<elvishjerricco> seems like android handle booting much differently than the typical x86 desktop
<samueldr> luckily and unluckily
<samueldr> even differently than many ARM boards
<elvishjerricco> Doesn't seem like a major obstacle though; just another pain point along the road
<samueldr> it's something to keep in mind when implementing stuff
<samueldr> booting will have to account for this
<samueldr> oh, another issue WILL be drivers, especially graphics
<elvishjerricco> samueldr: I was just going to start out trying to boot on a raspberry pi. You think that would be good enough just to get the kernel and main OS going?
<elvishjerricco> yea I'm not looking forward to the driver part
<samueldr> if you haven't checked much into alternative OS for cellphones, libhybris is probably the only way to make it work
<elvishjerricco> > Hybris is a solution that commits hybris, by allowing us to use bionic-based HW adaptations in glibc systems
<elvishjerricco> Not sure I understand that, really.
<elvishjerricco> We can probably make nixpkgs use bionic
<samueldr> heh
<samueldr> there's too much software incompatible with bionic
<samueldr> that libc is basically built for android and not much more
<samueldr> (iirc)
nocent has joined #nixos-aarch64
<samueldr> what libhybris allows is using a library built for bionic with glibc AFAIUI
<elvishjerricco> samueldr: Hm, have any examples of important software we'd be missing out on?
<samueldr> any web browser?
<samueldr> I'm really not sure what's incompatible with bionic
<samueldr> in fact, I'm assuming it would be
<samueldr> (and well, anything actually dependent on glibc specific stuff)
<elvishjerricco> Oh, personally, I was planning on using existing android app APKs for most real user apps. Haven't researched whether that's reasonable
<samueldr> that, I don't know
<samueldr> so more about re-packaging android to be built with nixos than porting nixos to cellphones?
<elvishjerricco> Yea I wouldn't expect to even be able to build anything without X, which would be a horrible UI manager for a phone
<elvishjerricco> Basically I want to be able to NixOS-style declare my otherwise ordinary android phone, and maybe build other non-android software whenever I can manage it
<samueldr> that would be cool, don't know anything about android's architecture though
<elvishjerricco> samueldr: Regardless, getting the kernel building and booting is independent of the libc / GUI framework :)
<samueldr> yes
<elvishjerricco> samueldr: Keep me updated if you take any steps in this area. I'll try and push my normal linux build somewhere today.
<samueldr> if I understand correctly, you managed to do a cross build for aarch64 of the nixos sd image?
<elvishjerricco> samueldr: Yea
<elvishjerricco> boots in qemu. Just ordered an rpi to test it on hardware
<samueldr> had to do anything special?
<elvishjerricco> samueldr: After shlevy's work on cross compiling to riscv, not especially. Mostly just had to tweak a few broken things here and there.
<elvishjerricco> samueldr: Does glibc work on android?
<samueldr> I don't know
<elvishjerricco> I was assuming it didn't, byt that hybris thing makes me think otherwise
<elvishjerricco> If glibc does work on android, then Nix's separation of libc might actually make hybris completely unnecessary. Any software that needs to be built with bionic can just use bionic, since the libc path is hard coded in the executable.