Bug#730073: linux-image-3.11-2-amd64: postinst fails with no_symlinks=yes
Hi Ben,
> this configuration is no longer supported.
Fair enough. Thanks for considering.
Does that mean /etc/kernel-img.conf will disappear completely?
Arno
________________________________________
From: Ben Hutchings <ben@decadent.org.uk>
Sent: Sunday, June 5, 2016 12:18:50 AM
To: 730073@bugs.debian.org; Arno
Subject: Re: 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
Reply to: