terryc wrote on 7/8/19 8:20 pm:
> On Wed, 7 Aug 2019 17:13:50 +1000
> "Ralph Ronnquist \(rrq\) via Dng" <dng@???> wrote:
>
>> terryc wrote on 7/8/19 4:39 pm:
>>> In the midst of removing a package that frequently crashes* and
>>> attempting a general package update/upgrade, somehow the package
>>> upgrade system has borked something.
>>>
>>> Specifically it seems to have come about following a
>>> sudo apt autoremove where a depreciated image was listed to go.
>>>
>>> Now I am at a state where I can do nothing package wise
>>>
>>> ..........Error Message........
>>> Removing linux-image-4.9.0-6-amd64
>>> (4.9.88-1+deb9u1) ... /etc/kernel/postrm.d/initramfs-tools:
>>> update-initramfs:
>>> Deleting /boot/initrd.img-4.9.0-6-amd64 /etc/kernel/postrm.d/zz-update-grub: /usr/sbin/grub-mkconfig:
>>> 32: /etc/default/grub: Syntax error: EOF in backquote substitution
>>> run-parts: /etc/kernel/postrm.d/zz-update-grub exited with return
>>> code 2 dpkg: error processing package linux-image-4.9.0-6-amd64
>>> (--remove):
>>
>> Maybe there's a spurious back-quote in /etc/default/grub ?
>
> If that is the case, then it has been placed there by a recent package
> as I've never touched it and the two other Devuan Ascii boxen have no
> problem. And line #32 of that file is actually a comment.
>
> I thought it might have referred to Line #32 of /usr/sbin/grub-mkconfig
> which s a reference to the contents of "$rootdatadir" but that is
> defined a few lines above as /usr/share. Plus it is identical(eyeball
> compare) on the affected and non-effected machine.
>
> Both the two non-effected machines have just today removed the
> linux-image-4.9.0-6-amd64
> from their boot options without trouble.
> And as webfu hasn't turned up any pointer, I'm a little stumped ATM.
>

Right. Not sure I can help you with the COB, but when I look at mine of
those files, I see a few technically non-balanced back-quotes in
/etc/default/grub and /usr/sbin/grub-mkconfig, although none of them
explaing "32", and all within double-quotes or comments.

You'll need to verify that /bin/sh is dash, and then sit and wait for
inspiration. Of course it might help with a manual initramfs update:
# update-initramfs -u -k all
or at least, that might give a new lead to the problem.

Ralph.