Removing /boot from Root paritions

[Zachary Reizner]

I've been planning on removing the contents of /boot from the root partitions on Chrome OS images for a while now, but have just now found some time to implement this. I know that the postinst program requires this, and I plan on chaning postinst so that dependency no longer exists. As far as I can tell, nobody boots from the /boot folder. Are there any other dependencies on the /boot folder in the root partitions?

[Mike Frysinger]

we already delete /boot from signed images:

https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+/release-R40-6457.B/scripts/image_signing/strip_boot_from_image.sh

we don't do it in unsigned images so we can use the bootloader/kernel in there in VM's and generic images (which will often boot w/legacy BIOS)

-mike

On Tue, Dec 16, 2014 at 5:01 PM, Zachary Reizner <za...@google.com> wrote:

I've been planning on removing the contents of /boot from the root partitions on Chrome OS images for a while now, but have just now found some time to implement this. I know that the postinst program requires this, and I plan on chaning postinst so that dependency no longer exists. As far as I can tell, nobody boots from the /boot folder. Are there any other dependencies on the /boot folder in the root partitions?

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

[Zachary Reizner]

It seems the VMs always boots from the system partition (/dev/sda12). Is there something that actually requires booting from /boot on a root partition (/dev/sda3 or /dev/sda5).

[Sonny Rao]

+dianders

I thought there was something that used /boot -- Doug, maybe it was
just nv_uboot on older platforms?

> To unsubscribe from this group and stop receiving emails from it, send an
> email to chromium-os-d...@chromium.org.

[Gabe Black]

I know (and I think Zach already knows) one use of it is to update the kernels in the system partition. When an update is applied, the root FS is updated, and then the kernel there is copied into the system partition. We still have almost all of the kernel in the kernel partition which is also updated, but it's a little harder to get at and is missing a little bit we don't use in a verified boot. We would need a mechanism to extract it, and also a way to recover the small bit that's dropped by the vboot tools.

I think we also use it to store the syslinux config files. If we generate those on the fly using the command line in the kernel blobs, we can eliminate that dependency also.

As far as things in the root FS, as vapier points out we delete /boot on signed images, so it can't be too strong of a dependency. It's possible one exists, but I suspect not.

Gabe

[Sonny Rao]

On Tue, Dec 16, 2014 at 4:02 PM, Gabe Black <gabe...@google.com> wrote:
> I know (and I think Zach already knows) one use of it is to update the
> kernels in the system partition. When an update is applied, the root FS is
> updated, and then the kernel there is copied into the system partition. We
> still have almost all of the kernel in the kernel partition which is also
> updated, but it's a little harder to get at and is missing a little bit we
> don't use in a verified boot. We would need a mechanism to extract it, and
> also a way to recover the small bit that's dropped by the vboot tools.
>
> I think we also use it to store the syslinux config files. If we generate
> those on the fly using the command line in the kernel blobs, we can
> eliminate that dependency also.
>
> As far as things in the root FS, as vapier points out we delete /boot on
> signed images, so it can't be too strong of a dependency. It's possible one
> exists, but I suspect not.

Yeah, it only matters for people not running ChromeOS firmware, but
since we already remove it for our official images, that brings up the
question, why do we need to remove it completely? What is being
gained?

[Zachary Reizner]

The biggest reason to remove it is that doing so will speed up image_to_vm.sh. Another is that when I first got started on the Chrome OS team, the /boot folder acted as a frustrating red herring. I was trying to modify the kernel command line there without realizing it had no effect on VMs. Removing the /boot folder's contents would prevent this confusion for future newcomers.

>> > email to chromium-os-dev+unsubscribe@chromium.org.

>>
>> --
>> --
>> Chromium OS Developers mailing list: chromiu...@chromium.org
>> View archives, change email options, or unsubscribe:
>> http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en
>>
>> To unsubscribe from this group and stop receiving emails from it, send an

>> email to chromium-os-dev+unsubscribe@chromium.org.

[Chris Masone]

On Tue Dec 16 2014 at 4:21:15 PM 'Zachary Reizner' via Chromium OS dev <chromiu...@chromium.org> wrote:

The biggest reason to remove it is that doing so will speed up image_to_vm.sh.

Do we have an idea how much of a speedup this will get us? It's hard to evaluate the tradeoffs without that info :-/

 

Another is that when I first got started on the Chrome OS team, the /boot folder acted as a frustrating red herring. I was trying to modify the kernel command line there without realizing it had no effect on VMs. Removing the /boot folder's contents would prevent this confusion for future newcomers.

Is there some kind of README or something where we could document this instead? And what'd your mentor tell you about this when you asked him or her?

[Zachary Reizner]

On Tue, Dec 16, 2014 at 4:42 PM, Chris Masone <cma...@chromium.org> wrote:

On Tue Dec 16 2014 at 4:21:15 PM 'Zachary Reizner' via Chromium OS dev <chromiu...@chromium.org> wrote:

