t184256 has left #nixos-aarch64 ["Disconnected: Replaced by new connection"]
t184256 has joined #nixos-aarch64
sphalerite_ has joined #nixos-aarch64
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
sphalerite has quit [Quit: WeeChat 2.4]
sphalerite_ is now known as sphalerite
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 272 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 248 seconds]
orivej has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 245 seconds]
jtojnar has joined #nixos-aarch64
orivej has quit [Ping timeout: 272 seconds]
orivej has joined #nixos-aarch64
ryantrinkle has joined #nixos-aarch64
orivej has quit [Ping timeout: 268 seconds]
orivej has joined #nixos-aarch64
wildtrees has joined #nixos-aarch64
wildtrees has quit [Max SendQ exceeded]
wildtrees has joined #nixos-aarch64
orivej has quit [Ping timeout: 268 seconds]
wildtrees has quit [Quit: Leaving]
Thra11 has joined #nixos-aarch64
<Thra11>
After a not-quite-successful boot from an SD-card, where on the card can I find the journal or other useful logs, once I've mounted the SD card under a working system?
<samueldr>
journalctl with -D I guess
<samueldr>
likely under /var/log/journal/
<samueldr>
so something like journalctl `-D /mnt/var/log/journal/ -b0` -b0 for the last boot
<samueldr>
that is, if it booted far enough to log and the journal flushed
<samueldr>
else, it's probably wise to hook to serial
<Thra11>
var/log only contains two files, "lastlog" and "wtmp"
ris has joined #nixos-aarch64
<Thra11>
both empty
<samueldr>
I guess it hasn't booted far enough to log to the journal and flush
<samueldr>
is it from sd_image?
<samueldr>
if so, is the main partition resized to fill the sd_card?
<samueldr>
if so, it means that it at least went far enough in stage-1 to do filesystems manipulation
<Thra11>
Watching the uart and hdmi output, it *looks* like it's reaching the login prompt
<samueldr>
oh
<Thra11>
Although oddly enough, it's not doing the partition resize
<samueldr>
any other storage on the device?
<samueldr>
it looks for partitions by label
<samueldr>
if you have a usb drive or an eMMC with the right partitions labels it might end up booting that instead of the usb drive
<samueldr>
instead of the sd card*
<samueldr>
(I don't know what's the target board here :))
<Thra11>
Oddity #2: It couldn't find the root partition by LABEL=NIXOS_SD, but it can if I put root=/dev/mmcblk1p2
<Thra11>
I'll try disconnecting the eMMC just in case it's confusing it.
<samueldr>
werid
<samueldr>
weirD*
<samueldr>
ugh, typing
<Thra11>
Board is a RockPro64. Trying to boot downstream 5.3 kernel
<samueldr>
ah!
<Thra11>
Is that the "ah!" of a person who has seen such weirdness and found all the solutions?
<samueldr>
maybe not since you said "it looks like it booted to the login prompt"
<samueldr>
I think it's more likely that the eMMC is confusing the initrd
<samueldr>
(from the few bits of infos I have here)
<Thra11>
w.r.t login prompt, it appears on the hdmi output, then flickers on and off for a while, eventually ending up with just a flashing "_". No login prompt appears on the uart, not sure if I need to tweak "console=<something>" on the kernel command line
orivej has joined #nixos-aarch64
<Thra11>
"[FAILED] Failed to start Login Service. See 'systemctl status systemd-logind.service' for details." <- Well that sucks.
<samueldr>
hmmm
<samueldr>
you say the partition didn't resize, right?
<samueldr>
is it... too full?
<Thra11>
Looks like there are lots of other failures. I'll have a read through the uart output.
<samueldr>
I *think* I've had this issue beforehand
<samueldr>
though I thought I added enough slack space for this not to happen
koral has joined #nixos-aarch64
<koral>
Hello
<koral>
I am trying to install NixOS on a Raspberry Pi 3 B+ ; the nixos image for SD card boots fine, but as soon as I `nixos-rebuild switch` with a custom configuration.nix, HDMI stops working after reboot
<Thra11>
samueldr: Presumably it's simple enough to test by building an image with *plenty* of space
<samueldr>
koral: if you're using linuxPackages_latest, for now don't; there's an annoyance with how our configuration is made to use the dtbs
<samueldr>
(unverified, though I suspect this is the case)
<samueldr>
I don't have a B+/A+ pair to confirm
<samueldr>
Thra11: or you could resize (with e.g. gparted) the partition offline in your case
<samueldr>
Thra11: that would at least let you know whether it is that or not
<koral>
samueldr: which one should I use then ? according to the wiki, linuxPackages_rpi is for RPi 1 only
<samueldr>
don't configure it, it'll use the same default as it did for the initial build; which is the lastest LTS; linuxPackages
<samueldr>
latest LTS*
<koral>
oh, okay, let me try that
<samueldr>
the issue is (from my flawed memory) the DTB filename changed from the mainline kernel, after the release of the A+, but our u-boot build doesn't know that
<koral>
FYI, the HDMI issue I am having is exactly the one described in the wiki: the display hangs on "Starting kernel..."
<samueldr>
it's the same symptom, but likely not related in that case
<samueldr>
(if it's what I think it is)
<samueldr>
the "Starting kernel..." message is the last thing u-boot printed while it was in control
<samueldr>
so it could be for _any_ reason where the kernel couldn't start using the display
<samueldr>
(making this hard to properly diagnose!)
<koral>
I can actually guess that NixOS booted correctly because if I blindly log as root and blindly type "reboot", it does reboot
<samueldr>
that's one of the diagnostic steps :)
<koral>
I don't have a serial connection available unfortunately
<samueldr>
if it isn't a one-off that you're going to do SBC stuff, it's worth its weight in gold to have the serial cable
<samueldr>
can be useful for non-SBC stuff too :)
<koral>
it works :D
<koral>
thank you sir !
<samueldr>
I'll add a note to the wiki page about that current issue
<samueldr>
it might be really hard to get right
<koral>
oh, didn't know I was actually exploring unknown territory :D
<samueldr>
since you either lose compatibility pre-change in u-boot, or lose compatibility post-change in u-boot
<samueldr>
not exactly unknown, another user had a similar (the same I think) issue the other day
Thra11 has quit [Ping timeout: 244 seconds]
<koral>
while I am at it, do you need specific information about the issue that may help you fix it ?
<samueldr>
I don't think so, I'm not sure
<samueldr>
it might not be exactly what I described (can't find proof from the sources)
<samueldr>
not entirely sure how you should do that
<samueldr>
but that's a u-boot option
<Thra11>
Ah. ok
<samueldr>
so, AFAIUI you're basically skipping the initrd entirely
<samueldr>
(which didn't load for some reason)
<samueldr>
the reason might be that it's being overwritten by the kernel
<samueldr>
at least, I'm reasonably confident
<Thra11>
Yes. I guess I've manually told it to skip it by fiddling with the command line, because when I didn't it just failed because the initrd was being overwritten
<Thra11>
*flashbacks to a very similar situation with an imx6 at work several years ago*
<samueldr>
plus ça change, plus c'est pareille ;)
<Thra11>
samueldr: I'll try setting ramdisk_addr_r tomorrow evening. Thanks for your help!
<samueldr>
you're welcome
<DigitalKiwi>
cana kit has raspberry pi 4 4gb
<DigitalKiwi>
err i think they have other ones too that's just the one i was on
<samueldr>
I have received mine it's been a good while
<samueldr>
though for a while it wasn't available standalone, only in "kits"
<DigitalKiwi>
oh
<DigitalKiwi>
soo nixos on it soon eh? :P
<samueldr>
some users already have it booted using the usual raspberry pi foundation boot chain
<samueldr>
u-boot is supposedly working
<samueldr>
though last I tried (when the patch set was shared) I didn't get it to work
<samueldr>
have been busy
<samueldr>
I was hoping that the changes required to tianocore would land soon enough
<samueldr>
I would personally prefer nudging towards EFI