Support for booting without initramfs #442

gatispaeglis · 2016-08-08T15:35:21Z

WIP

I have tested that this patch works fine with u-boot and grub backends.

What is missing here is an automake rule that would create:

/usr/lib/ostree-boot/ostree-prepare-root-> ../../sbin/ostree-prepare-root

or other way around:

/usr/sbin/ostree-prepare-root-> ../lib/ostree-boot/ostree-prepare-root

@cgwalters You mentioned once that you want to moveostree-prepare-rootand ostree-remount from sbin to libexecdir. I am thinking that maybe /usr/lib/ostree-boot is a better location? As this path would be the same on all systems and seems like a more natural place for all these "boot related" files (including ostree-grub-generator). Having this well known path would guarantee that this always works:

init=/ostree/boot.%d/%s/%s/%d/usr/lib/ostree-boot/ostree-prepare-root /

Related change: 54168bc#diff-f0c889fb056dc4a713f8a87702fdd27eR1452
When copying /usr/lib/ostree-boot, exclude ostree-{grub-generator, remount, prepare-root}

rh-atomic-bot · 2016-08-08T15:35:57Z

Can one of the admins verify this patch?
I understand the following comments:

bot, add author to whitelist
bot, test pull request
bot, test pull request once

jlebon · 2016-08-08T15:46:37Z

bot, retest this please

cgwalters · 2016-08-08T20:33:13Z

src/libostree/ostree-sysroot-deploy.c

+                                             new_bootversion, osname, bootcsum,
+                                             ostree_deployment_get_bootserial (deployment));
+      _ostree_kernel_args_replace_take (kargs, ostree_prepare_root);
+      ostree_prepare_root = NULL;


Minor but this can now be: _ostree_kernel_args_replace_take (kargs, g_steal_pointer (&ostree_prepare_root));

cgwalters · 2016-08-08T20:38:23Z

I think it'd be fine to just move the binaries unconditionally - systemd execs them via the .service files so the indirection should be OK.

cgwalters · 2016-08-08T20:46:20Z

src/libostree/ostree-sysroot-deploy.c

