[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#387780: initramfs-tools: power cut during update-initramfs leaves system unbootable

On Wed, Sep 20, 2006 at 09:23:15AM +0200, Thiemo Nagel wrote:
> >>A power cut during update-initramfs may leave the system in an unbootable 
> >>state as the old initrd.img is overwritten, but the new initrd.img is not 
> >>yet completed.  (This happened to me when my laptop battery ran empty.)  
> >>A simple fix would be to create the new initrd.img as a temporary file 
> >>and move it to replace the old initrd.img only after image creation has 
> >>been finished.  That way, the chance to have an unbootable system after a 
> >>power cut would be significantly lower, restricted to situations in which 
> >>the old initrd.img doesn't work anymore.
> >
> >A better fix would be to always keep a copy of the old vmlinuz/initrd.img 
> >pair
> >or ramdisk including vmlinuz.
> >
> >This would solve lot of problems of this kind, and always keep one or more
> >fallback to older kernels.
> Absolutely.  That solution would require some more thought and work... 
> ;-)  As far as I have understood update-initramfs is called on many 
> occasions and also possibly multiple times during a single apt-get run 
> (not only kernel upgrades but also upgrades of other packages, like e.g. 
> mdadm), so one would have to take some care to identify and backup the 
> last known-working kernel/initrd.img pair.

What about backuping the currently running one ? Or keeping load of backups ? 

But the idea was to ask this in a debconf question at lower priorities :

  We have detected multiple kernels installed.
    current default is : ...
    previous default was : ...
    currently running kernel is : ...
    newly installed kernel is : ...
    list of available kernels :

Then the user can change either the default or backup kernels, and how many he
would like to save and so on.

ramdisk generators, bootloaders and co should share in this scheme, and
everything will work happily thereafter.


Sven Luther

Reply to: