19.1 along side Windows 7 gone wrong

[InkKnife]

I took a blanked 256GB SSD drive, installed Win7 first, installed Mint second, used the Mint installer to resize the Windows partition to 100GB, 150GB for Mint. After that Mint asked me to choose a mount point which I was not sure about so I chose "/" on the Mint partition for the boot loader. Root, right? The Mint installer was fine with that and proceeded to the finish.
On reboot I have no grub menu and cannot boot Mint. Windows boots fine.
What did I do wrong?

[catweazel]

What did I do wrong?

Possibly nothing. If you have more than one disk, press your machine's BIOS boot key and try booting to the other drive. Sometimes the the key is F10 for some motherboards, F2, and F12 for others. You'll have to find that out yourself. If it boots ok then you can set the device that LM is on as the default boot device. You should be able to boot to Windwoes from the LM GrUB menu.

[InkKnife]

F10 does nothing on my system. F2 brings up the BIOS setup and F12 brings up the one time boot menu but both the BIOS setup and the one time boot menu only list devices, not partitions.
When I choose the split drive my PC just boots into Windows.
I have 18.3 on another drive if that makes any difference.

[InkKnife]

I should mention I have done all this using legacy mode not EUFI

[rickNS]

so I chose "/" on the Mint partition for the boot loader. Root, right?

Pretty sure wrong, the boot loader should go on the disk (sda example) not in any partition (sda1, or / examples)

[arvy]

I chose "/" on the Mint partition for the boot loader. Root, right? The Mint installer was fine with that and proceeded to the finish.
On reboot I have no grub menu and cannot boot Mint. Windows boots fine

Is your system and the existing Windows 7 installation configured for booting in so-called "legacy" BIOS-MBR mode? if so, what you are seeing would be the natural and inevitable outcome of choosing to install Grub into the Mint partition's boot record (PBR) rather than into the drive's master boot record (MBR) and it could be dealt with in either of two ways. You could install Grub into the drive's MBR replacing the Windows boot loader, or you could add an option to the Windows boot manager's menu to boot Linux Mint. The latter is a bit tricky, but it can be done if that's your preference.

[pbear]

I have 18.3 on another drive if that makes any difference.

Does this still boot correctly? If so, it's probably the primary Grub and you should be able to solve this problem by running sudo update-grub there. In which event, installing the bootloader to the root partition of the new installation was correct, but only because it's a secondary Grub.

[InkKnife]

I have 18.3 on another drive if that makes any difference.

Does this still boot correctly? If so, it's probably the primary Grub and you should be able to solve this problem by running sudo update-grub there. In which event, installing the bootloader to the root partition of the new installation was correct, but only because it's a secondary Grub.

OK, that worked to get me into 19.1. When I tried to update grub from 19.1 I got this:

Code: Select all

Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.15.0-20-generic
Found initrd image: /boot/initrd.img-4.15.0-20-generic
Found memtest86+ image: /boot/memtest86+.elf
Found memtest86+ image: /boot/memtest86+.bin
error: invalid volume.
grub-probe: error: cannot find a GRUB drive for /dev/sda1.  Check your device.map.
Found Linux Mint 18.3 Sylvia (18.3) on /dev/sdb1
Found Windows 7 on /dev/sdc1
done

Looks like I should have installed grub in /sdc but installed in /sdc5.

Can I correct this from 19.1?

[rickNS]

Can I correct this from 19.1?

Yes,
https://howtoubuntu.org/how-to-repair-r ... tu-live-cd

Or, (fairly recent)
https://linuxhint.com/ubuntu_boot_repair_tutorial/

[pbear]

Looks like I should have installed grub in /sdc but installed in /sdc5.

Can I correct this from 19.1?

Well, no, you shouldn't have installed Grub in sdc unless you wanted 19.1 to be primary Grub. Frankly, it seems rickNS and arvy overlooked that this is a multi-boot scenario. Secondary Grubs are common in multi-boot systems. You can reinstall Grub, which would make 19.1 the primary Grub, but it's not necessary. Only worth doing IMHO if you're planning to ditch 18.3 any time soon. Also, you may find 18.3 acting strangely when you overwrite the MBR, as it will be left without a Grub. Will boot from the new primary, but I've had trouble with orphaned systems not starting and shutting down cleanly. At least that's what I observed when got clever and set up a multi-boot with only primary Grub, using ubiquity -b to install the others. Ended up redoing the whole thing, putting secondary Grubs on the corresponding root partitions just as you did here. Works fine.

[InkKnife]

Looks like I should have installed grub in /sdc but installed in /sdc5.

Can I correct this from 19.1?

Well, no, you shouldn't have installed Grub in sdc unless you wanted 19.1 to be primary Grub. Frankly, it seems rickNS and arvy overlooked that this is a multi-boot scenario. Secondary Grubs are common in multi-boot systems. You can reinstall Grub, which would make 19.1 the primary Grub, but it's not necessary. Only worth doing IMHO if you're planning to ditch 18.3 any time soon. Also, you may find 18.3 acting strangely when you overwrite the MBR, as it will be left without a Grub. Will boot from the new primary, but I've had trouble with orphaned systems not starting and shutting down cleanly. At least that's what I observed when got clever and set up a multi-boot with only primary Grub, using ubiquity -b to install the others. Ended up redoing the whole thing, putting secondary Grubs on the corresponding root partitions just as you did here. Works fine.

I want to ditch 18.3, this is my old system and I want to migrate to 19.1 and remove that SSD to use in another computer.
Since my Windows and Mint 19.1 installs are virgin I am thinking I just might nuke the whole drive and start over from scratch. Seems easier than trying to repair my screw up.

[pbear]

Then, by all means, go for it.

Also, thinking it over, occurs to me I might be over-generalizing about orphaned systems, which is to say your 18.3 Grub might be fine pending removal. Notably, in the multi-boot scenario I mentioned, there were no Grub files on the secondary systems. Here, there will be.

[AndyMH]

I just might nuke the whole drive

Probably easiest. Second time around, either leave the space you created unallocated and choose the 'install alongside option' in the installer or if you go 'something else' which sounds like what you did before - at the bottom of that screen somewhere is a box where you can tell mint where to install grub.

[arvy]

Frankly, it seems rickNS and arvy overlooked that this is a multi-boot scenario.

Well, not entirely, pbear. But, in my case at least, your comment is justified nevertheless. My assumption that InkKnife wanted the newer Mint installation as primary was without any explicit basis at that point.

I want to ditch 18.3, this is my old system and I want to migrate to 19.1 and remove that SSD to use in another computer. Since my Windows and Mint 19.1 installs are virgin I am thinking I just might nuke the whole drive and start over from scratch. Seems easier than trying to repair my screw up.

That's entirely up to you, of course, but just installing Grub to the MBR isn't difficult and would be the default end result anyhow.

[pbear]

Further to arvy's suggestions, Ubuntu Help says:

If Ubuntu is operating normally, boot into the working installation and run the following command from a terminal.

X is the drive (letter) on which you want GRUB to write the boot information. Normally users should not include a partition number, which would produce an error message as the command would attempt to write the information to a partition.

sudo grub-install /dev/sdX # Example: sudo grub-install /dev/sda

This will rewrite the MBR information to point to the current installation and rewrite some GRUB 2 files (which are already working). Since it isn't done during execution of the previous command, running sudo update-grub after the install will ensure GRUB 2's menu is up-to-date.

Surely, sudo grub-install /dev/sda is simpler than a reinstall. Besides, if you're reconciled to reinstalling, worth trying as a learning exercise.

[rickNS]

Frankly, it seems rickNS and arvy overlooked that this is a multi-boot scenario.

Well, not entirely, pbear. But, in my case at least, your comment is justified nevertheless. My assumption that InkKnife wanted the newer Mint installation as primary was without any explicit basis at that point.

That was my assumption as well, that Mint 19 would being the newest (most used ?) OS it should be the one in control.

Didn't overlook the multi -boot aspect, it's in the title.

Agree with pbear, and avry that surely this fix, would be a lot less time consuming than re-installing two OSes, and if willing to do that anyway have nothing to loose by trying.

[InkKnife]

I installed Grub from 19.1, everything looked fine, It saw both systems, windows and Mint, on the drive when I ran update, rebooted to an invalid volume error and it dumped to grub rescue mode.
UGH.

[pbear]

Well, darn. Unfortunately, I'm only now learning this grub reinstall and boot repair stuff, so I don't know what step is missing. Probably simplest to do what you wanted and reinstall the whole system. At least now you can say you gave grub reinstall a shot.

[arvy]

I installed Grub from 19.1, everything looked fine, It saw both systems, windows and Mint, on the drive when I ran update, rebooted to an invalid volume error and it dumped to grub rescue mode.

To which drive's MBR did you install Grub? Check your system boot order settings. If that drive is not at the top of the list, move it up so that it is. And either get rid of or update any higher drive discovery order Grub configurations that may no longer be valid.

Even if you reinstall everything, you're quite likely to encounter some such difficulties if you're not clear about how your system's start-up configuration relates to multi-booting OS setups and their MBR/PBR installations, especially if you want each bootable independently. Keep in mind too that system boot order can and often does differ from drive discovery order, a fact that may be particularly significant for multi-version Linux setups.

[InkKnife]

I installed Grub from 19.1, everything looked fine, It saw both systems, windows and Mint, on the drive when I ran update, rebooted to an invalid volume error and it dumped to grub rescue mode.

To which drive's MBR did you install Grub? Check your system boot order settings. If that drive is not at the top of the list, move it up so that it is. And either get rid of or update any higher drive discovery order Grub configurations that may no longer be valid.

Even if you reinstall everything, you're quite likely to encounter some such difficulties if you're not clear about how your system's start-up configuration relates to multi-booting OS setups and their MBR/PBR installations, especially if you want each bootable independently. Keep in mind too that system boot order can and often does differ from drive discovery order, a fact that may be particularly significant for multi-version Linux setups.

I have grub installed at sda, the 64GB drive with 18.3 on it and sdc, the 256GB drive with Windows and Mint 19.1 on it.
When I unplug the drive with 18.3 to try and force the 256GB drive into boot I get a"no such device found" error and Grum Rescue followed by a command prompt.