The biggest reason to remove it is that doing so will speed up image_to_vm.sh.

Do we have an idea how much of a speedup this will get us? It's hard to evaluate the tradeoffs without that info :-/

According to Gabe, assuming I could successfully remove the need to call cros_make_image_bootable which will hopefully result from this change, about 18% of the image_to_vm.sh runtime.

 

 

 

Another is that when I first got started on the Chrome OS team, the /boot folder acted as a frustrating red herring. I was trying to modify the kernel command line there without realizing it had no effect on VMs. Removing the /boot folder's contents would prevent this confusion for future newcomers.

Is there some kind of README or something where we could document this instead? And what'd your mentor tell you about this when you asked him or her?

While a README would have been helpful, I think removing the hidden snake pit is better than giving developers a map around it, even if it requires me to put in some elbow grease. It was a few months ago when I was dealing with this, so I can't remember if I asked my mentor about it. However, not everybody (e.g. outside contributors) has a mentor to ask for quick help on institutional knowledge.

[Sonny Rao]

On Tue, Dec 16, 2014 at 4:51 PM, Zachary Reizner <za...@google.com> wrote:
>
>
> On Tue, Dec 16, 2014 at 4:42 PM, Chris Masone <cma...@chromium.org> wrote:
>>
>>
>>
>> On Tue Dec 16 2014 at 4:21:15 PM 'Zachary Reizner' via Chromium OS dev
>> <chromiu...@chromium.org> wrote:
>>>
>>> The biggest reason to remove it is that doing so will speed up
>>> image_to_vm.sh.
>>
>>
>> Do we have an idea how much of a speedup this will get us? It's hard to
>> evaluate the tradeoffs without that info :-/
>
> According to Gabe, assuming I could successfully remove the need to call
> cros_make_image_bootable which will hopefully result from this change, about
> 18% of the image_to_vm.sh runtime.

Ok, and I guess this is important for speeding up build bots running VMTests ?
If that's the goal, then I'm okay with it.

It is interesting that the /boot costs us that much, does it represent
18% of the data which is transferred?

>>
>>
>>
>>
>>
>>
>>>
>>> Another is that when I first got started on the Chrome OS team, the /boot
>>> folder acted as a frustrating red herring. I was trying to modify the kernel
>>> command line there without realizing it had no effect on VMs. Removing the
>>> /boot folder's contents would prevent this confusion for future newcomers.
>>
>>
>> Is there some kind of README or something where we could document this
>> instead? And what'd your mentor tell you about this when you asked him or
>> her?
>
> While a README would have been helpful, I think removing the hidden snake
> pit is better than giving developers a map around it, even if it requires me
> to put in some elbow grease. It was a few months ago when I was dealing with
> this, so I can't remember if I asked my mentor about it. However, not
> everybody (e.g. outside contributors) has a mentor to ask for quick help on
> institutional knowledge.

Yeah the VM is a bit of a corner case, AFAIK, most people aren't
developing on it, so documentation might be poor here. I don't know
that poor documentation means we should remove it, rather than improve
documentation, but if we're pursuing faster build bot times then I
think it's definitely a worthy goal.

>>>> >> > email to chromium-os-d...@chromium.org.

>>>> >>
>>>> >> --
>>>> >> --
>>>> >> Chromium OS Developers mailing list: chromiu...@chromium.org
>>>> >> View archives, change email options, or unsubscribe:
>>>> >> http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en
>>>> >>
>>>> >> To unsubscribe from this group and stop receiving emails from it,
>>>> >> send an

>>>> >> email to chromium-os-d...@chromium.org.

[Doug Anderson]

Hi,

On Tue, Dec 16, 2014 at 2:52 PM, Sonny Rao <sonn...@chromium.org> wrote:

+dianders

I thought there was something that used /boot -- Doug, maybe it was
just nv_uboot on older platforms?

Yup, this will necessitate changing my workflow on older devices like snow, pit, and pi.  I typically boot those with nv_uboot and.  The default scripts in U-Boot look in /boot for a kernel (and use partition 12 to decide which partition the rootfs is in to facilitate simple A/B swapping).  It's pretty old and crufty and I'm probably the only one using it, but I don't know that for sure.

-Doug

[Zachary Reizner]

 Are you open to this change? Would it be possible to change where U-Boot looks for a kernel? Is it possible there are some people in the wild who are also using nv_uboot?

[Andrew Bresticker]

FWIW I also rely on /boot for booting chromiumos images on my
Jetson-TK1. Those doing upstream work on Snow/Pit/Pi may also be
using nv_uboot.

[Chris Masone]

On Tue Dec 16 2014 at 4:51:50 PM Zachary Reizner <za...@google.com> wrote:

On Tue, Dec 16, 2014 at 4:42 PM, Chris Masone <cma...@chromium.org> wrote:

On Tue Dec 16 2014 at 4:21:15 PM 'Zachary Reizner' via Chromium OS dev <chromiu...@chromium.org> wrote:

