Bug#562847: closed by maximilian attems <maks@debian.org> (Bug#519800: fixed in initramfs-tools 0.94)

[maximilian attems <max@stro.at>]

On Mon, Apr 12, 2010 at 01:42:46PM +0400, Vladimir Stavrinov wrote:
> On Fri, Apr 09, 2010 at 03:42:57PM +0200, maximilian attems wrote:
> 
> OK. I see, but there are nothing what I don't already know at least
> related to this discussing. That is simple algorithm:
> 
>         1. You backup old intrd image
>         2. You create new image as temporary file.
>         3. You move new image in place of old one.
>         4. If it fail due to low disk space You move back the old image
>            into its' place.

there is nothing wrong with a /boot/initrd.img-version-flavour.bak
if initramfs creation goes wrong people expect it there.
won't change that indeed.
 
> And then You proudly say me "that was done for better reliability"! But
> this is poor "reliability". This way You solve only one case, when
> system become unbootable: when new image are already overridden by old
> one, but there are not enough space for that and You have not neither
> new nor old image. But there are other cases when system become
> unbootable, for example due to contents of new image itself. This is
> common case, when You can not boot with new image, but old one already
> overridden, because image was generated few times before system boot.
> Please, don't tell me, this is "admin error" again.
> 
> I don't understand, why You don't agree to move backup and temporary
> files out of /boot? In this case Your idea of "reliability" remain in
> place: when You can not replace old image with new one due to low disk
> space, You will roll back to the old image as You do this now.

it wasn't yet pointed that you can get smaller initramfs by using
MODULES=dep
and
BUSYBOX=n
(in the case that you don't use lvm2 or cryptsetup their initramfs
 boot script assume availabilty of busybox in initramfs)

thanks for your report, surfaced the old .bak keeping.