#9677 NORM Not Tri: applying a kernel upgrade via rpm is risky

[Zarro Boogs per Child]

#9677: applying a kernel upgrade via rpm is risky
--------------------------+-------------------------------------------------
 Reporter:  mikus         |                 Owner:                                   
     Type:  defect        |                Status:  new                              
 Priority:  normal        |             Milestone:  Not Triaged                      
Component:  not assigned  |               Version:  Development build as of this date
 Keywords:                |           Next_action:  never set                        
 Verified:  0             |   Deployment_affected:                                   
Blockedby:                |              Blocking:                                   
--------------------------+-------------------------------------------------
 I've several times recently tried to apply (to XO-1 nand) a new kernel
 from http://xs-dev.laptop.org/~dsd/repos/f11-xo1 via rpm, and each time
 the newly installed kernel failed to boot (often stalling with an error
 message about initramfs).

 The catch was doing recovery - turns out that in the process of installing
 the new kernel, rpm is *removing* the previous kernel.  So to be able to
 boot that XO-1 from nand again (I didn't want to re-flash the whole build)
 I've had to use a "rescue" USB-booted system to re-populate /boot with the
 files representing the previous kernel.

 To add insult to injury, rpm does not remove the (top-level) directory
 with the previous kernel's name from /lib/modules (fooling the user into
 thinking those components are still there) -- but does wipe all
 *sub*-directories from the previous kernel's /lib/modules tree.  The user
 finds out what happened only after restoring a working kernel and booting
 - many devices now don't work (because there are no drivers for them !!).

 I don't know for sure how Fedora handles the upgrading of a kernel via rpm
 - but I believe it leaves the previous kernel (and modules) still in the
 system.  Then, if the upgrade does not work, there is no need for heroics
 (i.e., using external means to re-insert the deleted kernel and modules) -
 recovery involves merely ensuring that booting will again use the
 preserved kernel.

 ----

 My experience upgrading an XO-1.5 kernel with rpm is much older - I seem
 to remember the previous kernel being left untouched.  [And even though I
 had to manually tweak something, the upgraded XO-1.5 kernel booted fine -
 meaning my decision then to use rpm (rather than wait for a new build) was
 appropriate.]

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