The biggest reason to remove it is that doing so will speed up image_to_vm.sh.

Do we have an idea how much of a speedup this will get us? It's hard to evaluate the tradeoffs without that info :-/

According to Gabe, assuming I could successfully remove the need to call cros_make_image_bootable which will hopefully result from this change, about 18% of the image_to_vm.sh runtime.

How much walltime is that? Is converting the images to VMs a bottleneck on the builders? That is, are the builders parallelizing it with other work anyway? Without knowing that, it's still hard to tell if this proposed gain is meaningful or not.

 

 

 

 

Another is that when I first got started on the Chrome OS team, the /boot folder acted as a frustrating red herring. I was trying to modify the kernel command line there without realizing it had no effect on VMs. Removing the /boot folder's contents would prevent this confusion for future newcomers.

Is there some kind of README or something where we could document this instead? And what'd your mentor tell you about this when you asked him or her?

While a README would have been helpful, I think removing the hidden snake pit is better than giving developers a map around it, even if it requires me to put in some elbow grease. It was a few months ago when I was dealing with this, so I can't remember if I asked my mentor about it. However, not everybody (e.g. outside contributors) has a mentor to ask for quick help on institutional knowledge.

Won't removing this negatively impact people not using official Chrome OS firmware, though? Like, potentially breaking boot? These would be the same people who don't have a mentor to ask for help on institutional knowledge.

FWIW, I actually run in VMs a lot, because for the userspace code I work on it's more than fine. I agree with Sonny's gut feeling that people doing kernel work in VMs are a bit of an edge case, though.

[Zachary Reizner]

On Wed, Dec 17, 2014 at 10:45 AM, Chris Masone <cma...@chromium.org> wrote:

On Tue Dec 16 2014 at 4:51:50 PM Zachary Reizner <za...@google.com> wrote:

On Tue, Dec 16, 2014 at 4:42 PM, Chris Masone <cma...@chromium.org> wrote:

On Tue Dec 16 2014 at 4:21:15 PM 'Zachary Reizner' via Chromium OS dev <chromiu...@chromium.org> wrote:

The biggest reason to remove it is that doing so will speed up image_to_vm.sh.

Do we have an idea how much of a speedup this will get us? It's hard to evaluate the tradeoffs without that info :-/

According to Gabe, assuming I could successfully remove the need to call cros_make_image_bootable which will hopefully result from this change, about 18% of the image_to_vm.sh runtime.

How much walltime is that? Is converting the images to VMs a bottleneck on the builders? That is, are the builders parallelizing it with other work anyway? Without knowing that, it's still hard to tell if this proposed gain is meaningful or not.

 

I'm under the impression that this unlikely to meaningfully improve overall runtime on the builders. However, I tend to run image_to_vm.sh manually often and would appreciate less wait time on that command.

 

 

 

 

Another is that when I first got started on the Chrome OS team, the /boot folder acted as a frustrating red herring. I was trying to modify the kernel command line there without realizing it had no effect on VMs. Removing the /boot folder's contents would prevent this confusion for future newcomers.

Is there some kind of README or something where we could document this instead? And what'd your mentor tell you about this when you asked him or her?

While a README would have been helpful, I think removing the hidden snake pit is better than giving developers a map around it, even if it requires me to put in some elbow grease. It was a few months ago when I was dealing with this, so I can't remember if I asked my mentor about it. However, not everybody (e.g. outside contributors) has a mentor to ask for quick help on institutional knowledge.

Won't removing this negatively impact people not using official Chrome OS firmware, though? Like, potentially breaking boot? These would be the same people who don't have a mentor to ask for help on institutional knowledge.

FWIW, I actually run in VMs a lot, because for the userspace code I work on it's more than fine. I agree with Sonny's gut feeling that people doing kernel work in VMs are a bit of an edge case, though.

 

I run qemu almost exclusively since I've gotten here and I'm doing kernel work. Hence my strong incentive to see VM development work smoother.

[Mike Frysinger]

On Thu, Dec 18, 2014 at 5:21 PM, Zachary Reizner <za...@google.com> wrote:

On Wed, Dec 17, 2014 at 10:45 AM, Chris Masone <cma...@chromium.org> wrote:

On Tue Dec 16 2014 at 4:51:50 PM Zachary Reizner <za...@google.com> wrote:

On Tue, Dec 16, 2014 at 4:42 PM, Chris Masone <cma...@chromium.org> wrote:

On Tue Dec 16 2014 at 4:21:15 PM 'Zachary Reizner' via Chromium OS dev <chromiu...@chromium.org> wrote:

The biggest reason to remove it is that doing so will speed up image_to_vm.sh.

Do we have an idea how much of a speedup this will get us? It's hard to evaluate the tradeoffs without that info :-/

According to Gabe, assuming I could successfully remove the need to call cros_make_image_bootable which will hopefully result from this change, about 18% of the image_to_vm.sh runtime.

