terryc wrote on 7/8/19 8:20 pm: > On Wed, 7 Aug 2019 17:13:50 +1000 > "Ralph Ronnquist \(rrq\) via Dng" <dng@lists.dyne.org> 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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng