Has anyone else had this grub problem after installing Stretch?
 

I did a clean install of Stretch rather than upgrading because my Debian system has gradually become cluttered up with abandoned experiments and I wanted to make a fresh start. When I rebooted, I got stuck on a GRUB prompt and had to complete the boot by hand.

The problem turned out to be that the grub configuration file in /boot/grub had been given the name grub.cfg.new instead of grub.cfg. This was using the netinst image and the graphical installer. I've reported it upwards using reportbug.

It sounds like a bug in the installer.

That's what I reported. I'm in a dialog with a dev now. I'll be happy to carry out any tests he asks me for. But I think I've found a possible locus for the problem. I've just been looking at the grub-mkconfig file, which I assume the installer uses (it's also used regularly by update-grub). This script creates grub.cfg.new if it finds a grub.cfg file already in existence, then renames it at the end. Now I don't think it should do this in a fresh install, but maybe it was looking in the wrong place.

We've identified the immediate problem. The grub.cfg file that was created had syntax errors; that's why it wasn't being renamed. Presumably a non-functioning cfg file is safer than a corrupt one. Now the guy at the other end is trying to find out why grub-mkconfig screwed up. It may have something to do with the grub os-sniffer's habit of trying to pick up data from any lilo.conf files that it finds while browsing around partitions. I didn't even know it did that!

Now I have Crux, LFS and an obsolete LFS that I used as a build system for the current one (that partition will in turn become the home of my next LFS with the present one as build host). Crux uses lilo and I have borrowed the source code for LFS too, although officially LFS uses grub. So that makes three different lilo.conf files, one badly out of date. No wonder the script had hiccups!

[rant]
This illustrates beautifully why I hate grub. I'm coming to hate it as much as some people hate systemd. It's bloated and invasive. Since I have three lilo.conf files, all containing much the same data (so that I can update lilo from either Crux or the current LFS), the grub.cfg file that was created had multiple entries for all my systems, including the obsolete LFS (which the current lilo.conf files have commented out). Even if it hadn't been buggy, it would have given me a huge, unwieldy menu with multiple duplications.

Some of you may ask why, in that case, I installed grub at all. If I had said "no", it would probably have asked me if I wanted lilo instead. At least that is my reading of the Stretch installation notes. But I have found that Debian updates go more smoothly if Debian at least thinks that it is using grub. Debian tends to create a new initrd image if any of the basic tools gets upgraded; then, if it knows you are using lilo, it tries to run /sbin/lilo immediately, and God help you if you don't have all your bootable partitions mounted.

I'm happy to install grub temporarily as a test for fixing this bug, but then I'm going back to lilo. [/rant]

Interesting. That sort of problem is the reason why I went all in for grub and ditched lilo.

But anyway, to help solve your problems, I have found with Debian 9 that the best thing for many weird situations is to simply remove grub-pc using apt-get remove grub-pc

This will tend to leave some unused junk files lying around, but no big deal. Any sort of update to basic tools or whatever will indeed create a new initrd, but that's as far as it goes if grub-pc is not installed (nor lilo). You'll have to manually copy over the new initrd and vmlinuz to wherever your actual boot setup expects them to be, but if you forget it'll just boot up with the old ones.

I use this for my various systems that use NFS boot, PXE diskless boot, RAMBOOT, and so on. These weird setups bomb update-grub, and even if it didn't, update-grub would just uselessly update some grub files that aren't actually used to boot the system anyway.

I was going to ask if that was possible. I seem to remember that in the past you couldn't uninstall packages that apt had marked as essential.
Where are the new ones stored then if not in /boot? Your solution seems to be exactly what I want.

The updated initrd and vmlinuz files will indeed be stored in /boot. However, this means whatever location /boot is in /etc/fstab of the Debian setup. This shouldn't be the same as whatever boot partition/system is actually being used by the system. When you uninstall grub-pc, the Debian OS will no longer have the ability to update-grub. In other words, it is no longer trying to "mastermind" the boot partition/system.

I guess this is fine if you want to manually update grub.cfg and you're okay with not getting security updates to grub itself. But I'd personally be more comfortable using some Linux install (not the Debian one) "masterminding" the multi-boot system (whether grub or lilo or whatever).

I don't use a boot partition (although the LFS team do recommend it for a multiboot setup). Instead I keep my kernels in simple boot directories on their respective partitions. Each system is thus completely insulated from the others. I think that is the simplest solution conceptually. So Debian's boot directory is on the Debian root partition (sda7) and that's where the kernel and initrd currently are and should remain.

If I got rid of grub-pc, nothing would be using grub.cfg any more, so there would be no need to update it. I would just run /sbin/lilo on my next non-Debian boot, which would probably be LFS because that has become my main system. The reason I have two lilos is simply "belt and braces". If LFS becomes unbootable, I can always run lilo from Crux and vice versa. That's how I ran things for years before I did this new Debian install and I've never had any problems with it.

That should work fine. So long as lilo scans and finds the Debian initrd/vmlinuz in its boot directory (as well as all of the other OS's), then you should be good. Or if you have to do some manual configuration of lilo...whatever you need to do.

So, just so you know, it is indeed possible to install Debian without installing grub (nor lilo). So, the next time you feel like installing Debian (if ever), tell it to not install grub when you get to that point in the installer (it will always ask to confirm where you want to put it, before actually doing it). When you do so, of course, the install will not initially have anything to boot it up. So, you'll have to boot up into another OS and do what you have to do to update lilo to let it boot the Debian install.

Personally, I don't care to have more than one "mastermind" OS, like you've got. If that one "mastermind" gets messed up, then sure I'll have to rescue by booting off a liveCD or network or USB or whatever. No big deal, to me. Basically, my steps are:

1) Boot up to a USB install of Debian.

2) Log in as root and run "update-grub". This will autodetect all OS's on local drives and update /boot/grub/grub.cfg to include all of them as options.

3) Reboot and select the install I'm rescuing.

4) Remove USB drive

5) Run update-grub, grub-install, and such to get the boot system working the way I like.

But then, I don't play fancy games with chain loading and other things like that.