+  else
+    {
+      g_autofree char *ostree_prepare_root = NULL;
+      ostree_prepare_root = g_strdup_printf ("init=/ostree/boot.%d/%s/%s/%d/usr/lib/ostree-boot/ostree-prepare-root /",


This will only work though if statically linked...which makes me think this should be part of an #ifdef BUILDOPT_NO_INITRD or something. (And then fatally error out if we do find an initrd in that case?)

For a better backward compatibility I suggest: #ifdef BUILDOPT_STATIC_PREPARE_ROOT

Now when ostree is build with static ostree-prepare-root users

can still use initramfs code path, if initramfs-* found (by using the static version inside of initramfs)

when initramfs-* not found, appendinit= kernel arg.

and if there are any users out there that were using OSTree without initramfs already (by hacking kernel sources to include the ostree-prepare-root logic), they can continue doing that by not compiling ostree-prepare-root statically (BUILDOPT_STATIC_PREPARE_ROOT not defined and therefore "init=" not appended to the kernel args)

Let's set aside the prepare-root-in-kernel case since I'm having enough trouble keeping the support matrix in my head 😄 and I doubt anyone is doing it. The overhead of an additional exec in the startup path is small enough, and avoids having to carry kernel patches, etc.

So, I wouldn't disagree that statically linked users can still use an initramfs, but it'd be odd to have a static switchroot inside an initramfs. I guess if it's small enough, I could imagine "general purpose" distros like Debian/CentOS always building it statically and allowing people to make initrd-less systems that use ostree, even if it's not going to be the default. In my world (CentOS/Fedora) though we're not really focused on the embedded cases, so we basically always have an initrd.

Anyways, I'm ok with renaming the build option to #ifdef BUILDOPT_STATIC_PREPARE_ROOT which is I guess what all this boils down to 😄

So...aside from minor bits, are you thinking we merge this patch as is, or is it more of an RFC and we'll update it with build options later?

cgwalters · 2016-08-08T20:50:48Z

Just some minor comments. I think the next important step here is adding the build machinery to statically link the switchroot binary, right?

gatispaeglis · 2016-08-09T09:42:07Z

I think the next important step here is adding the build machinery to statically link the switchroot binary, right?

@wmanley any success with the 'musl' patch?

gatispaeglis · 2016-08-09T17:01:41Z

Let's set aside the prepare-root-in-kernel case since I'm having enough trouble keeping the support matrix in my head

Good :)

So...aside from minor bits, are you thinking we merge this patch as is, or is it more of an RFC and we'll update it with build options later?

I pushed it here for the discussion purposes. I want to update this patch to include the configure switch: --with-static-prepare-root. Only my autotools knowledge is limited, so I will keep it simple. The "musl" version can be added as an improvement later on.

wmanley · 2016-08-10T12:26:28Z

@wmanley any success with the 'musl' patch?

Not yet. I had patch to build manually with musl. I haven't yet worked on the autotools bits. I don't think it will be too difficult but I don't think I'm going to have a chance to work on it this week.

gatispaeglis · 2016-08-11T14:08:26Z

This patch is still Work-In-Progress. There are few more issues that I need to resolve.

gatispaeglis · 2016-08-26T10:31:36Z

Squashed the autotest into the relevant commit.

rh-atomic-bot · 2016-08-30T21:23:07Z

☔ The latest upstream changes (presumably 42dab85) made this pull request unmergeable. Please resolve the merge conflicts.

wmanley · 2016-08-30T21:59:43Z

@wmanley any success with the 'musl' patch?

musl patch merged as part of #477.

rh-atomic-bot · 2016-08-31T17:06:58Z

☔ The latest upstream changes (presumably 661e463) made this pull request unmergeable. Please resolve the merge conflicts.

wmanley · 2016-08-31T18:21:29Z

musl patch merged as part of #477.

Also further musl fixes in #485

With the current approach, when ostree-prepare-root is used on the kernel command line as init=, it always assumes that the next value in the argument list is a path to the sysroot. The code for falling back to a default path (if none is provided), would only work if init= is the last arg in the argument list. We can not rely on that and have to explicitly provide the path to the sysroot. Which defeats the purpose of a default path selection code. To keep command line neater assume that sysroot is on / when using ostree-prepare-root as init. This probably is what most people want anyways. Also _ostree_kernel_args* API assumes that args are space separated list. Which is problematic for: "init=${ostree}/usr/lib/ostree/ostree-prepare-root /" as it gets split in two.

If the current deployment has "rootwait root=/dev/sda2", but the new deployment does not need "rootwait" anymore, there is no way to clear this arg at the moment (as opposed to "karg=root=", which overrides any earlier argument with the same name). With "--karg-none" users can now clear all the previous args and set new "root=": ostree admin deploy --karg-none --karg=root=LABEL=rootfs

Previously when initramfs-* was not found in a deployment's boot directory, it was assumed that rootfs is prepared for ostree booting by a kernel patch. With this patch, the behaviour changes to be - if initramfs-* is not found, assume that system is using a static ostree-prepare-root as init process. Booting without initramfs is a common use case on embedded systems. This approach is also more convenient, than having to patch the kernel.

gatispaeglis · 2016-10-18T11:25:04Z

FYI this is how I am using --karg-none : https://codereview.qt-project.org/#/c/174145/3/src/lib/qotaclientasync.cpp

cgwalters · 2016-12-06T02:09:05Z

Is this still WIP, or is it ready for review?

wmanley · 2017-02-17T18:28:52Z

@gatispaeglis: I was hoping to start using this soon. What's your feeling on it?

gatispaeglis · 2017-02-20T09:04:45Z

@cgwalters, The more accurate status of this PR would be "it is up from grabs" :) The patch in general is in good shape. I have been using it for a while. There is one issue that I noticed, but haven't had time to fix. The issue is in deployment_bootconfigs_equal. It would need to special case the "init=" command line argument (as it is already doing for "ostree=" ). Otherwise the bootloader configs are unnecessary rewritten, even when "inti=" is the same.

The latest snapshot of the documentation how I used this is in http://doc-snapshots.qt.io/qtota/index.html

@wmanley The above should answer your question too.

My focus recently has changed to other projects, but I can still help with reviewing.

cgwalters · 2017-02-24T03:03:49Z

Ok cool, removing WIP. Will take a look soon.

cgwalters · 2017-02-24T03:03:54Z

bot, retest this please

rh-atomic-bot · 2017-03-30T19:32:10Z

☔ The latest upstream changes (presumably 305db98) made this pull request unmergeable. Please resolve the merge conflicts.

cgwalters · 2018-01-16T22:29:03Z

This was merged in #1401

gatispaeglis mentioned this pull request Aug 8, 2016

