Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Fix some pitfalls from the Raspberry Pi 4 specific sd image #90119
Motivation for this change
The SD image is not exactly trivial to use if you are not intimately knowledgeable of the way our default generic aarch64 image is built. That is, we have only shoe-horned the rpi4 kernel, and rpi boot chain on top of that default image.
This change aims to square the circle, and make it less trivial to get things wrong.
The main change is that we are naming the FAT32 partition something more obvious for this use case,
This is needed since I haven't managed to get
What does this change??
Well, mainly, it makes the difference in this image, compared to the default, much more obvious. Hopefully fixing the issue where users ended up confused with boot "reverting" to an old generation.
The main thing to look out for, is that we're going to have to ask users to list from
I had a "first boot" boot once, though could not reproduce with a fresh image, where the
This was tested using cross-compilation, and using #89717 commits.
Verified to boot on a raspberry pi 4.
Oops, completely forgot that that PR existed even.
Though yeah, this is a more "proper" fix, in my opinion, as we are properly making the distinction between the "FIRMWARE" partition for mainline-based devices, and this "this is actually the boot partition" setup.
The way this ends up being called with the raspberry pi 4 image builder ends up not using the `-e` from the shebang. In turn, the builds fails during cross-compilation. The wrong coreutils ends up being used, but this is not made apparent. The issue I faced is already fixed on master, but this ensures no one ends up with a failed build "succeeding".
This will be helpful in the now too-long-lived image for the Raspberry Pi 4. We'll be able to properly configure the partition to be useful.
This should have been done initially, as otherwise it gets awfully awkward to boot into new generations by default. This system-specific image wasn't expected to be long-lived, thus why it didn't end up being polished much. Reality shows us we may be stuck with it for a bit longer, so let's make it easier to use for new users.
Because this is meant to produce an official image for a popular platform that is hard to get a setup.
Though it seems to me the question is loaded. Are you trying to mount an argument for NixOS/rfcs#70 out of this? Because I would agree this system-specific image shouldn't be part of Nixpkgs, but pragmatically speaking there was no other way to get the organization's Hydra building the images at the moment it was conceived. In my opinion this is a shining example of churn that I don't want to see inside of Nixpkgs.
While this is not something I want to see as part of Nixpkgs, and this is intended to be removed as soon as the generic image can boot on this dreadfully annoying piece of non-standard hardware, it is the most common gateway into getting a foothold in NixOS on ARM. It needed some maintenance, so I did it, instead of having to support user after user falling into the same pitfalls.
but pragmatically speaking there was no other way to get the
organization's Hydra building the images at the moment it was conceived. Which is an argument for more monorepo, not less monorepo and more infrastructural overhead.…
On Sun, Jun 21, 2020 at 11:00 PM Samuel Dionne-Riel < ***@***.***> wrote: Because this is meant to produce an official image for a popular platform that is hard to get a setup. Or are you trying to mount an argument for rfcs#70 out of this? Because I would agree this system-specific image shouldn't be part of Nixpkgs, but pragmatically speaking there was no other way to get the organization's Hydra building the images at the moment it was conceived. In my opinion this is a shining example of churn that I don't want to see inside of Nixpkgs. Note that on the original PR adding this system I voiced my concerns <#68265 (comment)>. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#90119 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAYB5ZSUI2NEXS6S5JYP4LLRXZYIBANCNFSM4N3AYIGA> .