How much walltime is that? Is converting the images to VMs a bottleneck on the builders? That is, are the builders parallelizing it with other work anyway? Without knowing that, it's still hard to tell if this proposed gain is meaningful or not.

 

I'm under the impression that this unlikely to meaningfully improve overall runtime on the builders. However, I tend to run image_to_vm.sh manually often and would appreciate less wait time on that command.

shrinking the cycle time from build_image to launching a VM is good (removing the need for image_to_vm.sh entirely is even better).  but how does that translate to removing /boot ?

-mike

[Chris Masone]

On Thu Dec 18 2014 at 2:21:42 PM Zachary Reizner <za...@google.com> wrote:

On Wed, Dec 17, 2014 at 10:45 AM, Chris Masone <cma...@chromium.org> wrote:

On Tue Dec 16 2014 at 4:51:50 PM Zachary Reizner <za...@google.com> wrote:

On Tue, Dec 16, 2014 at 4:42 PM, Chris Masone <cma...@chromium.org> wrote:

On Tue Dec 16 2014 at 4:21:15 PM 'Zachary Reizner' via Chromium OS dev <chromiu...@chromium.org> wrote:

The biggest reason to remove it is that doing so will speed up image_to_vm.sh.

Do we have an idea how much of a speedup this will get us? It's hard to evaluate the tradeoffs without that info :-/

According to Gabe, assuming I could successfully remove the need to call cros_make_image_bootable which will hopefully result from this change, about 18% of the image_to_vm.sh runtime.

How much walltime is that? Is converting the images to VMs a bottleneck on the builders? That is, are the builders parallelizing it with other work anyway? Without knowing that, it's still hard to tell if this proposed gain is meaningful or not.

 

I'm under the impression that this unlikely to meaningfully improve overall runtime on the builders. However, I tend to run image_to_vm.sh manually often and would appreciate less wait time on that command.

I can appreciate your desire; as I said, I often do development in a VM as well.

However, if it would break boot for people running Chromium OS on non-Chrome{box,book} hardware, then I think we'd need to explore other choices. Is that so, or have I misunderstood the conversation so far?

Also, is it possible that there's a better workflow for you? Ideally, you wouldn't have to mint a new image multiple times a day to do your work. There are ways to push new kernels to running systems, right?

 

 

 

 

 

Another is that when I first got started on the Chrome OS team, the /boot folder acted as a frustrating red herring. I was trying to modify the kernel command line there without realizing it had no effect on VMs. Removing the /boot folder's contents would prevent this confusion for future newcomers.

Is there some kind of README or something where we could document this instead? And what'd your mentor tell you about this when you asked him or her?

While a README would have been helpful, I think removing the hidden snake pit is better than giving developers a map around it, even if it requires me to put in some elbow grease. It was a few months ago when I was dealing with this, so I can't remember if I asked my mentor about it. However, not everybody (e.g. outside contributors) has a mentor to ask for quick help on institutional knowledge.

Won't removing this negatively impact people not using official Chrome OS firmware, though? Like, potentially breaking boot? These would be the same people who don't have a mentor to ask for help on institutional knowledge.

FWIW, I actually run in VMs a lot, because for the userspace code I work on it's more than fine. I agree with Sonny's gut feeling that people doing kernel work in VMs are a bit of an edge case, though.

 

I run qemu almost exclusively since I've gotten here and I'm doing kernel work. Hence my strong incentive to see VM development work smoother.

Sure, but it sounds like you're in a significant minority on that. Still, it seems like there should be some way to adapt the tools used by your teammates to your usecase that would both allow you to move faster and not break anything for anyone. Have you explored this?

[Zachary Reizner]

On Thu, Dec 18, 2014 at 3:15 PM, Mike Frysinger <vap...@chromium.org> wrote:

On Thu, Dec 18, 2014 at 5:21 PM, Zachary Reizner <za...@google.com> wrote:

On Wed, Dec 17, 2014 at 10:45 AM, Chris Masone <cma...@chromium.org> wrote:

On Tue Dec 16 2014 at 4:51:50 PM Zachary Reizner <za...@google.com> wrote:

On Tue, Dec 16, 2014 at 4:42 PM, Chris Masone <cma...@chromium.org> wrote:

On Tue Dec 16 2014 at 4:21:15 PM 'Zachary Reizner' via Chromium OS dev <chromiu...@chromium.org> wrote:

The biggest reason to remove it is that doing so will speed up image_to_vm.sh.

Do we have an idea how much of a speedup this will get us? It's hard to evaluate the tradeoffs without that info :-/

According to Gabe, assuming I could successfully remove the need to call cros_make_image_bootable which will hopefully result from this change, about 18% of the image_to_vm.sh runtime.

How much walltime is that? Is converting the images to VMs a bottleneck on the builders? That is, are the builders parallelizing it with other work anyway? Without knowing that, it's still hard to tell if this proposed gain is meaningful or not.

 

I'm under the impression that this unlikely to meaningfully improve overall runtime on the builders. However, I tend to run image_to_vm.sh manually often and would appreciate less wait time on that command.

