Re: 2 partition setup where /boot partition contains more than just kernel and initramfs images.

["Jasper St. Pierre" <jstpierre mecheye net>]

Hi,

At Endless, we use uboot's Flattened Image Tree (FIT) image format,
which bundles the kernel and devicetree together in one blob. This we
can ship as the kernel in an OSTree image.

Given an .its file, you can create a FIT image with `mkimage -f
foo.its foo.itb`. We have an example of an .its file which includes a
devicetree here:
https://github.com/endlessm/linux-meson/blob/master/amlogic.its

On Sun, Oct 25, 2015 at 10:26 AM, Paeglis Gatis
<Gatis Paeglis theqtcompany com> wrote:
> 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 "devicetree refers to the binary device tree to use when executing
> the kernel." Strange that devicetree
>
> 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:
>
>
> Hello,
>
>
> On u-boot based systems there often might be other files that need to be
> updated together with kernel/initramfs updates - like device tree blobs
> (actually several of these if you want to
>
> reuse the same kernel on several devices), uEnv.txt or compiled boot script,
> and maybe even second stage bootloader or what not. Updating only
> kernel/initramfs and skipping all these
>
> other files might result in system that does not boot.
>
>
> 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 way to workaround this issue is to keep your whole sysroot on a single
> partition. Patch for this was introduced in
> https://github.com/GNOME/ostree/commit/598530daf45a8bcb3be171732569b8aad0f4345d
> , but there are several disadvantages in this approach in my opinion:
>
>
> 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.
>
>
> - is this relevant for grub based systems too or there having only
> kernel/initramfs on /boot is sufficient?
>
>
> 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.
>
>
>
>
> _______________________________________________
> ostree-list mailing list
> ostree-list gnome org
> https://mail.gnome.org/mailman/listinfo/ostree-list



-- 
  Jasper