#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 dsaxena):

 Had a IRC conversation with Chris (see below) in regards to this and I'm
 wondering if we can "fix" the build system somehow to make this work. It
 would be really nice and much more user-friendly to be able to install a
 kernel RPM and just have everything dropped into the right place. The
 problem is not the RPM build but the fact that we're trying to install the
 resulting RPM into a chroot that does not have /boot/boot directory.
 Daniel, can you comment on what it would take to change this?

 {{{
 [15:56] <cjb> dsaxena: please revert the latest 2.6.31 commit
 [15:56] <cjb> it breaks the build
 [15:56] <dsaxena> "Update XO-1.5 kernel spec to install kernel bits in
 /boot/boot"?
 [15:56] <cjb> yes
 [15:57] <cjb> (dsd commented on the bug)
 [15:59] <dsaxena> in what does it break the build?
 [15:59] <dsaxena> i rather like having an RPM that installs directly to
 the right place :(
 [16:00] <cjb> the rpm install runs on the build server
 [16:00] <cjb> not the XO
 [16:00] <cjb> the build server does not have a /boot/boot
 [16:01] <dsaxena> can we fix the later? :)
 [16:02] <cjb> then we're demanding that anyone building an XO kernel has
 to be root on their machine
 [16:02] <cjb> which is not currently the case
 [16:02] <cjb> let's just revert it
 [16:05] <dsaxena> ? but when building a kernel, we don't install into the
 actual /boot/boot, but the one in the RPM build environment. I can build
 the kernel rpm on learn w/o being root
 [16:05] <dsaxena> anyways, reverting since it's blocking the build
 [16:06] <cjb> oh, yeah
 [16:06] <cjb> so it's just a problem on the machine you're building on
 [16:06] <cjb> and if you happen to be wanting to install your built kernel
 to <os38
 [16:08] <dsaxena> "machine you're building on" == learn? or something
 else. don't quite grok your meaning. as for <os38, we're in pre-release
 development phase so I'm OK breaking stuff right now
 [16:09] <dsaxena> as the end product is an RPM that is more user friendly
 [16:09] <-- jnettlet_ has left this server (Ping timeout: 480 seconds).
 [16:16] <cjb> yes, learn
 [16:18] <dsaxena> the fact that I can build an rpm on learn and it fails
 on the build box is a problem on learn and not a problem on the build box?
 /me fails to understand, but will go back to suspend resume stuff
 [16:18] <cjb> oh, heh
 [16:19] <cjb> no, we're talking about two different types of installs
 [16:21] <cjb> hm, not sure now
 [16:21] <cjb> did you see the bug?  dsd says:
 [16:21] <cjb> Yeah, that's going to break the build, I think it should be
 reverted.
 [16:21] <cjb> http://dev.laptop.org/ticket/9648
 [16:22] <dsaxena> yep saw that, but it doesn't tell me much to go on. i'll
 comment on there
 [16:22] <cjb> nod
 [16:22] <cjb> I'm not sure exactly what dsd's referring to either
 [16:22] <cjb> oh, I get it
 [16:22] <cjb> learn runs the build, installing RPMs into the chroot
 [16:22] <cjb> the chroot is not yet partitioned
 [16:22] <cjb> at RPM install time
 [16:23] <cjb> so the install of the kernel RPM fails, and the build fails
 [16:23] <cjb> because /boot/boot inside the chroot doesn't exist
 [16:24] <cjb> dsaxena: ^
 [16:25] <dsaxena> i see
 [16:25] <dsaxena> so it's not the build of the RPM itself, but the install
 of the RPM when building the filesystem image
 [16:26] <dsaxena> that's the issue
 [16:26] <dsaxena> (that was meant to be one sentence)
 [16:27] <cjb> right
 [16:27] <cjb> hence two different installs :)
 [16:27] <dsaxena> so fix the chroot? ;)
 [16:28] * dsaxena hides
 [16:28] <cjb> you can make the argument in the ticket; it's a possibility
 }}}

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