shrinking the cycle time from build_image to launching a VM is good (removing the need for image_to_vm.sh entirely is even better).  but how does that translate to removing /boot ?

-mike

image_to_vm.sh via cros_make_image_bootable will change the /boot folder's kernel args for the benefit of testing post-inst, which depends on these kernel args. Because the /boot folder resides on a root partition, it ends up needing to be re-signed.

[Chirantan Ekbote]

On Thu, Dec 18, 2014 at 3:48 PM, 'Zachary Reizner' via Chromium OS dev
<chromiu...@chromium.org> wrote:
>
>
>
> On Thu, Dec 18, 2014 at 3:15 PM, Mike Frysinger <vap...@chromium.org> wrote:
>>
>> On Thu, Dec 18, 2014 at 5:21 PM, Zachary Reizner <za...@google.com> wrote:
>>>
>>> On Wed, Dec 17, 2014 at 10:45 AM, Chris Masone <cma...@chromium.org> wrote:
>>>>
>>>> On Tue Dec 16 2014 at 4:51:50 PM Zachary Reizner <za...@google.com> wrote:
>>>>>
>>>>> On Tue, Dec 16, 2014 at 4:42 PM, Chris Masone <cma...@chromium.org> wrote:
>>>>>>
>>>>>> On Tue Dec 16 2014 at 4:21:15 PM 'Zachary Reizner' via Chromium OS dev <chromiu...@chromium.org> wrote:
>>>>>>>
>>>>>>> The biggest reason to remove it is that doing so will speed up image_to_vm.sh.
>>>>>>
>>>>>>
>>>>>> Do we have an idea how much of a speedup this will get us? It's hard to evaluate the tradeoffs without that info :-/
>>>>>
>>>>> According to Gabe, assuming I could successfully remove the need to call cros_make_image_bootable which will hopefully result from this change, about 18% of the image_to_vm.sh runtime.
>>>>
>>>>
>>>> How much walltime is that? Is converting the images to VMs a bottleneck on the builders? That is, are the builders parallelizing it with other work anyway? Without knowing that, it's still hard to tell if this proposed gain is meaningful or not.
>>>
>>>
>>> I'm under the impression that this unlikely to meaningfully improve overall runtime on the builders. However, I tend to run image_to_vm.sh manually often and would appreciate less wait time on that command.
>>
>>
>> shrinking the cycle time from build_image to launching a VM is good (removing the need for image_to_vm.sh entirely is even better). but how does that translate to removing /boot ?
>> -mike
>
>
> image_to_vm.sh via cros_make_image_bootable will change the /boot folder's kernel args for the benefit of testing post-inst, which depends on these kernel args. Because the /boot folder resides on a root partition, it ends up needing to be re-signed.
>
>

Is there a reason you can't make your image with
--noenable_rootfs_verification so that you don't need to re-sign the
rootfs?

[Zachary Reizner]

On Thu, Dec 18, 2014 at 3:43 PM, Chris Masone <cma...@chromium.org> wrote:

On Thu Dec 18 2014 at 2:21:42 PM Zachary Reizner <za...@google.com> wrote:

On Wed, Dec 17, 2014 at 10:45 AM, Chris Masone <cma...@chromium.org> wrote:

On Tue Dec 16 2014 at 4:51:50 PM Zachary Reizner <za...@google.com> wrote:

On Tue, Dec 16, 2014 at 4:42 PM, Chris Masone <cma...@chromium.org> wrote:

On Tue Dec 16 2014 at 4:21:15 PM 'Zachary Reizner' via Chromium OS dev <chromiu...@chromium.org> wrote:

The biggest reason to remove it is that doing so will speed up image_to_vm.sh.

Do we have an idea how much of a speedup this will get us? It's hard to evaluate the tradeoffs without that info :-/

According to Gabe, assuming I could successfully remove the need to call cros_make_image_bootable which will hopefully result from this change, about 18% of the image_to_vm.sh runtime.

How much walltime is that? Is converting the images to VMs a bottleneck on the builders? That is, are the builders parallelizing it with other work anyway? Without knowing that, it's still hard to tell if this proposed gain is meaningful or not.

 

I'm under the impression that this unlikely to meaningfully improve overall runtime on the builders. However, I tend to run image_to_vm.sh manually often and would appreciate less wait time on that command.

I can appreciate your desire; as I said, I often do development in a VM as well.

However, if it would break boot for people running Chromium OS on non-Chrome{box,book} hardware, then I think we'd need to explore other choices. Is that so, or have I misunderstood the conversation so far?

 

The only boards it would break are the ones that actually boot from /boot on the root partition. Chrome OS users on generic x86 hardware (or VMs) are booting the system partition and would therefore be safe. It seems Beaglebone and nv_boot users DO in fact need the /boot folder, however I'm looking into fixing that. 

Also, is it possible that there's a better workflow for you? Ideally, you wouldn't have to mint a new image multiple times a day to do your work. There are ways to push new kernels to running systems, right?

