<clever>
wacke: have you tried just using `nixos-generate-config` ?
<wacke>
yes, was the same result
<clever>
wacke: that typically happens if systemd is told to mount the wrong thing somewhere, and it panics due to not finding it
<wacke>
hmm, i looked up: /boot is not mounted, but defined like in the template from wiki
<wacke>
hmm, /boot is not empty
<clever>
wacke: what did you put into the config for /boot ?
<wacke>
raspberryPi = {
<wacke>
version = 4;
<wacke>
enable = true;
<wacke>
};
<wacke>
ah sorry
<wacke>
ahm, can't copy, the snippet from template from the wiki
<wacke>
"/boot" = {
<wacke>
fsType = "vfat";
<wacke>
device = "/dev/disk/by-label/NIXOS_BOOT";
<wacke>
};
<wacke>
this one
<clever>
wacke: and if you run `blkid /dev/mmc*`, does the boot partition actually have a label of NIXOS_BOOT?
<wacke>
no, listing /dev/disk/by-label shows FIRMWARE, NIXOS_SD, part2
<clever>
then thats your problem
<wacke>
thx
<clever>
you need to use the right label in the nixos config
<clever>
nixos-generate-config will auto-generate the right config
<wacke>
ok, i'll try
<wacke>
nixos-generate-config does not mention FIRMWARE, i'm not sure whether i should mount it on /boot
<wacke>
or just leave NIXOS_SD as the only mount on /
<clever>
wacke: what did nixos-generate-config do about /boot ?
<wacke>
nothing
<clever>
wacke: are you reading hardware-configuration.nix?
<wacke>
yes
<clever>
wacke: was /boot mounted when you ran it?
<wacke>
i think, because on the current system /boot is not mounted
<clever>
nixos-generate-config detects what is currently mounted, and makes config to keep it mounted
<wacke>
so if i mount FIRMWARE on /boot, i see files like *.dtb, bootcode.bin, cmdline.txt, config.txt, *.dat, initrd, kernel.img, *.elf, is this the right boot partition and should be mounted on /boot?
<clever>
yeah
<wacke>
if i umount /boot, i see 2 folder extlinux and nixos
<clever>
if /boot wasnt mounted when you ran nixos-rebuild, it will have dropped files in the /boot dir of /
<wacke>
ahh
<clever>
i always `chmod 0 /boot` before i mount it, so such mistakes fail with an error
<wacke>
updating the boot generations directory...
<wacke>
cp: error writing '/boot/old/zwiwdi73581p27cdlqc1zk36hh06azj0-initrd-linux-5.4.7-initrd.tmp.1999': No space left on device
<wacke>
warning: error(s) occurred while switching to the new configuration
<wacke>
hmm
<wacke>
/boot is 128m in size
<clever>
wacke: try going back to an older generation, and double-check what is actually mounted to /boot
<samueldr>
(oh, and making a serial cable is rather trivial if you have a TRRS plug, but I gather you don't :))
<fadenb>
you are a few steps further then me, I was just frankensteining (ist that a word?) existing images together with nixos ;)
<samueldr>
ist a word enough :)
<samueldr>
right now I'm "stuck" compiling the cross stuff for aarch64 for 19.09, since I intend to allow one to cross-build it in case they don't have an aarch64 host to build on
<samueldr>
the boot order is, set in hardware: SPI, eMMC, SD
<samueldr>
so to test u-boot it's easier to erase the start of the eMMC so it won't find a valid u-boot
<samueldr>
the u-boot built by mrfixit, and some (most?) of the community u-boots will *look* in SD first
<fadenb>
I just erased the eMMC a few minutes ago as it was starting things I did not reference. Took me a while to realize it loaded some leftover extlinux.conf on the eMMC
<samueldr>
haha
<samueldr>
the first thing I did with my PBP was look at hardware defects, there seemed to be none, then erase the eMMC
<samueldr>
the default distribution is... quite bad
<samueldr>
kinda put me off seeing how they worked actively with that dev and it's an insecure mess of hacks
<fadenb>
yeah, good enough to check that everything is working but not a setup I would like to use permanently
<samueldr>
they don't even have display init with u-boot (neither does mainline)
<samueldr>
fadenb: root and user passwords are well-known, and it defaults to start an sshd
<samueldr>
and not positive, but IIRC defaults to root login permitted with password
<fadenb>
I believe someone on the forum already pointed that out, can not remember what the response to it was
<samueldr>
it was pointed out on IRC too
<samueldr>
IIRC the response was that it wasn't an issue
<samueldr>
there are other issues IIRC
<samueldr>
that reaaaaally deflated me
<samueldr>
also the fact that u-boot had no GFX init, which means no generation selection
<fadenb>
I believe they are still in "get it working" mode so I think that is OKish
<samueldr>
though that's something I'm fixing with Mobile NixOS right now
<samueldr>
since phones, too, don't have a way to select a generation, working on a "stage-0" program to choose a generation at boot
<samueldr>
since the kernel does have gfx init with the pbp, that should be useful there too
orivej has quit [Ping timeout: 265 seconds]
FRidh has quit [Quit: Konversation terminated!]
orivej has joined #nixos-aarch64
wacke has quit [Ping timeout: 260 seconds]
orivej has quit [Ping timeout: 268 seconds]
<Raito_Bezarius>
Is it expected that even if I create a SD image with "services.openssh.enable = true;" sshd won't start on the image?
<Raito_Bezarius>
For some reason, I don't see the RPi connected to the WiFi even with "networking.wireless.enable = true;" and some AP
<samueldr>
Raito_Bezarius: yes
<Raito_Bezarius>
samueldr: ah… is there a way to force start it?
<samueldr>
I was extremely lazy and re-used iso-image/installation-cd-base for the initial setup of mobile nixos' demo :)
<Raito_Bezarius>
oh I never thought of using USB to have SSH, but I suppose it requires OTG cable
<samueldr>
oh, I don't imply that here...
<samueldr>
that's a special case of usb rndis for phones :)
<Raito_Bezarius>
# FIXME : Stop relying on initrd for `ssh` via USB.
<Raito_Bezarius>
Yeah, but it gave me this idea in fact
<Raito_Bezarius>
Nothing prevent me from using an USB gadget to set up some networking through USB, I guess?
<samueldr>
your device has to support being a usb gadget, most ARM SBCs somehow have support in some ways, but a good chunk of those can't use it since it's behind a hub or something inane like that
<Raito_Bezarius>
Hmm, you're right, RPi might be one of those behind a hub
<samueldr>
in most cases yes
<samueldr>
though rpi4's is not, it's the powered port
<samueldr>
and I *think* it's the 2/3 A that would be fine too, but not sure
<Raito_Bezarius>
(The easy fix is to go "wireless" then and set up some hostapd, but I don't need, I'll just remember it as an idea for some future projects)
<samueldr>
the compute modules and zero boards are fine though
<Raito_Bezarius>
I see
<Raito_Bezarius>
Thank for the tips
<Raito_Bezarius>
I finally succeeded into building an aarch64 image through some native ARM machine on Packet in the end
<Raito_Bezarius>
I didn't have enough time to test the "git checkout <some revision w/o cptofs>" or to dig in the cptofs issue