|
I have been thinking some more about this case. The patch from my first attempt does not seem very safe in case the device shut downs while it is clearing out and recreating symlinks to correct boot files. Now I have another idea, but I haven't had time to write a patch yet.
> Or even just unconditionally do it if the files exist.
That is what I was thinking; if files are there, just copy them to /boot partition.
> Are there any "defacto" standards for the locations of DT blobs etc.?
I am not aware of any, but I have looked at 6-7 reference devices and all of them keep DTBs in top level /boot.
> Currently the status quo in at least Fedora/Anaconda/OSTree is that Anaconda lays down all these additional files in /boot, then OSTree never touches them again.
I did that too initially, until I realized that it is not sufficient for all update
scenarios.
> One thing we could do as well is canonically store kernel/initramfs in /boot to avoid
duplication. The reason this isn't done by default is that it would require introducing a messy
special case into the generic "git-like" filesystem layer.
I am unsure what that would involve since I have not looked at the ostree repo handling code, but what I currently have in mind is (in u-boot context):
1) copy over everything that was committed under /boot. That usually would be - kernel, initramfs, DTBs, uEnv.txt / bootscript and on some systems boot loader binary itself. It is not a big amount of duplicated data, so it shouldn't be a problem for most people.
2) Then in ostree's u-boot handling code:
Add an extra record in the generated uEnv.txt - "boot-files=" and append contents of ${boot-files}/uEnv.txt (if it exists) to the generated
uEnv.txt. So now the generated uEnv.txt would look something like this:
kernel_image= ramdisk_image= bootargs= boot-files=/ostree/myos-ed14d566f2269a394e49ae5bbebb3dead181fb189d50163eb3aad71d6c997d75/ contents of /ostree/myos-ed14d566f2269a394e49ae5bbebb3dead181fb189d50163eb3aad71d6c997d75/uEnv.txt
The above would work also for the case where u-boot expects to find compiled ${bootscript} in the top level /boot. When preparing an initial sysroot, simply put a ${bootscript} in the top level /boot whose only task is to source the /boot/loader/uEnv.txt file to find the updated version of compiled bootscript in ${boot-files}/${bootscript}.
This would allow you to update everything except the boot loader binary itself, which is out of scope for ostree anyways.
How grub could handle this I don't know, because I don't see anything like the "bootargs" in the
http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ Also the same spec says " wants a file, not a path.
From: ostree-list <ostree-list-bounces gnome org> on behalf of Colin Walters <walters verbum org>
Sent: Sunday, October 25, 2015 4:32 PM To: ostree-list gnome org Subject: Re: 2 partition setup where /boot partition contains more than just kernel and initramfs images. On Wed, Oct 21, 2015, at 05:32 AM, Paeglis Gatis wrote:
We could have build-time options to enable some things like this. Or even just unconditionally
do it if the files exist. Are there any "defacto" standards for the locations of DT blobs etc.?
One thing we could do as well is canonically store kernel/initramfs in /boot to avoid
duplication. The reason this isn't done by default is that it would require introducing a messy
special case into the generic "git-like" filesystem layer.
Possibly yes- there are things like boot splash images. Currently the status quo in at least
Fedora/Anaconda/OSTree is that Anaconda lays down all these additional files in /boot, then
OSTree never touches them again.
But I can certainly imagine wanting to be able to atomically update the boot splash
with major version updates etc.
|