It's true that I do not use image_to_vm.sh as much since I've discovered the update_kernel.sh script :). However there are times when making an entirely new image is necessary like when I want to test another board config on the VM.

I'd also like to point out that it's not all about the workflow. Currently, we have 6 kernels located in 3 areas on each image. I think that's a lot of mental overhead for someone to learn the Chrome OS system. Removing the extraneous kernels will serve to simplify the system.

[Zachary Reizner]

+Don Garrett​

[Alex Deymo]

One more reason to remove the data from /boot (or better said, to not install it there) is that we build the image, and then we sign it somewhere else... so you need to have enough space in the partition when you build it to later remove that data. Alright, the official signed full payload won't have nor transfer that information, but the partition needs to have that empty space there which is wasted in the device. This is a bigger problem on embedded devices where the rootfs could be in the order of 50~100 MB and your kernel is 4MB.

 

[Chris Masone]

On Thu Dec 18 2014 at 3:59:13 PM Zachary Reizner <za...@google.com> wrote:

On Thu, Dec 18, 2014 at 3:43 PM, Chris Masone <cma...@chromium.org> wrote:

On Thu Dec 18 2014 at 2:21:42 PM Zachary Reizner <za...@google.com> wrote:

On Wed, Dec 17, 2014 at 10:45 AM, Chris Masone <cma...@chromium.org> wrote:

On Tue Dec 16 2014 at 4:51:50 PM Zachary Reizner <za...@google.com> wrote:

On Tue, Dec 16, 2014 at 4:42 PM, Chris Masone <cma...@chromium.org> wrote:

On Tue Dec 16 2014 at 4:21:15 PM 'Zachary Reizner' via Chromium OS dev <chromiu...@chromium.org> wrote:

The biggest reason to remove it is that doing so will speed up image_to_vm.sh.

Do we have an idea how much of a speedup this will get us? It's hard to evaluate the tradeoffs without that info :-/

According to Gabe, assuming I could successfully remove the need to call cros_make_image_bootable which will hopefully result from this change, about 18% of the image_to_vm.sh runtime.

How much walltime is that? Is converting the images to VMs a bottleneck on the builders? That is, are the builders parallelizing it with other work anyway? Without knowing that, it's still hard to tell if this proposed gain is meaningful or not.

 

I'm under the impression that this unlikely to meaningfully improve overall runtime on the builders. However, I tend to run image_to_vm.sh manually often and would appreciate less wait time on that command.

I can appreciate your desire; as I said, I often do development in a VM as well.

However, if it would break boot for people running Chromium OS on non-Chrome{box,book} hardware, then I think we'd need to explore other choices. Is that so, or have I misunderstood the conversation so far?

 

The only boards it would break are the ones that actually boot from /boot on the root partition. Chrome OS users on generic x86 hardware (or VMs) are booting the system partition and would therefore be safe. It seems Beaglebone and nv_boot users DO in fact need the /boot folder, however I'm looking into fixing that. 

I thought /boot was there to support legacy bootloaders, which many commodity x86 devices have. From chromium-os-discuss traffic, I feel like old laptops are mostly what people try to run Chromium OS on.

Is this not so?

[Zachary Reizner]

On Fri, Dec 19, 2014 at 8:56 AM, Chris Masone <cma...@chromium.org> wrote:

On Thu Dec 18 2014 at 3:59:13 PM Zachary Reizner <za...@google.com> wrote:

On Thu, Dec 18, 2014 at 3:43 PM, Chris Masone <cma...@chromium.org> wrote:

On Thu Dec 18 2014 at 2:21:42 PM Zachary Reizner <za...@google.com> wrote:

On Wed, Dec 17, 2014 at 10:45 AM, Chris Masone <cma...@chromium.org> wrote:

On Tue Dec 16 2014 at 4:51:50 PM Zachary Reizner <za...@google.com> wrote:

On Tue, Dec 16, 2014 at 4:42 PM, Chris Masone <cma...@chromium.org> wrote:

On Tue Dec 16 2014 at 4:21:15 PM 'Zachary Reizner' via Chromium OS dev <chromiu...@chromium.org> wrote:

The biggest reason to remove it is that doing so will speed up image_to_vm.sh.

Do we have an idea how much of a speedup this will get us? It's hard to evaluate the tradeoffs without that info :-/

According to Gabe, assuming I could successfully remove the need to call cros_make_image_bootable which will hopefully result from this change, about 18% of the image_to_vm.sh runtime.

How much walltime is that? Is converting the images to VMs a bottleneck on the builders? That is, are the builders parallelizing it with other work anyway? Without knowing that, it's still hard to tell if this proposed gain is meaningful or not.

 

I'm under the impression that this unlikely to meaningfully improve overall runtime on the builders. However, I tend to run image_to_vm.sh manually often and would appreciate less wait time on that command.

I can appreciate your desire; as I said, I often do development in a VM as well.

