GNOME.org
 

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

At Endless, we use uboot's Flattened Image Tree (FIT) image format.


Sounds interesting, but my goal is to make converting "any" embedded linux image into ostree enabled image as 
simple as possible.
FIT doesn't seem to be used on any of devices that I have been using.

Here is my approach: https://github.com/GNOME/ostree/pull/156/commits

It allows updating contents on the boot partition with major releases - when kernel/initramfs version 
(bootcsum) changes.
This way I can now update boot script and device tree blobs via over the air update. This approach I think 
should work also for other boot loader backends.

Anyways, I think there is even a better solution here, which would be implementing "symlink swap" pattern on 
the whole /boot partition instead of
/boot/loader.x , but that would require even more changes.

________________________________________
From: magcius gmail com <magcius gmail com> on behalf of Jasper St. Pierre <jstpierre mecheye net>
Sent: Tuesday, October 27, 2015 5:05 PM
To: Paeglis Gatis
Cc: Colin Walters; ostree-list gnome org
Subject: Re: 2 partition setup where /boot partition contains more than just kernel and initramfs images.

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
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]