<samueldr>
but, briefly said, it's based on preconfigured XFCE, with awesome as WM
<samueldr>
it's not an actual environment
wavirc22_ has joined #nixos-aarch64
<samueldr>
it's something I threw together rather quickly last year that's better than using the desktop environment
<samueldr>
trying to wrangle XFWM windows on a touch screen that's high DPI is... pretty much impossible :)
wavirc22 has quit [Ping timeout: 256 seconds]
zupo has joined #nixos-aarch64
v0|d` has joined #nixos-aarch64
v0|d has quit [Ping timeout: 265 seconds]
v0|d` has quit [Ping timeout: 265 seconds]
<samueldr>
Danct12[m]: anything more you wanted to know about that?
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
<lordcirth>
When I try to enable xserver on my PBP, it won't build; complains that the vmware driver can't be built. I tried to override videoDrivers to [ "vesa" ] but that doesn't detect the Mali GPU. I can't figure out which of these drivers I need?
<samueldr>
I'm trying to think of a way to count valid boots on android-based systems without A/B
<samueldr>
I have this fun idea, well two
<samueldr>
1) assuming we don't fill the boot partition, keep a couple bytes at the end to store a counter and maybe a signature
<samueldr>
(signature in the sense of a magic number)
<samueldr>
e.g. MNBOOTxx where xx would be uint32_t so it'd be 8 bytes
<samueldr>
or, assuming the boot image isn't checksummed and validated at boot, what if it was self-modifying the kernel command-line?
<samueldr>
the only issue with that is when boot has a kernel that boot just enough, but panics, it would still boot loop
<samueldr>
which... we could maybe add to the panic handler support for that? where it would set the next "boot command" to recovery
<samueldr>
there is value in that even for newer android-based devices, as not all of them use A/B schemes
<lordcirth>
samueldr, your goal is to make all borked boots reboot to previous?
<samueldr>
not necessarily to previous, but at the very least to the recovery boot menu
<samueldr>
assuming that on-device you would flash only the boot partition with a fresh build
<samueldr>
the kernel/stage-1 of recovery should hopefully still be one that boots
<samueldr>
I want to enable mostly-fearless tinkering on-device
<danielrf[m]>
samueldr: My thoughts aren't fully formed yet, but I've been experimenting with systemd-boot counting and thinking how similar mobile-nixos should be: https://github.com/NixOS/nixpkgs/pull/84204
<{^_^}>
#84204 (by danielfullmer, 5 days ago, open): [WIP] nixos/systemd-boot: boot counting and automatic fallback
<danielrf[m]>
I don't think we should use android's A/B boot counting
<samueldr>
you're still left with a split super/userdata
<samueldr>
super, though, AFAIUI is freely tinkerable with
<ashkitten>
i don't know if that's something we necessarily care about though, since i assume we'd like a one-size-fits-all solution for all devices yeah?
<samueldr>
though they're entirely relying on device mapper to setup the partitions
<samueldr>
we need to care about it in some way
<samueldr>
since fastboot will now allow flashing system when fastbootd exists
<samueldr>
though I *think* we may be able to simply take the whole super partition as one part of the LVM volume
<samueldr>
and userdata as the other
<samueldr>
though that does leave us unable to use the vendor partitions
<samueldr>
but it might not be a huge deal
<samueldr>
oop!
<samueldr>
oops!*
<samueldr>
I might have accidentally started a firefox build on my asus-z00t
<ashkitten>
the only thing that we need to be actually separate a/b for our purposes is the boot partition, yeah? that way we have one bootloader
<ashkitten>
LOL
<ashkitten>
er, that way we have two stage-1s
<samueldr>
yep, that's what I've been thinking about, that we don't really care about system
<samueldr>
we really only care about boot
<ashkitten>
i got distracted, lol
<ashkitten>
so if we can just merge system_a, system_b, and userdata somehow, we'd have a lot more space to work with
<samueldr>
yes
<samueldr>
in a sense, it shouldn't be any different than merging system and userdata
<ashkitten>
the bootloader should only care about which boot partition it hands off to, anyways. anything further is out of its scope
<samueldr>
depends on how AVB works
<samueldr>
there's that uncertainty
<ashkitten>
oh, hm
<samueldr>
if the bootloader validates the system partition with AVB, then it won't ever be usable really
<danielrf[m]>
yeah, my current thought it just to use AVB for boot.img, and something else for the remainder
<samueldr>
but if it's the kernel/dm-verity that does, then everything's alright
<danielrf[m]>
I think (but would need to check) that the bootloader only validates boot.img
<samueldr>
>> /dev/disk/by-label/NIXOS_SYSTEM 11G
* samueldr
weeps
<danielrf[m]>
and the kernel validates everything else afterward
<samueldr>
danielrf[m]: that's my assumption too
<ashkitten>
i can't wait until i get my cosmo and port nixos to it....
<ashkitten>
that would seem to not be happening for quite a while though
<ashkitten>
i can only hope it'll arrive soon after the pandemic clears up
<samueldr>
drat, I really need to figure out an MTK device I should try and get for a target to port to
<samueldr>
hopefully one which can be flashed with the flashing tools, so nothing recent from xiaomi
<samueldr>
and hopefully one with trivial bootloader unlock
<samueldr>
oh, and hard mode, with sources :)
<samueldr>
it's so great using a usb ethernet adapter to rebuild on device
<ashkitten>
the only mediatek device i have is a steam link
<samueldr>
an android-based MTK device **
<ashkitten>
:p
<samueldr>
I do have one MTK phone, but no sources even after getting in touch multiple times
<samueldr>
(jelly phone)
<ashkitten>
ugh, gpl violations
<samueldr>
I would love to be able to port Mobile NixOS to it
<ashkitten>
*shakes fist*
<samueldr>
yeah :(
<samueldr>
chinese OEMs + MTK gonna do what they do best