However, if it would break boot for people running Chromium OS on non-Chrome{box,book} hardware, then I think we'd need to explore other choices. Is that so, or have I misunderstood the conversation so far?

 

The only boards it would break are the ones that actually boot from /boot on the root partition. Chrome OS users on generic x86 hardware (or VMs) are booting the system partition and would therefore be safe. It seems Beaglebone and nv_boot users DO in fact need the /boot folder, however I'm looking into fixing that. 

I thought /boot was there to support legacy bootloaders, which many commodity x86 devices have. From chromium-os-discuss traffic, I feel like old laptops are mostly what people try to run Chromium OS on.

Is this not so?

Legacy bootloaders work just fine on partition 12 (the system partition) as evidenced by the fact that qemu boots it just fine. Running `parted -l` on my machine even shows that partition has the boot flag. You can read more about this at http://www.chromium.org/chromium-os/chromiumos-design-docs/disk-format. That article mentions that /boot is needed by EFI, but if you actually look at <partition 12>/efi/boot/grub.cfg inside partition 12, it mostly just sticks the kernels under <partition 12>/syslinux.  Granted that config has one labeled "Alternate USB Boot" which references the <partition 3>/boot/vmlinuz kernel, but I can't deduce that label's purpose or if anybody needs it.

[Chris Masone]

On Fri Dec 19 2014 at 10:31:03 AM Zachary Reizner <za...@google.com> wrote:

On Fri, Dec 19, 2014 at 8:56 AM, Chris Masone <cma...@chromium.org> wrote:

On Thu Dec 18 2014 at 3:59:13 PM Zachary Reizner <za...@google.com> wrote:

On Thu, Dec 18, 2014 at 3:43 PM, Chris Masone <cma...@chromium.org> wrote:

On Thu Dec 18 2014 at 2:21:42 PM Zachary Reizner <za...@google.com> wrote:

On Wed, Dec 17, 2014 at 10:45 AM, Chris Masone <cma...@chromium.org> wrote:

On Tue Dec 16 2014 at 4:51:50 PM Zachary Reizner <za...@google.com> wrote:

On Tue, Dec 16, 2014 at 4:42 PM, Chris Masone <cma...@chromium.org> wrote:

On Tue Dec 16 2014 at 4:21:15 PM 'Zachary Reizner' via Chromium OS dev <chromiu...@chromium.org> wrote:

The biggest reason to remove it is that doing so will speed up image_to_vm.sh.

Do we have an idea how much of a speedup this will get us? It's hard to evaluate the tradeoffs without that info :-/

According to Gabe, assuming I could successfully remove the need to call cros_make_image_bootable which will hopefully result from this change, about 18% of the image_to_vm.sh runtime.

How much walltime is that? Is converting the images to VMs a bottleneck on the builders? That is, are the builders parallelizing it with other work anyway? Without knowing that, it's still hard to tell if this proposed gain is meaningful or not.

 

I'm under the impression that this unlikely to meaningfully improve overall runtime on the builders. However, I tend to run image_to_vm.sh manually often and would appreciate less wait time on that command.

I can appreciate your desire; as I said, I often do development in a VM as well.

However, if it would break boot for people running Chromium OS on non-Chrome{box,book} hardware, then I think we'd need to explore other choices. Is that so, or have I misunderstood the conversation so far?

 

The only boards it would break are the ones that actually boot from /boot on the root partition. Chrome OS users on generic x86 hardware (or VMs) are booting the system partition and would therefore be safe. It seems Beaglebone and nv_boot users DO in fact need the /boot folder, however I'm looking into fixing that. 

I thought /boot was there to support legacy bootloaders, which many commodity x86 devices have. From chromium-os-discuss traffic, I feel like old laptops are mostly what people try to run Chromium OS on.

Is this not so?

Legacy bootloaders work just fine on partition 12 (the system partition) as evidenced by the fact that qemu boots it just fine. Running `parted -l` on my machine even shows that partition has the boot flag. You can read more about this at http://www.chromium.org/chromium-os/chromiumos-design-docs/disk-format. That article mentions that /boot is needed by EFI, but if you actually look at <partition 12>/efi/boot/grub.cfg inside partition 12, it mostly just sticks the kernels under <partition 12>/syslinux.  Granted that config has one labeled "Alternate USB Boot" which references the <partition 3>/boot/vmlinuz kernel, but I can't deduce that label's purpose or if anybody needs it.

Yeah, I reviewed that doc when we open sourced the project :-)

The EFI bios sounds like what I was remembering. If you can confirm that nothing we care about relies on the kernel in <whatever partition>/boot/vmlinuz, then it seems like it's fine to remove this. Simpler is usually better :-) That said, it looks like that doc explains things pretty well and clears up confusion developers might have about which kernels are used when.

[Zachary Reizner]

To summarize the blockers

• removing /boot would upset Doug's, Andrew's, and Richard's workflow which all depend on /boot
  
• postinst depends on /boot for the kernel and templates

