Installed new debian OS now cannot access old OS
 

I installed a new debian OS via USB onto a prepared partition (sdb3).
However, the launcher seemed to be insisting on installing grub and I couldn't find a way of de-selecting grub installation.
To avoid any problems, I loaded grub onto the same partition I was installing in (sdb3). I think this means the new install has overwritten the MBR.

Before the installation, sda1 (i.e. a different hard disk) was the original OS which placed grub in the MBR.
Now when I boot, grub can see sda1, but it won't boot up. I booted sda2 (an OS on the same disk) and did a 'grub-update' but this hasn't worked.
How can I boot into the OS on sda1 again?

I was wondering if it's possible to do this without a live USB as I currently have a debian OS written to it!

You could try running update-grub instead of grub-update.

Ah yes, that's a good one.
What I meant was I used on sda2 and it didn't sort out the problem. Of course, 'grub-update' is nonsense and simply brings up an error message.

I've opened the boot directory in sdb3 which is the new install and which has GRUB2 booting from the MBR. The boot directory has the following files:
So I'm guessing that's how the boot directory should look after a successful new install.

I looked at the boot file of an OS which GRUB2 will open (sda2):
It appears it has its boot files from its original install and new boot files written to it from the new install (sda3).
I'm wondering if I should delete the old boot files?

I then opened the boot directory in the problem OS (sda1) which GRUB2 sees but won't boot up. The files in there are as follows:
So it has its original files and new files written to it from the new install.
But it also has extlinux, memtest and multiboot files.

So I'm wondering if I deleted the extra files so the boot directory looked like the one in sda2, then perhaps GRUB2 will boot sda1?

install grub on the HDD / (MBR) that you want grub on then update it to get back both of your systems.

providing that you are actually booting into at least one of them, remembering that the one you used to install grub has the control over grubx

and YES you can just over write them (the old grub files) - I've done this many times...

I installed grub onto sdb3 when installing jessie onto the same partition. The launcher did its own 'update-grub'.
So what you've said has already happened while using debian-launcher-installer.
The problem is the grub menu shows sda1 but locks up when I try to boot it.

If I use the terminal on the sb3 install and do the following:
then will this allow me to boot sda1?

Yes, but what about the extlinux, memtest and multiboot files in /boot on sda1? Can I delete those too?
I'm wondering if those files are unnecessary (because they're not in sda2) and whether they were generated from the conflict created by installing grub to the mbr on the new install?

take off the 3 /dev/sda no numbers
numbers are your partitions, not the hdd mbr section.

that is where your files are at but grub I put on MBR and when you update it it finds what it needs to know where to look on boot up of your system(s).

fyi
you can install grub
/dev/sda
/dev/sdb
/dev/sdc

not

/dev/sda1
/dev/sdb1
/dev/sdc1

just logially guessing, the ones on sda1 are for the system on sda1 and the others are for the other system on that other partiton.

so just back up the files in question, doing it like this renames them , and "removing" them at the same time. Because they are no longer the same name that the system looks for.

mv -v filename filename.bk

this way if it messes you up then all you have to do is reverse the proccess to put the files back.

mv -v filename.bk filename

if no problems arise then I'd say it is ok to delete them afterwards..

better safe then sorry.

It hasn't worked. I still can't boot the OS in sda1.
I initially renamed the 'extra files' in /boot of sda1 and ran:
After that, I still couldn't get into sda1.
So I restored the correct names of the extra files and tried to boot the OS from grub again, but nothing happened.

Usually, if there's a problem with grub, then it can't see the partition. But in this instance it can see it but it won't boot the OS.
I haven't made any changes to sda1 except for the fact I made a new install where a new grub bootloader was installed which changed the location of the mbr.

ok, you are doing this the hard way.

sometimes i get confronted with an unbootable system, and for situations like this i have my rescatux cd (now usb) handy.
"restore grub" => done.

NO NO NO
this
should show you a /dev/sda1 now install it on
then update it

Wizard – Restore Grub with Super Grub2 Disk

as far as I know he has grub, he just did not install it properly to pick up his other OS prior to install. now grub is confused.

just reinstall /dev/sda then update grub ,, it picks up the other sys's and adds them to the list, done.

.. whatever works, as long as it works...

Yes, I've read an old article on grub where a live cd is recommended.
However, there is also a 'Boot Repair' program which can also be used from a terminal.
I'm going to try this option first before having to create a live usb. But I'll this tomorrow.

what do you mean by lock up? what kind of error message or that the last line before the lock up.

Yes - I did install grub to the hdd and not the partition. Then I updated grub. But for some reason it didn't work.
I'm going to look into this a little more, but like you say, it does look like I'll need a separate repair pgm to sort it out.

I think you've said before you've employed this method and it works.
For some reason though, there must be some other issue in my case, as its not quite working.
I'll look into 'Boot Repair', give that a try and if that fails I'll create a live usb as I currently have jessie dvd.iso installed on the usb.