<shofius>
oh ok. i've seen that page you linked many times but for some reason i always thought that had something to do with my build system's configuration.nix
<samueldr>
haha, on the device
<samueldr>
I think I need to re-do a lot of the onboarding
<samueldr>
like, did you know that while the loading splash screen is present, if you press a volume key you will be able to select a generation?
<shofius>
oh nice. i didn't know that
<shofius>
since i haven't been able to update yet, i only have one generation :p
<samueldr>
no onboarding guide to let you know what the different parts are and how they work :)
<shofius>
ok, so right now i have a phone running nixos but ssh is not enabled. so if i want to keep my configuration exactly as is, but enable ssh, do i need to type out the full config that i build with, plus that mobile-nixos import from your link, plus the ssh addition?
<samueldr>
that's an option, but not a good one
<samueldr>
since you have done "nothing" on the system, you could also configure locally the image with ssh and your key
<samueldr>
build a new image and flash it
<samueldr>
at this point it's more about how would you handle that with the given limitations
<samueldr>
and nothing specific to mobile nixos I guess :)
<shofius>
ok
<shofius>
is there any way to build an image that already has a config in place that i can modify on the device?
<shofius>
part of the reason for that is that i have a few friends that i want to share this image with and i'd rather have a config on the device that can be edited rather than personalize it with keys
<samueldr>
I think this is something that is "nixos-hard", that is, there is nothing that can serialize the active config for you
<samueldr>
so outside of the scope of purely Mobile Nixos, and something that NixOS doesn't manage itself
<samueldr>
what you could do is, I guess, customize the rootfs image
<shofius>
i suppose i could write some kind of "default"-ish config that gets written to the home folder of the user at build time or something so it can easily be copied over and be a starting point
<samueldr>
in this `populateCommands` the PWD is the rootfs
<samueldr>
so let's say your configuration for the built image is in `configuration.nix`, you could `mkdir -p etc/nixos; cp ${./configuration.nix} etc/nixos/configuration.nix`
<samueldr>
I guess that's a good thing to show-off as part of the examples/demo system config
* samueldr
makes an issue
<shofius>
ok sweet
<shofius>
lol
<shofius>
is it safe to have that import line in the local.nix that i'm using to build my image?
<shofius>
or does it need to be commented or something?
<samueldr>
good question
<samueldr>
it'd "re-apply" the config
<samueldr>
for the device
<samueldr>
so I don't know
<samueldr>
try it
<samueldr>
but I would assume that to be "not supported"
<samueldr>
you probably want to somehow split your config a bit to cheat with the build
<samueldr>
e.g. in local.nix import "mysystem.nix", where your config is, and in configuration.nix add the device import line, then import mysystem.nix
<samueldr>
and copy both mysystem and configuration
<samueldr>
(please pick a better name for mysystem)
<shofius>
lol
<shofius>
ok i'll play around with it and see if i can get something going
<shofius>
thanks :)
<samueldr>
n/p
<samueldr>
the important bit to get is that mobile nixos mainly deals with abstracting the mobile devices
<samueldr>
everything else is mostly standard nixos
<samueldr>
(part of abstracting the devices requires building disk images... so that's why there's a lot of disk images building)
<shofius>
i've only been using nixos since like... september or something... or maybe december, idk
<shofius>
so a lot of this is still confusing even with normal nix stuff lol
<shofius>
but i'm super happy to have nix on my phone though
<shofius>
i've had a lot of fun figuring stuff out with nix and writing nix-shells for everything
<shofius>
(that is... for everyday nixos stuff... not mobile --- yet)
<samueldr>
great!
mvnetbiz_2 has quit [Quit: Bye!]
rajivr has joined #nixos-aarch64
apache8080 has joined #nixos-aarch64
<apache8080>
I am trying to boot a board via USB that has a nixos image and the board has uboot, but on boot I get a /sbin/init no such file or directory error
<apache8080>
any ideas?
h0m1 has quit [Ping timeout: 264 seconds]
h0m1 has joined #nixos-aarch64
apache8080 has quit [Ping timeout: 256 seconds]
<samueldr>
it feels like I've been spending the whole evening trying to get that dang lpunpack "project" someone has on github building
<samueldr>
and I'm still not closer than I was a while ago
<samueldr>
oh
<samueldr>
I *had* to say it to unblock it I guess????
<danielrf[m]>
samueldr is it the project with the `make.sh`
<samueldr>
yes
<danielrf[m]>
that code is just unfortunate
<samueldr>
issues with linking because it requires clang
<samueldr>
yes
<samueldr>
and the amount of sub-projects needing to be wrangled makes me not want to do that "better"
<danielrf[m]>
if you do end up having to wrangle a ton of these projects at some point I think the soongnix approach would be the right way to handle it
<danielrf[m]>
not saying the current soongnix code is up to snuff though :)
<samueldr>
would it be usable without IFD?
<danielrf[m]>
Yes, via builtins.fetchGit or flakes
<danielrf[m]>
if you fetched soongnix code at eval time
<samueldr>
hm
<danielrf[m]>
shouldn't need IFD then I don't think
<samueldr>
yeah, but I think using builtins.fetchGit there is not going to work in e.g. hydra
<danielrf[m]>
but longer term you might hope they switch these subprojects over to bazel
<samueldr>
another avenue I found
<samueldr>
CLion apparently can handle transforming an android source tree to CMakelists
<danielrf[m]>
My biggest hope with their transition to bazel will be if they allow us to only checkout a fraction of the required repos to build a particular project
<samueldr>
I sincerely have no hope for anything touching AOSP... because their infrastructure scale "solves" their issues
<samueldr>
they don't need to make it easier for people to checkout
<danielrf[m]>
great open source values, right :) only google can build it conveniently
<samueldr>
hopefully I'll be proven wrong
<samueldr>
but look at chromiumOS, they also require a big brain setup to compile
ryantrinkle has quit [Ping timeout: 256 seconds]
ryantrinkle has joined #nixos-aarch64
<samueldr>
great, it builds for aarch64-linux (native) even with that messy make script
<samueldr>
oh... duh... restoring the `super` partition will be as simple as `fastboot flash super` in the bootloader fastboot (not fastbootd)
<samueldr>
assuming the user has access to a valid super.img... which hopefully they will
<samueldr>
(but flashing something else into the super partition doesn't work... fastboot checks that it's a dynamic partition image)
cole-h has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-aarch64
konubinix has quit [Quit: Coyote finally caught me]
konubinix has joined #nixos-aarch64
noneucat has quit [Quit: Idle for 30+ days]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
orivej has quit [Ping timeout: 260 seconds]
bpye has quit [Ping timeout: 260 seconds]
bpye has joined #nixos-aarch64
s1341_ has quit [Quit: Connection closed for inactivity]
bpye has quit [Ping timeout: 265 seconds]
bpye has joined #nixos-aarch64
s1341_ has joined #nixos-aarch64
superherointj has joined #nixos-aarch64
dev_mohe has joined #nixos-aarch64
aminechikhaoui has quit [Quit: Ping timeout (120 seconds)]
superherointj has quit [Quit: Leaving]
aminechikhaoui has joined #nixos-aarch64
zupo has joined #nixos-aarch64
shofius has quit [Remote host closed the connection]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dev_mohe has quit [Quit: dev_mohe]
dev_mohe has joined #nixos-aarch64
zupo has joined #nixos-aarch64
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…]
shofius has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
Acou_Bass has quit [Ping timeout: 260 seconds]
marek has quit [Changing host]
marek has joined #nixos-aarch64
cole-h has quit [Quit: Goodbye]
cole-h has joined #nixos-aarch64
<shofius>
samueldr: is there some way i can get in and see if there were errors or something during boot? i created an image the way we were talking about last night (splitting up the local.nix in order to inject configuration.nix into the build when it boots) and it built the image fine but when i try to boot it on my pinephone, stage 2 is just the text-based login prompt instead of the sxmo interface i was expecting
<shofius>
hrm... i mounted the root partition and i see my config files made it to where they're supposed to be. but i'm also noticing i need to move some stuff around cause it as some stuff in the config that shouldn't be there.. oops
aleph- has quit [Ping timeout: 264 seconds]
aleph- has joined #nixos-aarch64
<samueldr>
ideally, everyone getting the pinephone, still, should be getting a UART adapter...
<samueldr>
... since so many things are not "ready"
<samueldr>
it makes harder things trivial to debug
<samueldr>
you could use journalctl on the image that booted once, if you mount it on your computer
<samueldr>
I don't remember the exact way
<Ke>
yes
<Ke>
though pine64 is not very good at shipping adapters of correct voltage
<Ke>
I got 5v serial and someone else reported that too
<Ke>
caused funny issues with the pinebook, luckily did not seem to break anything permanently
srk has quit [Remote host closed the connection]
srk has joined #nixos-aarch64
khh7778 has joined #nixos-aarch64
<shofius>
ok that worked. i was able to mount the root partition and then do `sudo journalctl --file var/log/blah/blah`
<samueldr>
great, I really like users/future contributors that can fill in the blanks :)
khh7778 has quit [Ping timeout: 240 seconds]
<shofius>
i'm not sure how helpful i'll be :p but i'm having fun so far
<samueldr>
don't worry, clearly explaining issues and troubles is one way of contributing
<shofius>
yeah that's a good point
rajivr has quit [Quit: Connection closed for inactivity]
justan0theruser has quit [Ping timeout: 264 seconds]
<shofius>
looks like there are a lot of errors due to not being able to find users and groups that it's expecing to be there
<shofius>
i split things up a bit better (i think) and rebuilt the image. i'm downloading that one now and i'll see if that's any better. i should probably get used to looking at these logs when things are working as expected so i can get familiar with what's "normal" in there
khh7778 has joined #nixos-aarch64
apache8080 has joined #nixos-aarch64
<shofius>
ok well... the new image booted fine
<khh7778>
Hello! I have Google Pixel 1 Phone (not XL, codename: Sailfish). Also, i find official build of Mobile NixOS for Google Pixel 1 XL (codename: Marlin). I check specifications for both devices, its have difference in screen resolution and battery. And now I have a question: how I cant to port NixOS Mobile to Pixel Sailfish now? Maybe I can do it for
<khh7778>
few ways? Thanks!
<apache8080>
has anyone here used the boot.loader.initScript option in their NixOS config? I tried adding it but it doesn't create the /sbin/init directory
<samueldr>
khh7778: since they're quite close, you could start with a copy of the google-marlin device descriptions, changing the few marlin-specific things for sailfish equivalents
<samueldr>
e.g. the firmware, some of the device config, but more importantly the kernel config
<samueldr>
at "android-linux-stable", sailfish is a distinct repository
<samueldr>
oh... no
<samueldr>
there is no sailfish repository
<samueldr>
uh... that's annoying
<samueldr>
as I meant to say before finding this unfortunate turn of event: the kernel configuration differs slightly between both devices
<samueldr>
some config options needs to be off, and some others need to be on, for device-specific OEM customizations
<samueldr>
odd, I might be wronger than I thought
<samueldr>
looks like for LineageOS
<samueldr>
"Nothing is really here, all configuration is in device/google/marlin.
<khh7778>
But if i try to flash Marlin image to Sailfish, whats may happened? I know that difference only in resolution of display and battery.
<samueldr>
about the resolution of the display, it shouldn't be an issue, the one described in Mobile NixOS is described only as an informational data point (still not used!)
<samueldr>
about the kernel, I guess it depends on what is actually in the "ALS" (android-linux-stable) kernel
<samueldr>
is it a unified kernel for both sailfish and marlin?
<samueldr>
if so, things should work fine *assuming* the sailfish bits were enabled
<samueldr>
khh7778: do you know what "device tree" is? (e.g. dtb, FDT, dts)
<samueldr>
(assuming no for time reasons)
<samueldr>
it's a standardized method to describe the hardware
<samueldr>
the bootloader is able to "pick" the right "device tree" from the boot image
<samueldr>
(e.g. the sailfish one)
<samueldr>
and the kernel uses that description to init the different drivers
<samueldr>
so the exact display in use, and the battery, no issues
<samueldr>
that's important, since sometimes on the "same" device, you can have different incompatible displays!
<samueldr>
or other components
<samueldr>
hm! looks like sailfish is indeed part of the ALS tree too
<khh7778>
Thanks for hints. I will unpack kernels of both devices, and find differences. I hope, that i will can to run linux on my device. And i have last question: what layers (main components) included in Mobile NixOS flashable images? It use Android OS for run?
<samueldr>
it does not use Android
<samueldr>
the kernel comes from vendor kernel trees, meant for use on Android
<samueldr>
but it's configured to run a standard NixOS aarch64 system
<samueldr>
the prebuilt images... it's a bit more complex
<samueldr>
if you flash the what there is on the hydra, it will seemingly hang
<samueldr>
because it'll successfully boot into an unconfigured system
<samueldr>
I have here a customized system image which is somewhat more configured
<samueldr>
note that wi-fi will not work out of the box for the time being
<samueldr>
it would require a "rebuild" (a NixOS term) with the firmware configuration enabled
<samueldr>
firmware files, for the time being, are assumed unfree unredistributable
<AmandaC>
How could I make hydra able to run aarch64 jobs on a host with boot.binfmt.emulatedSystems set to emulate it?
khh77786 has joined #nixos-aarch64
khh77786 has quit [Client Quit]
<samueldr>
AmandaC: I think last time people asked a similar question the solution was to add the same machine, another time, but with the system as aarch64-linux
<samueldr>
clever may be able to confirm
<AmandaC>
ah
<clever>
yeah, just add both x86 and arm to the systems list for the build machine
<AmandaC>
Ah, I wasn't defining any builders at all, I guess I could do that and it'll Just Work(tm)
<AmandaC>
( So it was using the default of localhost building )
khh7778 has quit [Ping timeout: 240 seconds]
justanotheruser has joined #nixos-aarch64
apache8080 has quit [Ping timeout: 264 seconds]
khh7771 has joined #nixos-aarch64
AmandaC has quit [Quit: WeeChat 3.0.1]
<khh7771>
Hi. Has anyone managed to run NixOS mobile on real device with gui (KDE, for example)?
AmandaC has joined #nixos-aarch64
<samueldr>
"with GUI", yes the examples/demo rootfs has a (not that good) GUI configuration
<samueldr>
but there is no "phone GUI" packaged **yet**
<samueldr>
I've been working these past few days on packaging plasma mobile, and other community users have been packaging phosh on their own
<samueldr>
so hopefully soon™ we'll have two phone-first GUIs
<samueldr>
(and there's more, with community people working on sxmo)
<samueldr>
once in Nixpkgs proper, we'll have example configurations for both of them I guess
<samueldr>
note that it is assumed **only** mainline-based devices will be able to use wayland-based compositors, so phosh and plasma mobile for the time being won't be usable on many, or even most, android-based devices
<samueldr>
(this assumption may be somewhat thin... but I can't promise it'll work...)
<khh7771>
I know about KDE Plasma. Who can send me demo screenshots or videos with NixOS Mobile running?
<samueldr>
I don't think we have many for the time being
<samueldr>
khh7771: anything reason?
<samueldr>
oops, any reason*
<khh7771>
ok
khh7771 has quit [Quit: Connection closed]
<samueldr>
a lot of the header images of the news items include a photo of the (not great) example demo gui
<samueldr>
I'm wondering about the reason behind the question
<shofius>
maybe they're just wondering if it's gonna be worth the effort to get it going or something
<samueldr>
yeah, that's why I was curious about the reason :)
<samueldr>
it's not like Mobile NixOS has a custom experience (once booted)
<samueldr>
it's value-add is NixOS, and its declarative configuration
<samueldr>
*and* the value-add of Mobile NixOS specifically on top of NixOS is the phone-first early boot setup
<samueldr>
you could have the same "desktop" (phone) experience on another distro, just like on NixOS you can have a gnome setup that is indistinguishable from another stock gnome on another distro
<shofius>
yeah but you still get nixos once booted, even if its config is not inherited from the built image
<samueldr>
exactly!
<samueldr>
basically, it's a normal NixOS system, except for stage-1 and earlier
<shofius>
do you know how i'd go about finding out where the cameras are located for my phone?
<shofius>
this build has the megapixels app but it errors out cause it's looking for the cameras in the wrong place
zupo has joined #nixos-aarch64
apache8080 has quit [Ping timeout: 246 seconds]
<samueldr>
uh, not really, haven't taken the time to check camera stuff yet :)
superherointj has joined #nixos-aarch64
flokli is now known as FLOKLI
adisbladis is now known as ADISBLADIS
lovesegfault is now known as LOVESEGFAULT
pie_ is now known as PIE_
ashkitten is now known as ASHKITTEN
cole-h has quit [Ping timeout: 246 seconds]
superherointj has quit [Quit: Leaving]
AmandaC has quit [Quit: WeeChat 3.1]
AmandaC has joined #nixos-aarch64
apache8080 has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
apache8080 has quit [Ping timeout: 256 seconds]
cheshircat has joined #nixos-aarch64
zupo has joined #nixos-aarch64
<cheshircat>
I'm trying to install nixos on my motorola e6, and I don't know what the fastboot boot "android burn tool" thing is
<cheshircat>
So I'm having trouble flashing the system image
<samueldr>
ignore that, "android burn tool" is something that doesn't exist anymore
* samueldr
looks to remove that from the docs...
<cheshircat>
OK, is there a new way of flashing the system image?
<samueldr>
should be only part of the instructions for two specific devices, where did you see that?
<cheshircat>
In the instructions for the motorola e6
<samueldr>
duh... I didn't realise E6 was surfna :)
<cheshircat>
:D
<cheshircat>
Is there another way of flashing the system image?
<samueldr>
use the flashable zip through TWRP
bpye9 has joined #nixos-aarch64
<cheshircat>
I can't find a TWRP image for surfna
<samueldr>
oh... right... there isn't an official one
dongcarl has quit [Write error: Connection reset by peer]
* samueldr
thinks
<cheshircat>
Is there a reputable unofficial one?
<samueldr>
reputable, I don't know
<cheshircat>
This is a spare phone, I don't really care about screwing it up
<samueldr>
I wouldn't be the one to make that judgement call
<samueldr>
but I used one from XDA
bpye has quit [Read error: Connection reset by peer]
bpye9 is now known as bpye
<cheshircat>
Could you send the link?
<samueldr>
AFAIK motorola phones are generally recoverable from screwups... but I don't know how far
<cheshircat>
I promise I won't sue :D
<samueldr>
hmm...
<samueldr>
I *don't* have a TWRP for it
<samueldr>
sorry, I assumed, I have too many devices to keep track of
<cheshircat>
haha no worries
<samueldr>
I guess maybe I actually used that writer... but I think I used an unsafe method instead
<samueldr>
or uh, not that writer, but the same idea
<samueldr>
I'm curious: what the heck is up with this week? I've never had *that many* questions about Mobile NixOS from new peeps!
<cheshircat>
What do you mean "that writer"?
<samueldr>
uh, "android burn tool"
<samueldr>
it was basically a preconfigured image with ssh running with USB rndis
<cheshircat>
Ah
<samueldr>
right, looking quickly it seems there still is no ROM community for that device
<cheshircat>
Is there a way of bringing the android burn tool back?
<samueldr>
I'll be hones: this line was copied from another device's README, I probably actually never used the exact "android burn tool"
<samueldr>
honest*
<samueldr>
though I guess this *does* mean a method needs to be figured out here
dev_mohe has quit [Quit: dev_mohe]
<cheshircat>
Could I just copy the android burn tool stuff from the older version?
apache8080 has joined #nixos-aarch64
<cheshircat>
Is it basically a stripped-down configuration.nix?
<samueldr>
the reason I removed it outright was because it didn't exactly work :)
<samueldr>
and yes
<samueldr>
it's basically that
<cheshircat>
hahaha
<samueldr>
the main idea being that it doesn't have a dependency on rootfs
<cheshircat>
So basically what you are saying is that there isn't currently a way of flashing mobile-nixos on motorola e6?
<samueldr>
nothing out of the box, all requires you to *somehow* be able to `dd` on the userdata partition (because system is likely too small to be useful)
<samueldr>
I'm thinking just a bit more to see if there's a cheaty way
<cheshircat>
I'm all for cheaty ways, thanks for thinking about it!
<samueldr>
for which there is a note about how it's trivial to brick an android device with it
<cheshircat>
OK, noted
<apache8080>
for uboot does it default to sdcard for booting? and is there a way to set uboot to look on /dev/sda1 without needing to bring up a uboot prompt?
<samueldr>
apache8080: u-boot build dependent
<samueldr>
and the answer is then, u-boot build dependent :)
<apache8080>
ok thanks, do you know what uboot config sets that stuff?
<samueldr>
cheshircat: Something like: mobile.boot.stage-1.bootConfigstorage.internal = "/dev/disk/by-partlabel/userdata"; should make target disk mode buildable and export the userdata partition as a usb drive
<samueldr>
cheshircat: It's extremely likely I flashed it like that
<samueldr>
apache8080: device-dependent in the u-boot source tree, or when it's not, it's SoC family dependent
<apache8080>
ok thanks
<samueldr>
also, important to realize that vendor u-boot trees and mainline u-boot trees are likely to act differently
<samueldr>
cheshircat: note about target disk mode, again, sharing the whole storage of the phone is a bad idea, since the storage on most (all?) android phones holds the boot firmware
<samueldr>
but sharing one single partition *should* be fine
<samueldr>
it *may* not work if the device strictly uses DRM
<samueldr>
I don't remember if I booted it on the motorola-surfna, or if I stopped at `examples/hello`
<cheshircat>
So how do I install the system.img with the USB mass storage thing?
<samueldr>
`dd if=... of=/dev/... bs=whateveryoureusedto oflag=sync status=progress` or anything like that
<samueldr>
note that it's already the partition, so you write to the "whole" block device
<cheshircat>
if=.../system.img?
<samueldr>
yes
<cheshircat>
Do I have to do stuff with boot.img and recovery.img first?
<samueldr>
you can do the stuff with boot.img with fastboot
<samueldr>
fastboot will (for no good reason really) not write to userdata on the motorola-surfna :)
<cheshircat>
OK, I already did that, and that shouldn't have been overwritten by this usb mass storage thing, right?
apache8080 has quit [Ping timeout: 240 seconds]
<cheshircat>
Oh, though also, will the boot.img and recovery.img be different for the hello system image?
<cheshircat>
I guess just to be on the safe side I'll fastboot them again before I copy over the system.img
<samueldr>
for the hello image, yes boot (and recovery) will be different
<samueldr>
since the hello image uses a different filesystem label
<cheshircat>
makes sense
<samueldr>
(recovery isn't actually required... it's what boots in recovery mode)
<samueldr>
because some devices require it, *all* devices build the full recovery system in the boot.img too!
<cheshircat>
OK, flashed boot and recovery, booted up usb mass storage, fingers crossed
<samueldr>
btw, you probably want to save in your personal archives the "motorola blankflash" for "surfna" you can find on a mirror at the top of google search results
<samueldr>
AFAIUI blankflash is the motorola-specific process to go from a quite-bricked device to a working device
<samueldr>
though I haven't personally had to deal with blankflash yet
<cheshircat>
great success!
<samueldr>
great!
<samueldr>
in the display validation test, does it say it's using `fbdev` or `drm`?
<cheshircat>
fbdev
<samueldr>
surfna is at a vintage of SoC where it could realistically be any of them
<samueldr>
ah, "great", the demo rootfs should work
<samueldr>
(drm in theory should be better, but there are challenges with android-flavoured DRM drivers)
dev_mohe has joined #nixos-aarch64
<cheshircat>
So now if the demo doesn't crosscompile, how do I download it?
<samueldr>
there is a "Link" column with a zst compressed artifact
dev_mohe has quit [Client Quit]
<cheshircat>
Will this work with the "boot.img" that I have already installed?
<samueldr>
this is your "system.img" (which kind of needs to be flashed to userdata)
<samueldr>
no it will not because the filesystem label differs
<samueldr>
but you *can* cross-compile the boot.img for examples/demo
<cheshircat>
Aha!
<samueldr>
-A build.android-bootimg # IIRC
<samueldr>
oh, just as a preface: wireless networking is not expected to work
<cheshircat>
Not so surprising
<samueldr>
but I have time set aside (later) to work on the issue for qcacld-3.0 devices
<samueldr>
I'm not 100% sure it's qcacld-3.0 though
anton[m] has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<samueldr>
I don't know if that makes it better or not :)
<cheshircat>
So basically, I can't rebuild the system on my laptop, because it doesn't cross-compile, and I can't rebuild the system on my phone, because it doesn't have internet?
<cheshircat>
Hahaha
<cheshircat>
Welp, it better have some good things preinstalled!
<samueldr>
sgtatham's puzzle collection!
<samueldr>
you can use a wired network interface though, probably
<samueldr>
(the kernel drivers may not be enabled... I try to do it though)
<samueldr>
either native type-c, or using something like a type-c to type-a adapter
<samueldr>
native type-c may have the benefit of allowing pass-through charging!
<samueldr>
it's definitely not in a usable place for many android-based devices
<samueldr>
but it was important to get "useless" devices early in to test assumptions
<samueldr>
(the motorola-surfna was a deal for real cheap... useful to test that SoC "vintage")
<cheshircat>
surfna doesn't have type-c :D
<samueldr>
uh, right
<cheshircat>
real cheap indeed
<samueldr>
(see how familiar I am with it? :))
<samueldr>
OTG adapter, though no power through
<cheshircat>
OK, sweet, I have a 30$ microcenter giftcard burning a hole in my pocket, maybe I'll use it on that
<cheshircat>
Yeah, I was really surprised to see the E6 as one of the supported devices; it's really pretty crap
<samueldr>
cheap, and bought it as a challenge
<samueldr>
there is also asus-x018d in that list
<samueldr>
both of them have *no* custom ROM community
<cheshircat>
Yeah I know
<samueldr>
which meant to me that if I could run Mobile NixOS easily, that (Mobile) NixOS is really the best ;)
<samueldr>
hint: it's basically the best ;)
<cheshircat>
so, I jiggled the cord while writing with dd, and now when I try to write again, it gives me "error writing /dev/sdb: no space left on device'
<cheshircat>
What does that even mean?
luxemboye has quit [Remote host closed the connection]
<cheshircat>
Like, how is it possible for dd to fail with that error?
luxemboye has joined #nixos-aarch64
<cheshircat>
it used to show up as 10GB in gparted, and now it's only showing up as 386 MB
<samueldr>
I don't know!
<samueldr>
maybe the gadgetfs driver is weird?
<cheshircat>
wuhuh
<samueldr>
uh mass storage gadget driver*
<samueldr>
try rebooting into TDM again
<samueldr>
(target disk mode)
<cheshircat>
I did that
<cheshircat>
is there a way to reset it?
<samueldr>
there is no reason I can see that it would do that
<samueldr>
maybe `fastboot format userdata`
Acou_Bass has joined #nixos-aarch64
<cheshircat>
OK, I'll try that
<cheshircat>
"Formatting is not supported for file system with type 'raw'"
<samueldr>
do you have `adb` enabled on your host nixos system?
<cheshircat>
yes
<samueldr>
good
<samueldr>
I believe adb is enabled by default in TDM
<samueldr>
that'll give you a root shell within stage-1
<cheshircat>
OK, cool
<cheshircat>
ah, I'm in
<cheshircat>
can I just write /dev/zero to /dev/disk/by-label/NIXOS_SYSTEM?
<cheshircat>
ah, there's fdisk available
<samueldr>
DO NOT
<samueldr>
change the partitioning
<samueldr>
use fdisk only to list partitions
<cheshircat>
Yeah, didn't change the partitioning
<samueldr>
because accidentally touching the wrong partition is a good way to brick an android device :/
<cheshircat>
I tried running mkfs.ext4 on it
<samueldr>
you should be able to use /dev/disk/by-partlabel/userdata as a target
<samueldr>
you could use `blkid` to identify the "sdX" name
<samueldr>
and cat cat /sys/block/sdX/sdaXn/size
<cheshircat>
hmmm
<cheshircat>
I can't seem to find which one corresponds to userdata
<cheshircat>
what would the LABEL be?
<samueldr>
oh
<samueldr>
ls -l /dev/disk/by-parlabel/userdata should show it then
<samueldr>
I assumed blkid showed partlabel
<samueldr>
but I guess it doesn't
<samueldr>
(something not necessarily obvious, there can be BOTH a partition label [gpt] and a filesystem label [e.g. ext4])
<cheshircat>
how do I interpret this block size?
<samueldr>
hm
<samueldr>
either sectors or bytes
<samueldr>
if it's sectors, 512 bytes are assumed IIRC
<samueldr>
what's the value?
<cheshircat>
22716383
dev_mohe has joined #nixos-aarch64
<samueldr>
I have 22716383 here too
<samueldr>
so the partition block device is fine
<samueldr>
(I booted my motorola-surfna to check)
<samueldr>
maybe cat /dev/zero to it and reboot TDM?
dev_mohe has quit [Client Quit]
<cheshircat>
Alright, here goes
<samueldr>
good to confirm that the issue (which is weird!) didn't touch the actual block device size
<cheshircat>
Could it be something with the superblock?
<cheshircat>
what is a superblock?
<cheshircat>
also, I guess cat /dev/zero never stops on its own, lol
<samueldr>
cat /dev/zero should stop once the block device is full
<samueldr>
no idea about the superblock...
<samueldr>
>> The superblock is essentially file system metadata and defines the file system type, size, status
<samueldr>
that shouldn't affect mass storage
<samueldr>
that's a filesystem thing
<cheshircat>
Ah
<cheshircat>
How do I verify the partition table?
<cheshircat>
Could it be something there?
<cheshircat>
hmmm
<cheshircat>
Aha!
<samueldr>
shouldn't be, since that size comes from the partition table
<samueldr>
aha?
<cheshircat>
I mkfs.ext4d userdata again, and then ran df-h and it shows up as 10.6G!
<cheshircat>
So this is a problem with USB mass storage I guess
<cheshircat>
(I have no idea how it would persist across reboots...??)
<samueldr>
wait, were you checking the filesystem size?
<samueldr>
that's normal
<samueldr>
you're flashing a (minimal) filesystem!
<samueldr>
it will resize to fill the block device at first boot
<samueldr>
though... I'm feeling maybe there's something weird still with the mass storage?
<samueldr>
I guess I should test
<cheshircat>
So, the file system size as reported through adb shell
<cheshircat>
is 10.6GB
<cheshircat>
The file system size as reported through gparted (going through the mass storage driver) is 386.30 MiB
<samueldr>
right
<samueldr>
because the file system itself is built to be as small as possible
<samueldr>
but what about the _block device_ shown on your computer?
<cheshircat>
Yeah, that's 386.30 MiB
<samueldr>
in theory it should be 22716383 whatever units this actually was
<samueldr>
so that's the odd part
<cheshircat>
I'm now starting to think that maybe it's something cached weirdly on the laptop side
<cheshircat>
let me reboot
cheshircat has quit [Quit: Connection closed]
cheshircat has joined #nixos-aarch64
<samueldr>
btw, I'm not saying you're wrong... but _something_ is wrong if what you're relaying is correct...
<cheshircat>
I was right!
<samueldr>
odd!
<cheshircat>
rebooting fixed it
<cheshircat>
Yeah, super odd!
<samueldr>
I wouldn't have expected that
<cheshircat>
Yeah, me neither
<samueldr>
especially given that even when a filesystem doesn't fill a block device... the block device is still of a given size
<samueldr>
maybe it was bumping the wire that caused things to go awry?
<cheshircat>
Yeah, I mean definitely that was the proximal cause
<cheshircat>
Truly, today we have stared into the abyss of the linux kernel
<samueldr>
though knowing a reboot fixes it is good, if anyone else gets a similar issue I can propose that (even as odd as it sounds)
<cheshircat>
Yeah, I bet it depended on the microsecond timing of the jiggle, or something
<cheshircat>
I sincerely doubt this is a reproducible bug!
<samueldr>
the most fun!
<cheshircat>
Indeed!
<cheshircat>
This usb mass storage thing is pretty funny
<samueldr>
when it's safe to use on the whole storage device of a device, e.g. pinephone, that's **extremely** useful
<cheshircat>
I.e., android used to always present as usb mass storage, and this is such a nose-thumbing to the decision to remove that
<samueldr>
you should not mount the filesystem or manipulate the block device on both ends at once
<samueldr>
well... because of that ^
<cheshircat>
Like "screw you google, my phone *is* a flashdrive"
<samueldr>
they had to unmount the "sd card" partition