To summarize the gains

• image_to_vm.sh becomes faster and simpler
• there is one less source of kernels and confusion in the images
• we save significant empty space for Alex's use case

To summarize what needs to be done

• fix postinst to use the kernel partitions for updates and to statically include kernel command line templates
• fix nv_uboot to boot using one of the other kernels
• change build scripts to no longer populate /boot

As there hasn't been comment on this thread in weeks, I'll be moving forward with this. 

Thank you all for your discussion. 

[Chris Masone]

I'm not convinced that the lack of comment during a time when almost the entire team is on vacation is meaningful :-)

Have you confirmed that nothing depends on .../boot/vmlinuz? Also, keep in mind that breaking postinst can have significant consequences for our users, and that devices in the field might update from very, very old system images. What're your plans for ensuring coverage for all autoupdate cases?

Also, factory flows are often rather different than developer or end-user use cases, especially when it comes to boot/recovery/image formatting. Have you checked with the factory team to ensure that they don't depend on this in any way?

[Zachary Reizner]

On Fri, Jan 2, 2015 at 11:33 AM, Chris Masone <cma...@chromium.org> wrote:

I'm not convinced that the lack of comment during a time when almost the entire team is on vacation is meaningful :-)

Have you confirmed that nothing depends on .../boot/vmlinuz?

 

Some things do depend on /boot/vmlinuz. This discussion is my attempt to identify them as I have in my summary. It is my belief after talking with Doug, Richard, and Don (who is behind postinst) that things can be changed to remove that dependency. 

Also, keep in mind that breaking postinst can have significant consequences for our users, and that devices in the field might update from very, very old system images. What're your plans for ensuring coverage for all autoupdate cases? 

 

postinst operates on fresh images including any new kernel partitions. It won't matter how old the system is by the time postinst actually gets run. Also, postinst will actually have less external dependencies once I change it to statically include the kernel command line templates. As for ensuring coverage on all machines, I'll do it the same way it has always been done when postinst needed changes, once I find out what that way is. :)

Also, factory flows are often rather different than developer or end-user use cases, especially when it comes to boot/recovery/image formatting. Have you checked with the factory team to ensure that they don't depend on this in any way?

 

You've got a good point about the factory flows. I know absolutely nothing about those, but it was my hope that posting on cros-dev would loop at least one person from each of the pertinent areas I don't know about. If you know of such a factory person who could answer your question, would you please CC them this thread? I don't know who the factory team are.

[Zachary Reizner]

Hello Hung-Te,

Could you please weigh in on this issue of factory image formatting in relation to /boot in the root partitions? Does factory have dependencies on this that would be upset by my change?

Thanks

[Hung-Te Lin]

(resend so chromiumos-dev mailing list can see it0

2015-01-03 4:26 GMT+08:00 Zachary Reizner <za...@google.com>:

Hello Hung-Te,

Could you please weigh in on this issue of factory image formatting in relation to /boot in the root partitions? Does factory have dependencies on this that would be upset by my change?

Factory calls postinst in its installation flow. So if you can ensure postinst is fixed, factory flow is basically fine.

However there's something I want to address.

Do you want to strip the /boot in build_image, or are you also trying to modify the kernel ebuild files so they don't produce /boot/vmlinu*?

Many build scripts, including factory netboot ( https://chromium.googlesource.com/chromiumos/platform/crosutils/+/master/make_netboot.sh),

(probably recovery as well), will try to do emerge-$BOARD <kernel> to some temp directory, and then get the kernel file from

/boot/vmlinuz.

Please make sure that part is not changed.

Thanks,

Hung-Te

[Marc Herbert]

On Tuesday, 16 December 2014 16:51:52 UTC-8, Zachary Reizner wrote:

Another is that when I first got started on the Chrome OS team, the /boot folder acted as a frustrating red herring. I was trying to modify the kernel command line there without realizing it had no effect on VMs. Removing the /boot folder's contents would prevent this confusion for future newcomers.

Is there some kind of README or something where we could document this instead? And what'd your mentor tell you about this when you asked him or her?

 

While a README would have been helpful, I think removing the hidden snake pit is better than giving developers a map around it, even if it requires me to put in some elbow grease. It was a few months ago when I was dealing with this, so I can't remember if I asked my mentor about it. However, not everybody (e.g. outside contributors) has a mentor to ask for quick help on institutional knowledge.

I can confirm I had a very similarly painful experience staring at the half-generated (!) grub.cfg file in /boot. Anything is better than duplication.

Now let me see when I can schedule this meeting with my mentor... :-)

[Alex Deymo]

Hi,

To close the loop here, crbug.com/461595 will remove the /boot files for most devices, except the ones mentioned here (snow, pit, pi, beaglebone) by introducing a new flag; and crbug.com/455343 will take care of the legacy_postinstall step. If for some reason your board / bootloader requires those files in /boot, you will be able to set the USE flag to install them.

I hope this doesn't break any workflow.

deymo.