[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#730073: linux-image-3.11-2-amd64: postinst fails with no_symlinks=yes



On Wed, 20 Nov 2013 23:22:46 +0100 Arno <aelschuring@hotmail.com> wrote:
> Package: src:linux
> Version: 3.11.8-1
> Severity: normal
> 
> Dearest maintainer,
> 
> The latest kernel upgrade fails to complete its installation on my system. If
> I remember correctly, the previous new kernel failed to install in the same
> way but I chose to work around it instead of reporting it back then.
> 
> The symptom is a failing postinst script because initrd is missing:

I recently found this bug myself while reviewing the maintainer scripts.
 
> If I'm reading the postinst script correctly, this error is from either
> line 383 or line 422, which is called from image_magic() if the
> destination path is neither missing nor a symlink. This is the case on
> my system, because I have set both do_symlinks=no and no_symlinks=yes in
> /etc/kernel-img.conf (what's the difference between them?).

do_symlinks = no disables creating symlinks for the 'default' kernel and initrd.
no_symlinks = yes enables copying to the default filenames.

> For new
> kernels, the initrd has not been generated yet (that happens at the end
> of the script) and cp doesn't handle that case as gracefully as ln does.

Yes.  This regression was introduced when we moved the call to update-
initramfs into a hook script (around version 2.6.38).
 
> Even though the failure mode is created by no_symlinks in kernel-img.conf,
> simply changing those settings does not allow the installation to
> continue. That's because the /initrd.img file still exists, and
> image_magic() is driven by the existing paths, not the config settings.
> Conversely, simply setting no_symlinks=yes in the config does not prevent
> a new kernel to be installed initially -- but as soon as a new initrd is
> generated (and the /initrd symlink is replaced with a file), the next
> kernel installation will fail regardless of the current config setting.

I'm afraid my answer to this is that this configuration is no longer
supported.  If many people were using it, I would try to fix it, but it
seems that yours was the only bug report.  Future kernel packages will
warn and will create symlinks instead of copying.

Ben.

-- 
Ben Hutchings
The most exhausting thing in life is being insincere. - Anne Morrow
Lindberg

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: