FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 04-06-2011, 09:18 PM
Joey Hess
 
Default Bug#621375: backup_initramfs=yes

Package: initramfs-tools
Version: 0.98.8
Severity: normal

I recently suffered 2 weeks of downtime of a machine in a location that
made fixing it hard, caused by a broken initramfs due to bug #621137.
This highlighted to me that there are many things that can go wrong and
break an initramfs when it is refreshed, not just when upgrading to a
new kernel. And yet backup initramfses are not kept by default, except
for ones that accompany old kernel versions.

Space should not be a concern, since /boot is always provisioned with
space for multiple kernel and initramfs pairs. So I feel that setting
backup_initramfs=yes would be better than the current default,
leading to more robust and recoverable systems. Thank you.

--
see shy jo
 
Old 04-09-2011, 07:55 PM
maximilian attems
 
Default Bug#621375: backup_initramfs=yes

On Wed, 06 Apr 2011, Joey Hess wrote:

> I recently suffered 2 weeks of downtime of a machine in a location that
> made fixing it hard, caused by a broken initramfs due to bug #621137.
> This highlighted to me that there are many things that can go wrong and
> break an initramfs when it is refreshed, not just when upgrading to a
> new kernel. And yet backup initramfses are not kept by default, except
> for ones that accompany old kernel versions.

it was an Ubuntu merge, as initramfs-tools initramfs were considered
stable, one could think to have this set for sid/testing until freeze.

> Space should not be a concern, since /boot is always provisioned with
> space for multiple kernel and initramfs pairs. So I feel that setting
> backup_initramfs=yes would be better than the current default,
> leading to more robust and recoverable systems. Thank you.

the -ENOSPC error accounts for 50% of the Ubuntu bugs.
I do agree that it is not an initramfs-tools bug per se,
but of the invovled apt that do not cleanup a huge number
of linux-images that heppen due to their easy ABI bump.
Nevertheless due to the triggering the error happens very
late and kills the box.
(Not even starting to account for seperate /boot partitions)

--
maks



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110409195557.GA11940@stro.at">http://lists.debian.org/20110409195557.GA11940@stro.at
 
Old 11-23-2011, 12:29 PM
Michael Prokop
 
Default Bug#621375: backup_initramfs=yes

* maximilian attems [Sam Apr 09, 2011 at 09:55:57 +0200]:
> On Wed, 06 Apr 2011, Joey Hess wrote:

> > I recently suffered 2 weeks of downtime of a machine in a location that
> > made fixing it hard, caused by a broken initramfs due to bug #621137.
> > This highlighted to me that there are many things that can go wrong and
> > break an initramfs when it is refreshed, not just when upgrading to a
> > new kernel. And yet backup initramfses are not kept by default, except
> > for ones that accompany old kernel versions.

> it was an Ubuntu merge, as initramfs-tools initramfs were considered
> stable, one could think to have this set for sid/testing until freeze.

> > Space should not be a concern, since /boot is always provisioned with
> > space for multiple kernel and initramfs pairs. So I feel that setting
> > backup_initramfs=yes would be better than the current default,
> > leading to more robust and recoverable systems. Thank you.

> the -ENOSPC error accounts for 50% of the Ubuntu bugs.
> I do agree that it is not an initramfs-tools bug per se,
> but of the invovled apt that do not cleanup a huge number
> of linux-images that heppen due to their easy ABI bump.
> Nevertheless due to the triggering the error happens very
> late and kills the box.
> (Not even starting to account for seperate /boot partitions)

maximilian, how do we proceed with this issue?

regards,
-mika-
 

Thread Tools




All times are GMT. The time now is 10:21 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org