Bug#867804: cdrom: Stretch netinst CD installs grub config file incorrectly

[Hazel Russman]

On Mon, 10 Jul 2017 17:50:45 +0100
Steve McIntyre <steve at einval.com> wrote:

> Control: reassign -1 grub-common
> 
> On Mon, Jul 10, 2017 at 05:27:08PM +0100, Steve McIntyre wrote:
> 
> OK, I can see you have lots of OSes installed on your computer. I can
> see os-prober parsing lilo config files from other installations. :-)
> 
> What I *don't* see is any indication of any failures, though. Instead,
> grub-install claims to have succeeded:
> 
> Jul  8 07:42:53 grub-installer: info: Installing grub on '/dev/sda'
> Jul  8 07:42:53 grub-installer: info: grub-install does not support --no-floppy
> Jul  8 07:42:53 grub-installer: info: Running chroot /target grub-install  --force "/dev/sda"
> Jul  8 07:42:54 grub-installer: Installing for i386-pc platform.
> Jul  8 07:43:05 grub-installer: Installation finished. No error reported.
> Jul  8 07:43:05 grub-installer: info: grub-install ran successfully
> 
> I'm wondering if *maybe* something has been confused by those lilo
> setups, but I'll admit that I'm not sure what's happening there.
> 
> >>I normally prefer lilo to grub, so I reinstalled lilo from one of my
> >>other Linuxen, but I could do a grub-install in Debian to test out the
> >>grub.cfg file, which I've now renamed. Would you like me to do that?  
> >
> >I'll get back to you...  
> 
> Yes please, that might be very helpful. Run as
> 
>  "grub-install -v /dev/sda"
> 
> and capture the output please?
Fine, I'll do that after I've walked the dog. But in the mean time, here is my take on the source of the problem:

Grub did indeed install correctly. I got a normal grub prompt, not a rescue prompt, which means that both boot.img and core.img were in their proper places. The problem was a misnamed grub.cfg file, and that is not created by grub-install but by grub-mkconfig.

I have looked at this script and have found that it creates a file called outputfile.new where "outputfile" is the argument to the --output option. It switches standard output to this file. Then, if all its daughter scripts have exited successfully, it renames outputfile.new to outputfile.

In this case it was obviously given the name grub.cfg, so it created grub.cfg.new. It then ran all the sniffer scripts to find my other systems. But one of those scripts must have failed so the renaming never took place and the file was left as grub.cfg.new. I'll report back again when I've retested grub, but in the meantime, I suggest you have a look at grub-mkconfig. Is there anything about my system that could have spooked one of those daughter scripts?

-- 
If any members of GCHQ are reading this, shame on you! I fought for your right to belong to a trade union and now you are taking away my right to privacy?

H Russman