I haven't removed /etc/grub.d/memtest86+ myself: maybe it has been declared a configuration file at some point of time and/or some intermediate version of memtest86+ decided to remove it. The independent askubuntu experience would suggest something like that.
I have to admit that _now_ purging memtest86+ and reinstalling it via apt-get install also installs the memtest+ program. So while I really had to put up a fight until I got /etc/grub.d/memtest86+ back into my system, I cannot at the current point offer a recipe for how it got lost originally. The anecdotal report from the linked Askubuntu question would suggest that I am not alone in this particular respect but I am currently not able to state how to get there. The system in question might have been changed from an i386 system to an amd64 system without installing from scratch. I'd not rule out that the procedure changing the packages and architecture to amd64 might have been involved. At the point of time of reporting the problem, I thought I had a better grasp of the situation. Maybe a removed conffile should be treated differently from a changed (like empty) conffile? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1766310 Title: apt-get install memtest86+ fails to create /etc/grub.d/20_memtest86+ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1766310/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
