Support for booting without initramfs (rebased) #1401
Conversation
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.
wmanley
changed the title
|
@cgwalters does it possible to update #215 while new grub2 backend not ready? I have already bunch of hosts with /boot on / and i'm always need to prepend /boot inside grub.cfg |
There was a problem hiding this comment.
Only one very minor comment, otherwise looks great to me! Sorry I didn't get to reviewing the original PR; my world is mostly laptop-and-above machines. I did buy a Cubietruck but have yet to put an OS on it...testing things like this may be an excuse to spend time on that.
Thanks a ton for pushing this forward.
| else | ||
| { | ||
| g_autofree char *prepare_root_arg = NULL; | ||
| prepare_root_arg = g_strdup_printf ("init=/ostree/boot.%d/%s/%s/%d/usr/lib/ostree/ostree-prepare-root", |
There was a problem hiding this comment.
This path should use LIBEXECDIR I think.
There was a problem hiding this comment.
I don't think so. See fd1a044. I think the idea is that ostree-prepare-root needs to be at a fixed location in the rootfs otherwise a different version of ostree with different configure flags couldn't successfully deploy a rootfs with standard configure flags.
There was a problem hiding this comment.
Yep, I even agreed with this in #449 (comment) - though for a different reason; I'm not sure how realistic it is to worry about different configure flags.
|
Did you already rebase #215 then? |
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 Closes: #1401 Approved by: cgwalters
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. Closes: #1401 Approved by: cgwalters
Closes: #1401 Approved by: cgwalters
Closes: #1401 Approved by: cgwalters
|
☀️ Test successful - status-atomicjenkins |
This is #442 rebased and with some additional tests. We've been using this patch successfully for over a year in combination with #215 and some others.