[PATCH] Cleaning up the kernel postinst script

[Tim Gardner]

Matt Zimmerman wrote:
> 
> ------------------------------------------------------------------------
> 
> Subject:
> [PATCH] Cleaning up the kernel postinst script
> From:
> Matt Zimmerman <mdz at ubuntu.com>
> Date:
> Wed, 19 Aug 2009 16:45:22 +0100
> To:
> ubuntu-devel at lists.ubuntu.com, ubuntu-kernel at lists.ubuntu.com
> 
> To:
> ubuntu-devel at lists.ubuntu.com, ubuntu-kernel at lists.ubuntu.com
> 
> 
> I came across the following bug today:
> 
> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/358564
> 
> which led me to notice that the postinst doesn't print the error message
> when a symlink() call fails.  This makes the failure difficult to debug.
> 
> I've attached a patch which fixes that particular problem (untested but
> fairly trivial).
> 
> However, this got me thinking about the kernel postinst script in general.
> It is over 1000 lines of perl code, and it has many "interesting" failure
> modes.  It doesn't check error codes everywhere it should, and it just
> generally has a lot of logic in it.
> 
> Because every Ubuntu user has this package installed, a lot of them trip
> over these failures, resulting in the rather long (and growing) list of bugs
> here:
> 
> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=INVALID&field.status%3Alist=WONTFIX&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.status_upstream-empty-marker=1&field.omit_dupes.used=&field.has_patch.used=&field.has_cve.used=&field.tag=apport-package&field.tags_combinator=ANY&search=Search
> 
> I'd like to suggest that it might be a good idea to radically simplify this
> script, so that it doesn't have quite so many opportunities to fail.  Much
> of the code in it is inherited from the kernel-package package, which is
> designed to provide extreme configurability.  Just look at the list of
> configuration options at the top:
> 
> my $link_in_boot      = "";  # Should be empty, mostly
> my $no_symlink        = "";   # Should be empty, mostly
> my $reverse_symlink   = "";   # Should be empty, mostly
> my $do_symlink        = "Yes";  # target machine defined
> my $do_boot_enable    = "Yes";  # target machine defined
> my $do_bootfloppy     = "Yes";  # target machine defined
> my $do_bootloader     = "Yes";  # target machine defined
> my $move_image        = '';     # target machine defined
> my $kimage            = "vmlinuz";   # Should be empty, mostly
> my $loader            = "grub"; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot or delo
> my $image_dir         = "/boot";        # where the image is located
> my $clobber_modules   = '';          # target machine defined
> my $relative_links    = "";          # target machine defined
> my $initrd            = "YES";        # initrd kernel
> my $do_initrd         = '';     # Normally we do not
> my $use_hard_links    = ''; # hardlinks do not work across fs boundaries
> my $postinst_hook     = '';          #Normally we do not
> my $postrm_hook       = '';          #Normally we do not
> my $preinst_hook      = '';          #Normally we do not
> my $prerm_hook        = '';          #Normally we do not
> my $minimal_swap      = '';          # Do not swap symlinks
> my $ignore_depmod_err = '';          # normally we do not
> my $ramdisk           = "/usr/sbin/update-initramfs";  # List of tools to create initial ram fs.
> my $notifier          = "/usr/share/update-notifier/notify-reboot-required";
> my $package_name      = "linux-image-$version";
> my $explicit_do_loader = 'Yes';
> 
> In this era of Linux, do end users really need to tweak many of these
> things?  The default GRUB configuration doesn't even use the symlinks (these
> are a holdover from LILO).  Could we get rid of them entirely?
> 
> We could continue to use the massively complex one for ports if that's
> needed, but I think x86+x86_64 could be much, much simpler.
> 
> What do you think?
> 
> 

I've applied the enhanced error reporting patch to Karmic. As for the
larger question, I'd be happy to use an arch dependent postinst that is
tuned for PC platforms, but I'd likely need to work with someone on the
foundations team (my perl skills have long since atrophied). It seems
like something one _really_ wants to get correct.

rtg
-- 
Tim Gardner tim.gardner at canonical.com