#9648 LOW 1.5-F11: applying a kernel upgrade via rpm is ineffective

[Zarro Boogs per Child]

#9648: applying a kernel upgrade via rpm is ineffective
------------------------------------+---------------------------------------
           Reporter:  Quozl         |       Owner:                                   
               Type:  defect        |      Status:  reopened                         
           Priority:  low           |   Milestone:  1.5-F11                          
          Component:  not assigned  |     Version:  Development build as of this date
         Resolution:                |    Keywords:  kernel                           
        Next_action:  diagnose      |    Verified:  0                                
Deployment_affected:                |   Blockedby:                                   
           Blocking:                |  
------------------------------------+---------------------------------------

Comment(by dsd):

 It would be an easy change to make, but it would be a hack that makes the
 situation even more messy rather than looking at the problem on a global
 scale. The problem is that this topic reaches out into so many areas so
 I'll attempt to collect all my thoughts here:

 The current system where we mount the boot partition at /boot on the
 chrooted-and-moved filesystem is not nice:

 It breaks various components that look for /boot/olpc_build

 It hides the contents of the real disk. There is stuff in "the real /boot"

 Additionally, /boot/boot is not guaranteed to point at the build that is
 currently running, so fixing all these scripts and things to use
 /boot/boot instead of /boot is not going to give the right results.
 (/boot/boot represents the OS that will be booted into if a reboot was to
 occur at that particular moment in time)

 As for the kernel, it does need to go in /boot in the real image that ends
 up on disk. If you adjust the RPM to install it at /boot/boot then we have
 to add a hack to move it into the right place in the build script. It's
 easy, but it's a hack. Imagine if we had to do that for 10 packages...
 I feel that the pieces of the build should represent how the disk layout
 will end up, rather than how the system will appear after all the mounts
 have been put in place.

 Also, the current system leaves us without a nice way to match the kernel
 stored on the root partition to the one stored on the boot partition. Many
 of these things aren't issues we are are likely to encounter on a regular
 basis, but are things that would be quite painful as we developers run
 into them on an irregular basis.

 Scott (who designed this system) also said that this isn't how he
 envisioned it would work.

 This issue also branches out into #9457: how do we know which is the boot
 device?


 Here's my proposal, which Scott has indicated agreement with:

 /boot is not a mount point. It just shows the contents of the disk.
 Therefore /boot/olpc_build will work again and will *always* be correct.

 /boot entry will be deleted from fstab.

 /bootpart will be created as an empty directory on the root partition.

 olpc-configure will look at /ofw/chosen/bootpath and decide which device
 to mount at /bootpart. The options are /dev/disk/olpc/intp1 or
 /dev/disk/olpc/extp1

 Kernel RPM will go back to installing to /boot

 bitfrost.update will be tweaked to work in /bootpart rather than /boot


 This means that only 2 components need changing from prior behaviour:
 olpc-utils and bitfrost.
 If we go with any other plan, this number becomes higher.

 One downside will be that kernel has to be manually copied from /boot to
 /bootpart after installing a new RPM. I don't think this is an issue
 though - outside of our team this is not something that happens on a
 regular basis, and we've always had to copy the kernel after installation
 as a side-effect of the /versions system, and this is well documented. If
 you think about the /versions and pristine update system as a whole, then
 this is also perfectly understandable. And I can only guess, but
 presumably the RPM never tried to put the boot files in the right place on
 a working install before for exactly these reasons :)

 Either way, lets try and discuss this today, as this issue (as a whole) is
 blocking quite a few items and we aren't making good progress by thinking
 about each component solely on an individual basis...

-- 
Ticket URL: <http://dev.laptop.org/ticket/9648#comment:9>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system