<sphalerite> oh hm I should probably include the kernel module tree on nixos as well… that might help with the wifi and stuff too
<sphalerite> is there a way I can just plonk the /lib/modules from chromeos in nixos and have it find it?
<clever> sphalerite: it has to be under /run/current-system/kernel-modules i believe
<sphalerite> ah yes that looks helpful
<clever> line 48 is where it symlinks the nixos modules
<clever> line 93 is under your control
<clever> delete the evil module symlink!
<sphalerite> hm I think overriding config.system.modulesTree is more elegant
<clever> that would also embed into the initrd better
<clever> are you even using an initrd?
<sphalerite> no I'm not
<clever> this is doing fun things with the nixos options framework
<clever> you set the option to a list of derivations
<clever> but it then runs pkgs.aggregateModules over that list, to merge them into a single dir
<clever> i believe it mixes buildEnv with depmod
<sphalerite> wtf!? I'm trying to ssh in but as soon as I auth it closes the ocnnection
<clever> any way to view the journal?
<sphalerite> yeah that's what I'm about to do
<sphalerite> (the way: reboot into chromeos, mount everything, chroot)
<clever> oh, you can also experiment with the usb ethernet, while in real chromeos
<sphalerite> yeah it works
<sphalerite> wtf
<sphalerite> "failed publickey for root from 192.168.1.200 port 50610 ssh: RSA SHA256:…"
<clever> enable password auth?
<sphalerite> "fatal: Access denied for user root by PAM account configuration [preauth]"
<clever> ah
<sphalerite> which is weird because it is accepting the offer of the key
<sphalerite> but then rejecting the actual auth..?
<clever> pam may be configured to not allow root logins
<clever> cat /etc/pam.d/sshd | uniq
<clever> compare against an x86 that allows ssh to root
<sphalerite> looks identical
<sphalerite> ah well I'll try as a regular user
<sphalerite> and with password
<sphalerite> right it failed for the regular user as well… password worked though
<sphalerite> yeah if I try to run X manually it complains that /dev/tty0 doesn't exist
<sphalerite> clever: ^
<clever> and what about playing with each of the options i previously listed?
<clever> or aiming it at just tty?
<sphalerite> nope
<sphalerite> always tries to open /dev/tty0 unless I pass vtN in which case it tries to open /dev/ttyN
<clever> symlink tty7 to tty?
<sphalerite> no such device or address
<clever> to the source!
<clever> [clever@amd-nixos:~/apps]$ nix-shell '<nixpkgs>' -A xorg.xorgserver
<clever> [nix-shell:~/apps]$ unpackPhase
<clever> unpacking source archive /nix/store/zfc11mgqdxfmsv8rqqky4wsmjpr4vlyp-xorg-server-1.19.6.tar.bz2
<sphalerite> yes you don't need to paste the whole transcript :p
<clever> lol, i already have a 1.17 in this dir
<clever> hw/kdrive/linux/linux.c: snprintf(vtname, sizeof(vtname), "/dev/tty%d", vtno); /* /dev/tty1-64 */
<clever> if kdVirtualTerminal > 0, obey it, else, open tty0 and query for the first free VT
<clever> sphalerite: oh, does /dev/console exist?
<sphalerite> yes
<clever> symlink tty7 to console?
<sphalerite> "No such device"
<sphalerite> Not "No such device or address" this time!
<clever> sphalerite: it may help to attach gdb to xorg and single-step thru LinuxInit()
<clever> or hit it with strace
<clever> strace plus source can help
<sphalerite> I'm not sure that would be fun or really helpful…
<clever> try just running it under strace and throwing it in a pastebin?
<sphalerite> I don't think it'll be helpful, since I'll just be informed that open("/dev/tty7") results in ENODEVICE or whatever
<sphalerite> but ok
<clever> the symlink should send it elsewhere
<clever> and then a certain syscall will trigger the error
<sphalerite> yes
<sphalerite> openat(AT_FDCWD, "/dev/tty7", O_RDWR|O_NONBLOCK) = -1 ENODEV (No such device)
<clever> and `ls -l /dev/tty7` shows?
<sphalerite> lrwxrwxrwx 1 root root 7 Sep 18 00:38 /dev/tty7 -> console
<clever> ah, then opening /dev/console is failing with the same error
<clever> what about ttyS0?
<clever> try cating the nodes first to see if they work with cat
<clever> hw/dmx/input/lnx-keyboard.c: const char *vcs[] = { "/dev/vc/", "/dev/tty", NULL };
<clever> vc/7 appears elsewhere
<sphalerite> (EE) xf86OpenConsole: Switching VT failed even with -novtswitch
<sphalerite> I'm pretty sure X just needs a real virtual console to run
<samueldr> sorry sphalerite, no idea; my research stops at "which devices are interesting, and what good starting points for documentation"
<samueldr> built a kernel or used mainline?
<sphalerite> I used the stock chromeos kernel
<samueldr> ah
<samueldr> it probably has features missing :/
<sphalerite> next step will be to try a nix-built kernel, but I'll need to port the DTBs over from the chromeos tree which is scary
<samueldr> if using mainline, try 4.19 (currently rc4) it may add rk3399 support for $things
<samueldr> or maybe using chromeos kernel tree for gru
<samueldr> (I say 4.19 since the renegade elite, an RK3399 board, mentions it as the first supported mainline kernel)
<sphalerite> cool, thanks for the tips also holy crap it's almost 2am I should really sleep
<samueldr> and finally
<samueldr> probably a good source of infos
<samueldr> for a non-mainline kernel
orivej has quit [Ping timeout: 244 seconds]
<thefloweringash> Linus: Apparently both Kevin and Bob are gru boards. There's a decent chance that booting an image built for my chromebook (kevin) on yours (bob) would JustWork™
<samueldr> thefloweringash: (sphalerite's probably asleep) anywhere you're stashing any relevant nix derivations for such an image?
<samueldr> (and AFAIUI you're most likely right)
<thefloweringash> and here's my source: http://github.com/thefloweringash/kevin-nix
<samueldr> lovely, starring since I'm still interested into getting one of the gru (scarlet, chromebook tab 10)
<thefloweringash> pretty sure he's familiar with it already, but if it works, it seems like a convenient place to start iterating from
<samueldr> ooh, even depthcharge automation
<samueldr> example = "/dev/disk/by-partlabel/kenrel";
<thefloweringash> doh
<samueldr> :) that example may cause issues :D
<samueldr> (and you might want to not default to an empty string, to make it explicit?
<thefloweringash> uh, yeah, why is there a default? thanks for the review :-)
<samueldr> as the sole user, you probably didn't realise :)
<thefloweringash> yeah, I also booted off the image and then did a regular nixos-install, so I could setup f2fs on top of luks, so I'm not using the partition map from the image
<samueldr> on gru you can nuke the whole partition table?
<thefloweringash> I left chromeos alone on the internal storage, and dual boot to a microSD card
<samueldr> on veyron (whichever sphalerite has) and on veyron mickey, it seems the emmc has trouble being written around where the primary GPT is
<samueldr> oh right
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 244 seconds]
Thra11 has joined #nixos-aarch64
Thra11 has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
lopsided98_ has joined #nixos-aarch64
lopsided98 has quit [Ping timeout: 276 seconds]
<sphalerite> error: while setting up the build environment: mounting /proc: Operation not permitted
<sphalerite> :( the stock kernel also doesn't seem to play along well with the sandbox
lopsided98_ has quit [Ping timeout: 240 seconds]
lopsided98 has joined #nixos-aarch64
<sphalerite> samueldr: none of the funky write-protection business on the bob by the looks of it
<sphalerite> aww, the testing kernel isn't cached
orivej has quit [Ping timeout: 252 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
<sphalerite> I am very tempted to use a community-box-built kernel for the new chromebook >_<
orivej has quit [Ping timeout: 250 seconds]
<sphalerite> clever: AFAICT X needs to open the console to tell the kernel to switch into graphics mode (ioctl KDSETMODE)
<sphalerite> not sure exactly what that actually entails
orivej has joined #nixos-aarch64
<samueldr> sphalerite: pretty sure you can and should use the community box to build
<samueldr> (unless you don't trust it)
<sphalerite> samueldr: oh yeah I will use it to build but the repo has a big scary warning saying you shouldn't trust it :)
<sphalerite> "TLDR: a trusted but malicious actor could hack your system through this builder. Do not use this builder for secret builds. Be careful what you use this system for. Do not trust the results. For a more nuanced understanding, read on."
<sphalerite> and under the "Want access?" heading: "You must read literally this entire README. It is critically important that you do so."
<sphalerite> :p
orivej has quit [Ping timeout: 252 seconds]
orivej has joined #nixos-aarch64
<clever> sphalerite: that depends heavily on the gpu drivers
<clever> sphalerite: the drivers are totally able to ignore KDSETMODE and just do whatever they want
Thra11 has joined #nixos-aarch64
FRidh has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
jtojnar has quit [Ping timeout: 252 seconds]
samrose has joined #nixos-aarch64
<samrose> I feel like I am very close, trouble shooting "unable to use mmc 1" on boot of nixos on bananapim64
<sphalerite> ooh exciting!
orivej has joined #nixos-aarch64
FRidh has quit [Quit: Konversation terminated!]
samrose has quit [Quit: Page closed]
samrose has joined #nixos-aarch64
duncan^ has quit [Ping timeout: 240 seconds]
orivej has quit [Ping timeout: 252 seconds]
Thra11 has quit [Ping timeout: 240 seconds]
duncan^ has joined #nixos-aarch64
<duncan^> it's a terrible tablet soc
<duncan^> they used to make the allwinner a10 for awful PDA devices
<duncan^> this is the a10 without the ethernet and some other features
<duncan^> that being said there was an awesome post https://dzone.com/articles/embedded-linux-on-a-2-layer-board
<duncan^> which I guess could be updated with that
<samueldr> The R8 is a rename of A13, and primarily targeted towards low-budget IoT devices.
<samueldr> which was used in the pocket chip
<grw> i had one of those, and this thing: https://licheepizero.us/
<grw> seems a bit obselete though
<grw> nanopi duo is same-ish size and much more powerful
<grw> i guess costs more tho, $ and power
<samueldr> released around the same time or not?
<samueldr> (that makes a huge difference :))
<grw> i think a few months later
<grw> CHIP had big supply issues iirc, nothing shipped for a long time
<grw> this licheepi thing was a one-man project, also very late shipping