[merged] ostree-prepare-root as init #403

Closed

4 tasks

cgwalters reviewed Aug 8, 2016
View reviewed changes

cgwalters added the WIP label Aug 9, 2016

gatispaeglis force-pushed the no-initramfs-bootloader-support branch from a957bc1 to c34de2b Compare August 10, 2016 14:01

gatispaeglis force-pushed the no-initramfs-bootloader-support branch from e374c0e to d0fe11e Compare August 15, 2016 09:29

gatispaeglis mentioned this pull request Aug 18, 2016

Updates on /boot #268

Open

gatispaeglis force-pushed the no-initramfs-bootloader-support branch 2 times, most recently from daeb57d to 5e16918 Compare August 26, 2016 10:30

gatispaeglis force-pushed the no-initramfs-bootloader-support branch from 5e16918 to 3172d58 Compare August 31, 2016 11:02

gatispaeglis added 4 commits September 2, 2016 11:13

ostree-grub-generator: update outdated comment

4fcdca7

gatispaeglis force-pushed the no-initramfs-bootloader-support branch from 3172d58 to 4fcdca7 Compare September 2, 2016 09:21

cgwalters removed the WIP label Feb 24, 2017

cgwalters self-assigned this Feb 24, 2017

cgwalters added this to the 2017.3 milestone Feb 24, 2017

wmanley mentioned this pull request Jan 9, 2018

Support for booting without initramfs (rebased) #1401

Closed

cgwalters closed this Jan 16, 2018

mcorb mentioned this pull request Jan 31, 2018

upgrade doesn't support initramfs <-> non-initramfs switch #1440

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support for booting without initramfs #442

Support for booting without initramfs #442

gatispaeglis commented Aug 8, 2016 •

edited

Loading

rh-atomic-bot commented Aug 8, 2016

jlebon commented Aug 8, 2016

cgwalters Aug 8, 2016

cgwalters commented Aug 8, 2016

cgwalters Aug 8, 2016

gatispaeglis Aug 9, 2016 •

edited

Loading

cgwalters Aug 9, 2016

cgwalters commented Aug 8, 2016

gatispaeglis commented Aug 9, 2016

gatispaeglis commented Aug 9, 2016

wmanley commented Aug 10, 2016

gatispaeglis commented Aug 11, 2016

gatispaeglis commented Aug 26, 2016

rh-atomic-bot commented Aug 30, 2016

wmanley commented Aug 30, 2016

rh-atomic-bot commented Aug 31, 2016

wmanley commented Aug 31, 2016

gatispaeglis commented Oct 18, 2016

cgwalters commented Dec 6, 2016

wmanley commented Feb 17, 2017

gatispaeglis commented Feb 20, 2017

cgwalters commented Feb 24, 2017

cgwalters commented Feb 24, 2017

rh-atomic-bot commented Mar 30, 2017

cgwalters commented Jan 16, 2018

Support for booting without initramfs #442

Support for booting without initramfs #442

Conversation

gatispaeglis commented Aug 8, 2016 • edited Loading

rh-atomic-bot commented Aug 8, 2016

jlebon commented Aug 8, 2016

cgwalters Aug 8, 2016

Choose a reason for hiding this comment

cgwalters commented Aug 8, 2016

cgwalters Aug 8, 2016

Choose a reason for hiding this comment

gatispaeglis Aug 9, 2016 • edited Loading

Choose a reason for hiding this comment

cgwalters Aug 9, 2016

Choose a reason for hiding this comment

cgwalters commented Aug 8, 2016

gatispaeglis commented Aug 9, 2016

gatispaeglis commented Aug 9, 2016

wmanley commented Aug 10, 2016

gatispaeglis commented Aug 11, 2016

gatispaeglis commented Aug 26, 2016

rh-atomic-bot commented Aug 30, 2016

wmanley commented Aug 30, 2016

rh-atomic-bot commented Aug 31, 2016

wmanley commented Aug 31, 2016

gatispaeglis commented Oct 18, 2016

cgwalters commented Dec 6, 2016

wmanley commented Feb 17, 2017

gatispaeglis commented Feb 20, 2017

cgwalters commented Feb 24, 2017

cgwalters commented Feb 24, 2017

rh-atomic-bot commented Mar 30, 2017

cgwalters commented Jan 16, 2018

gatispaeglis commented Aug 8, 2016 •

edited

Loading

gatispaeglis Aug 9, 2016 •

edited

Loading