Re: The policy on initramfs decompression failure

[Theodore Tso]

On Tue, Jan 13, 2009 at 02:38:49PM -0800, H. Peter Anvin wrote:
> As part of the multi-compression-formats patch, the issue has come up as  
> to what is the preferred policy is on initramfs decompression failure,  
> due to either corruption or due to the use of a compression format which  
> the kernel does not support.
>
> I had personally assumed the proper policy would be to panic, since it  
> is unlikely to mean the system can be booted.  However, Ingo brought up  
> the case where the initramfs is auxilliary to being able to boot the  
> full system, for example the initramfs supplied is primarily a data  
> carrier, and either the builtin initramfs or the kernel itself is  
> sufficient to boot.

I would suggest a default policy of "panic", and a way of overriding
the policy, probably with a boot command-line option.  The reality is
that most of the time, the failure case of a failed or partially
failed initramfs is not going to be well tested, as you have pointed
out, the downsidesof a booted-but-dysfunctional system is often going
to be worse than a hard failure.  The partially decoded case is going
to be even worse, so I can see a three-way policy:

   failed-initramfs-decode=panic      Panic on failed initramfs
   failed-initramfs-decode=partial    If the initramfs fails part-way in, 
   				      decode what you can and let the boot
				      system see what files could be fully
				      decypted
   failed-initramfs-decode=allow      If the initramfs decryption fails
   				      part-of-the-way in, continue the
				      boot, but do not provide the partial
				      initramfs --- i.e., this is the 
				      all-or-nothing option

If this is too complicated, I'd be happy with the "panic on failed
initramfs".  After all, the user can always simply delete the initrd
specifier from their grub boot configuration, and simply retry the
boot....

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/