<DigitalKiwi>
how do i make the /boot not be 30M :(
<thefloweringash>
Complaining on irc seems to have fixed my build. I should have complained earlier
<DigitalKiwi>
oh in that case
<DigitalKiwi>
I'd like to file a complaint about my 30M boot
vika_nezrimaya has quit [Ping timeout: 240 seconds]
<thefloweringash>
is it smaller yet?
<thefloweringash>
what's the story with /boot ?
<DigitalKiwi>
/dev/mmcblk0p1 30M 30M 0 100% /boot
<DigitalKiwi>
it made my nixos-rebuild fail :<
<thefloweringash>
I normally make ~512mb for /boot, don't know what the recommended value is
<thefloweringash>
are you using the firmware partition for /boot?
<DigitalKiwi>
yeah
<thefloweringash>
might I recommend not doing that? :-)
<DigitalKiwi>
what do i do instead
<DigitalKiwi>
update: it is now larger
<thefloweringash>
general idea is leave the firmware partition alone, and put kernels/images/dtbs elsewhere. I think modern sdImages do this by mounting the firmware partition on /boot/firmware putting kernels on the root (under the /boot directory), don't know what device or setup you have though
<samueldr>
it depends which image is being built
<samueldr>
is it using u-boot or booting the kernel directly using config.txt?
<samueldr>
using config.txt you've got less flexibility
<samueldr>
(here I assume a raspberry pi from previous discussions)
<samueldr>
if it's using u-boot, the default assumption since 19.09 is that the FAT32 partition is an "opaque blob" for the raspberry pi 3
<samueldr>
(4 pending)
<DigitalKiwi>
rpi 3b+
<samueldr>
though I'm not sure when not using u-boot, if the image builder defaults to the same diminutive size
<thefloweringash>
is not using u-boot typical?
<samueldr>
on raspberry pi it seems some people want to do it
<samueldr>
mainly with the raspberry pi kernel and dtoverlay and shenanigans from config.txt
<samueldr>
but one thing for sure is that "converting" a u-boot generic image to booting the kernel with config.txt the small size of the partition is going to cause grief
<DigitalKiwi>
can i resize it
<DigitalKiwi>
well i mean i did
<DigitalKiwi>
but kind of
<DigitalKiwi>
gparted failed to resize it
<samueldr>
you can produce an SD image with different parameters
<DigitalKiwi>
so i copied the contents and then deleted it and made one bigger and copied back
<DigitalKiwi>
it booted at least
<samueldr>
the easy way is to checkout nixpkgs and tweak the files
<samueldr>
yeah, the small size makes mkfs.fat make a FAT16 partition iirc
<samueldr>
which has a smaller maximum size
<samueldr>
(i assume could have been the issue)
<DigitalKiwi>
oh i reformatted it as fat32 too
<samueldr>
the raspberry pi 3 family is not fussy with partitions though
<samueldr>
no issue there
<DigitalKiwi>
because yeah fat16 wasn't having the 512
<samueldr>
as long as there's a FAT partition on MBR with its fancy files it'll use those
<samueldr>
though, if you're still using u-boot, it's recommended to not mount a partition for /boot, but rather leaving it at the root of the fs
<samueldr>
as u-boot just reads from the ext4 fs
<DigitalKiwi>
i don't know if i'm using u-boot
<samueldr>
this mirrors the other u-boot-based setups
<samueldr>
if you downloaded an image from hydra, "nixos.sd_image.aarch64", it's a generic image where the FIRMWARE partition is intended to be used as an opaque blob hosting u-boot
<samueldr>
docs really need to be written about that :(