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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
