orivej has quit [Ping timeout: 256 seconds]
cstrahan has joined #nixos-aarch64
<cstrahan> Dezgeg et al: I'm trying to use the install image for aarch64 on RasPi 3, but when my Pi boots, it gets stuck on "Starting kernel ..."; any advice on what to do from here?
<samueldr> cstrahan: try switching VT (ctrl+alt+F2 then ctrl+alt+F1)
<samueldr> there is some issues with the vc4 modesetting driver which makes it show the last uboot messages "seemingly at random"
<cstrahan> samueldr: Ah, I should note that I'm connected via the UART.
<samueldr> oh
<samueldr> then you don't have the console active :)
<samueldr> it isn't active by default
<samueldr> you could manually "fix" the extlinux.conf file in the FAT partition to add console=ttyS0,115200n8 to the cmdline
<samueldr> haha, just realized, what's funny is that both problem look the same! you're seeing the last message from uboot whether on serial or with the vc4 modesetting issue :)
<cstrahan> samueldr: it looks like extlinux.conf already has that: APPEND systemConfig=/nix/store/in1n8id4flwcd6pdj7c1wcrs6p09wg06-nixos-system-nixos-18.03.git.9b25b9347d9 init=/nix/store/in1n8id4flwcd6pdj7c1wcrs6p09wg06-nixos-system-nixos-18.03.git.9b25b9347d9/init loglevel=7 console=ttyS0,115200n8 console=ttymxc0,115200n8 console=ttyAMA0,115200n8 console=ttyO0,115200n8 console=ttySAC2,115200n8 console=tty0
<cstrahan> and it looks like Dezgeg's images should already have the kernel param set here: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/installer/cd-dvd/sd-image-aarch64.nix#L37
<samueldr> hmm, I was going from memory
<samueldr> and I'm guessing you're on your first boot with the image, not after a rebuild, right?
<cstrahan> samueldr: yep, first boot.
<cstrahan> (I'm hoping I can figure this out on the Pi as a sort of sanity check, but what I really want to do ultimately is get NixOS supported on the Rock64 :P )
<samueldr> thing is, I have my pi sitting at hands reach in front of me... but I'm battling with early 2000 tech on my workstation to get triple screen working :|
<cstrahan> Ah, so I hooked it up via hdmi to my TV and I see it boot successfully (at least, past the "Starting kernel..." and all the way up to asking for credentials), so the image overall seems to work -- it just seems that Linux isn't isn't printing anything over the serial connection ...
<samueldr> asking for credentials?
<samueldr> I thought it defaulted to a root shell
<cstrahan> Err, yeah -- just noted it defaults to password-less root / auto login
<cstrahan> I wasn't looking all that closely -- just enough to see that it booted successfully :)
<samueldr> weird, especially since uboot seemingly showed the boot
<samueldr> and you tried sending keypresses over serial?
<samueldr> maybe it felt a bit sleepy (definitely not the technical term)
<cstrahan> Yeah, nothing was echoed back
<cstrahan> So I see getty running on ttyAMA0, but not ttyS0 -- is that to be expected?
<samueldr> I wouldn't know
<samueldr> especially since the wiki page seems to say rpi3 uses ttyS0
<cstrahan> And, FWIW, some cursory reading online shows that ttyAMA0 might be used for bluetooth, unless that's disabled. This is all about as clear as mud to me :/
<samueldr> cat /proc/cmdline to see how it booted
<samueldr> ttyAMA0 is a name that can be used for *anything serial* and including some bluetooth control device
Acou_Bass has quit [Ping timeout: 260 seconds]
<cstrahan> Aha! On a hunch, I tried
<cstrahan> # systemctl start serial-getty@ttyS1.service
<cstrahan> - and that worked! I immediately saw my bash prompt over the usb serial connection on my laptop.
<cstrahan> samueldr: thanks for the advice!
Acou_Bass has joined #nixos-aarch64
Acou_Bass has quit [Ping timeout: 276 seconds]
Acou_Bass has joined #nixos-aarch64
<cstrahan> Strangely, adding console=ttyS1,115200n8 to the kernel command line doesn't result in systemd starting getty on ttyS1...
<cstrahan> Curious if I'll have to resort to adding systemd.services."serial-getty@ttyS0".enable = true; to my config.
<cstrahan> err, meant: systemd.services."serial-getty@ttyS1".enable = false;
<cstrahan> Well, you get the idea... My copy-paste-edit-fu is failing me at this hour.
Acou_Bass has quit [Ping timeout: 256 seconds]
<samueldr> weird, I really want to go back to NixOS on ARM stuff, but last time I tried, december IIRC, it worked
<samueldr> it worked with pine64 lts, orange pi pc, and rpi3
<samueldr> and rpi1 too
chris| has quit [Quit: ZNC 1.6.5 - http://znc.in]
chris| has joined #nixos-aarch64
chris| has quit [Ping timeout: 248 seconds]
chris| has joined #nixos-aarch64
Acou_Bass has joined #nixos-aarch64
Acou_Bass has quit [Ping timeout: 260 seconds]
Acou_Bass has joined #nixos-aarch64
vcunat has joined #nixos-aarch64
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
alunduil has quit [Quit: leaving]
alunduil has joined #nixos-aarch64
orivej has joined #nixos-aarch64
buovjaga has joined #nixos-aarch64
<buovjaga> Dezgeg: I'm experimenting with building my own images under qemu. I changed the bootSize default to be 1024, but then I get this failure when building: "Total number of sectors (2097152) not a multiple of sectors per track (63)!" What am I missing?
<Dezgeg> hmm
<buovjaga> I must confess I also changed the ext4 partition to f2fs, but it seemed to go fine (I paid careful attention to details)
<Dezgeg> I suppose the mcopy line needs MTOOLS_SKIP_CHECK=1 prefixed to it
<Dezgeg> in sd-image.nix
<buovjaga> here is the whole relevant output https://paste.simplylinux.ch/view/520dbf1f
<buovjaga> ok, if it's harmless to skip it I will :) thanks
<cstrahan> grahamc: I'm having some trouble using the community/Packet aarch64 machine -- when I follow the README directions and proceed to nix-build, I get the following message: unable to open SSH connection to 'ssh://cstrahan@aarch64.nixos.community': cannot connect to 'cstrahan@aarch64.nixos.community'; trying other available machines...
<cstrahan> any idea what I might be doing wrong?
<vcunat> direct ssh works?
<vcunat> I'd be also careful about which ssh key is used by nix...
<cstrahan> vcunat: yeah, direct ssh works fine.
<cstrahan> what sort of care should I take wrt the ssh key used by nix?
<cstrahan> I am using the unstable branch of Nix, so I suppose it's possible something broke there. Is anyone using unstable with remote ssh builders successfully?
<vcunat> I meant - it might be using a different key than you expect.
<vcunat> (different than the one configured on the target box)
<cstrahan> vcunat: oh, gotcha. i've double checked, and I've definitely specified the right key.
<cstrahan> hm... reverting back to stable didn't fix things.
<LnL> is this with nix 2.0?
<vcunat> with both, apparently
<LnL> make sure the key is owned by root and that root's known_hosts are ok
<cstrahan> oh gosh, I completely forgot my ssh key has a password.
<vcunat> :-) there are many pitfalls
<clever> then it would only work if nix-daemon has access to an agent i think
<LnL> heh, that would do it
<clever> better to make another key for nix's use
<vcunat> I'm just now building on that very box through nix-2.0
<vcunat> I created a separate key for nix builders.
<clever> LnL, cstrahan: i also prefer using this nixos option over ~/.ssh/known_hosts: https://nixos.org/nixos/options.html#programs.ssh.known
<clever> i can put the host pubkey for every machine i commonly use into a common.nix, then add that to imports for every machine
<LnL> yeah! I really want to add that to nix-darwin
<clever> and now they all automaticaly know who to trust
<clever> you cant even mitm me on the first session
<cstrahan> clever: nice!
<clever> its also in /etc/ so all users on the machine trust it
<gchristensen> Can someone send a PR adding docs about the password caveat?
<vcunat> it's in docs of nix.buildMachines
<vcunat> > The SSH private key should not have a passphrase, and the corresponding public key should be added to ~sshUser/authorized_keys on the remote machine.
<vcunat> Though I suppose you wouldn't read that on Darwin :-)
<cstrahan> gchristensen: Thanks, btw, for setting up (and maintaining) this infrastructure :P
<gchristensen> =)
<gchristensen> Yeah better to put it in those docs directly
buovjaga has quit [Remote host closed the connection]
<cstrahan> gchristensen: I opened a PR to add that warning to the README: https://github.com/nix-community/aarch64-build-box/pull/18/files
<cstrahan> gchristensen: Also, do you think you might be able to bump the nixpkgs version soonish (per https://github.com/nix-community/aarch64-build-box/issues/17 )?
<cstrahan> I'm working on support for NixOS on the Rock64 (https://www.pine64.org/?page_id=7147), and I'd really rather have the Packet instance do the heavy lifting, rather than waiting forever for my RPi to e.g. build the Linux kernel :P
<gchristensen> Yes
<cstrahan> Awesome - thanks a ton!
<dtz> oh yay came here to ask about /bin/sh fixing but wasn't sure what it'd entail, hooray there's an issue on it already ^_^
<cstrahan> :P
<gchristensen> builder for ‘/nix/store/1m7aympsbpw7cgkfrplhqf2m6pxg9w16-strace-4.21.drv’ failed with exit code 1
<gchristensen> anyone have a known good version to use here?
<gchristensen> latest nixos-unstable-small seems to work
<gchristensen> ok its rebooting
vcunat has quit [Quit: Leaving.]