<samueldr>
though, at the same time, it would be a bit surprising that the compressed image jumped from ~660MB to 2GiB
<samueldr>
I'll look into it... but first: sleep
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
zupo has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-aarch64
quinn has quit [Ping timeout: 260 seconds]
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
tilpner has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
Thra11 has quit [Ping timeout: 240 seconds]
Thra11 has joined #nixos-aarch64
EatThem has joined #nixos-aarch64
orivej has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
FRidh has quit [Quit: Konversation terminated!]
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-aarch64
Thra11 has quit [Ping timeout: 260 seconds]
EatThem has quit [Quit: Quit]
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
Thra11 has joined #nixos-aarch64
Thra11 has quit [Ping timeout: 246 seconds]
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
Thra11 has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 265 seconds]
orivej_ has joined #nixos-aarch64
orivej_ has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
nschoe has joined #nixos-aarch64
nschoe has quit [Ping timeout: 272 seconds]
orivej has quit [Ping timeout: 260 seconds]
orivej_ has joined #nixos-aarch64
nschoe has joined #nixos-aarch64
Thra11 has quit [Ping timeout: 240 seconds]
orivej_ has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
EatThem has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-aarch64
Thra11 has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
zupo_ has quit [Ping timeout: 260 seconds]
zupo has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
orivej_ has joined #nixos-aarch64
orivej_ has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
rajivr has quit [Quit: Connection closed for inactivity]
EatThem has quit [Ping timeout: 256 seconds]
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
quinn has joined #nixos-aarch64
zupo has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
FRidh has joined #nixos-aarch64
t184256 has left #nixos-aarch64 [#nixos-aarch64]
t184256 has joined #nixos-aarch64
Thra11 has quit [Ping timeout: 258 seconds]
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
Thra11 has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
orivej_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 264 seconds]
<samueldr>
turns out I was wrong, something much simpler
<samueldr>
(see vcunat's comment on the issue)
<irminsul>
oh nice, nixos-rebuild switch seems to have changed thing but for some reason the autologin config didn't do what I expected so now I have the "lightdm doesn't have an on screen keyboard" problem :P
<irminsul>
also it takes ages to boot, though I'm not sure which component that's in
<samueldr>
irminsul: it could be successfully trying to autolog you in, but failing, which restarts lightdm in manual login mode
<samueldr>
(not specific to mobile nixos :))
<irminsul>
yeah I'm expecting a lot of this process to involve discovering nixos behavior I never knew about
<irminsul>
oh maybe I'm not making the nixos user exist?
<samueldr>
that's a possibility
<samueldr>
reboot on the first generation, use journalctl -b-1 to get the logs
<irminsul>
`-b-<n>` is "the nth previous boot"?
<irminsul>
ah yes it is
<samueldr>
-b0 current boot
<samueldr>
-b+1 doesn't work
<samueldr>
that sucks, I would like to see the next boot
<irminsul>
`Thus, 1 means the first boot found in the journal in chronological order, 2 the second and so on; while -0 is the last boot, -1 the boot before last, and so on.`
<irminsul>
this is an extremely silly scheme
<samueldr>
some programming languages do the same for array indices
<samueldr>
oh, your bit makes me think I might have been wrong, -b-0 instead of -b-1
<samueldr>
0 indexing strikes again!
<samueldr>
with its side-kick: negative zero!
<pinkieval>
-b+1 sounds like it would access logs from future boots
orivej_ has quit [Ping timeout: 246 seconds]
<pinkieval>
which would be handy
orivej has joined #nixos-aarch64
<samueldr>
(that was the intended joke :))
<irminsul>
`display-manager[842]: Error writing X authority: Failed to open X authority /var/empty/.Xauthority: Operation not permitted`
<irminsul>
suspicious
<samueldr>
someone's home may be /var/empty
<samueldr>
/var/empty is chattr +i so that nothing can write into it
<pinkieval>
(oh, I missed the next line ><)
<irminsul>
yeah your hypothesis about autologin seems right
<irminsul>
but I'm not yet sure what the bit that made it log out is
<irminsul>
also, why is the default homedir /var/empty???
<clever>
irminsul: did you set isNormalUser = true; on the user?
<irminsul>
no, which might be the issue
<irminsul>
but the thing I'm confused about is that this is an extremely small modification of examples/demo/configuration.nix
<irminsul>
the config that works right now has a rootfs which is dd'd from the image samueldr linked me to, which I thought was generated from that config
<samueldr>
yep, just thinking about different possibilities
<samueldr>
the /var/empty home is what gets me... not sure how it ends up being that
<irminsul>
yeah I'm rerunning nixos-rebuild again with nixpkgs at staging in case something went really weird and I'm not running the nixos I thought I had
<irminsul>
thought I was*
<samueldr>
using nixos-unstable should be fine, maybe better due to cache coverage
<irminsul>
do you know off the top of your head where homedir stuff lands in the derived profile?
<samueldr>
most likely /etc/passwd
<samueldr>
(all of that is normal nixos :))
<samueldr>
just stating in case you were searching into the Mobile NixOS repo
<irminsul>
/nix/var/nix/profiles/system-2-link/etc/passwd doesn't seem to exist :/
<irminsul>
which is concerning
<samueldr>
oh, I think it's generated
* samueldr
digs
<irminsul>
I think I'm getting an intuition for the split here
<samueldr>
into $GENERATION/active, I have /nix/store/w5s7s1nnzsmzdqh06abysffrj2m0nrwf-update-users-groups.pl /nix/store/4j139x9cxk11zz9jagqyzp148knfgwkz-users-groups.json
<irminsul>
basically, mobile-nixos is handling bootloadery stuff and then handing off to more standard nixos
<samueldr>
pretty much
<samueldr>
the Mobile NixOS repo may have some "quirks" it implements for stage-2, e.g. mainly for qualcomm devices it patches xorg to flip the fbdev framebuffer
<samueldr>
but it doesn't change the way NixOS works, only small fixes
<samueldr>
IIRC there is no fix at all for the pinephone
<samueldr>
so yeah, continuing, that json file is what is used to generate /etc/passwd
<samueldr>
it's replaced with that "pre-init" logo instead, and setup to go at the center of the screen instead of top left
<irminsul>
is there a config option that can keep the logging?
<samueldr>
(one of the goal I have is to make it not look like a 1337 hax0r thing, so I'm always ending up looking for solutions to have a fully graphical boot flow)
<samueldr>
I should add that
<irminsul>
I am personally a fan of 1337 h4x0r things when they give info about the underlying process
<samueldr>
yeah, I understand that, and it's something I also want to make togglable
<samueldr>
but most of the devices supported can't do that :)
<samueldr>
so it's been out of sight, out of mind
<samueldr>
all qualcomm-based android devices supported right now can't do virtual consoles
nschoe has quit [Ping timeout: 272 seconds]
Thra11 has joined #nixos-aarch64
<irminsul>
if that screen is showing the kernel but is before the generation picker, does that mean the generations all get the same kernel regardless?
<samueldr>
yes
<samueldr>
but an upcoming improvement, part of the plan, is to implement kexec in generation selection
<irminsul>
would (patched?) grub be better? waiting for a whole linux boot then kexec'ing seems a bit expensive
<samueldr>
patched how? :)
<samueldr>
I think the slowness you are experiencing comes from the naïve implementation of partition/filesystem grow, where it's always done, with ensuing fsck
<samueldr>
I haven't taken the time to optimize that correctly
<samueldr>
though, to come back to alternatives
<samueldr>
the issue comes from devices not-made-for-standard-linux
<samueldr>
it'd take quite a bunch of work to get grub going on most devices
<samueldr>
while the current approach allows quicker porting
<samueldr>
with the pinephone, specifically, grub could be used, but not until someone implements the display drivers in u-boot
<samueldr>
on the pinebook "a64" (non-pro), same SoC, I'm using u-boot + grub to boot nixos, and grub works as expected
<samueldr>
in that case, "mobile nixos" would be unneeded
<samueldr>
and I wholly support non-mobile-nixos approaches to boot nixos! especially considering once the system is booted there's not much left of Mobile NixOS :)
<samueldr>
on qualcomm-based android devices, it (is known possible for some devices) might be possible to port tianocore and EDK to get UEFI, and then boot UEFI from there on
<samueldr>
but this requires porting work for each device
<samueldr>
while the approach of using Linux to boot allows us to... use Linux to boot, Linux which is part of Android, and needed anyway
<samueldr>
in reality, if it was possible and trivial to get EDK+Tianocore going for all devices, I would go for that 100%
<samueldr>
in practicality, whew that's a lot of work :/
<samueldr>
things are optimized to reduce the hurdles as much as possible for new users to make a new port
<samueldr>
and, circling yet again back to grub
orivej_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 264 seconds]
<samueldr>
there is one issue, generic to most aarch64 platforms, that is yet to be solved
<samueldr>
the kernel has set itself to be the gatekeeper and maintainer of flattened device trees (FDT, .dtb) for all devices supported on mainline
<samueldr>
so, to get things going well, you kinda have to use the FDT produced by the kernel you run
tilpner_ has joined #nixos-aarch64
<samueldr>
not an issue when your OS doesn't have the concept of generations, shove the FDT next to the initrd and kernel images, and configure the loader to load it
<samueldr>
especially since you're also likely to have that image support only one device
<samueldr>
but this is not possible to do with grub, as grub has no way to know which FDT to load in a directory in a generic manner
<samueldr>
it's quite frankly, a big mess whenever you're not constraining the built system to only one device
tilpner has quit [Ping timeout: 264 seconds]
tilpner_ is now known as tilpner
<samueldr>
the way I see all of this: make it a new normal for enthusiasts to be able to run whatever they want on their phone, to hopefully transform the industry into making it easier for enthusiats to do so
<samueldr>
so at some points shortcuts have to be taken, as a team of mostly 1 individual :)
<irminsul>
oh hm
<irminsul>
The option `security.polkit.enable' has conflicting definitions, in `/home/joe/Sync/nixpkgs/nixos/modules/services/x11/desktop-managers/xfce.nix' and `/home/joe/Sync/nixpkgs/nixos/modules/security/rtkit.nix' and `/home/joe/Sync/mobile-nixos/modules/cross-workarounds.nix'.
<irminsul>
giving up temporarily on nixos-rebuild
<irminsul>
and just trying to generate a disk image of the demo
<samueldr>
the demo image needs to be built on native aarch64 (using qemu binfmt may work)
<samueldr>
if it's loading cross-workarounds, it's trying to cross-compile
<samueldr>
I have not tested, and am not testing using QEMU binfmt
<irminsul>
ah I thought I was doing that but I need `--argstr system aarch64-linux` I guess?
<irminsul>
which makes sense
<irminsul>
I don't have any arm devices other than the pinephone & some rpi's that I never got running nixos
orivej_ has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
<samueldr>
not entirely sure how to force aarch64, I know one way lies to nixpkgs, the other one does a "true" attempt at being aarch64-linux
<samueldr>
I believe `--system aarch64-linux` is the right way
<samueldr>
trace: Building with crossSystem?: aarch64-linux != aarch64-linux → we're not.
<irminsul>
yep that's doing it!
<irminsul>
thx
<irminsul>
I wonder how eg, ub touch is doing its bootup
<samueldr>
similar, but no need to worry with generations
<samueldr>
u-boot -> kernel/initrd for ubports
<samueldr>
AFAIK there is only one boot chain that isn't dependent on u-boot directly on the pinephone