Reinstalling OpenSUSE to New Drive - Best Way to Manage GRUB2 Issues

I will soon receive a replacement SSD from Corsair (of whom I can only say good things!) that will once again become my OpenSUSE 13.1 drive. I currently have /dev/sda as my Win7 drive (NTFS) and /dev/sdc with both Win7 data partitions and OpenSUSE (swap, root, home) partitions. The new SSD will be /dev/sdb. My plan is to delete OpenSUSE from sdc, extend the Win7 partition to fill sdc space, boot from the OpenSUSE install DVD and install clean to sdb, and write the GRUB2 file to the MBR on sda, which will presumably overwrite the GRUB2 file that is currently there. This will result in GRUB2 giving me options at boot to start either Win7 on sda or OpenSUSE on sdb.

Does all this make sense, or is there a more sensible way to manage the GRUB2 file replacement process? If I were uninstalling OpenSUSE permanently, I’m sure there would be a better way to do this so that Win7 still booted properly, but in this case, I am expecting that the end result will give me a boot menu that does what I want.

What is currently on sdb? I am guessing you have an sdb, since you say you currently have an sdc?

Post the output of

fdisk -l

That is a lower case “L”, not a numeral one.

Yes, that’s a good point I didn’t mention. When I removed the failed SSD that was sdb, all the drives moved up. Once I put the replacement SSD back in the system, I would like it to be sdb again. Sorry, I didn’t make that clear. Here is the fdisk output without the replacement SSD installed:

Disk /dev/sda: 250.1 GB, 250059350016 bytes, 488397168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x6e90e1a7

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048      206847      102400    7  HPFS/NTFS/exFAT
/dev/sda2          206848   488394751   244093952    7  HPFS/NTFS/exFAT

Disk /dev/sdb: 500.1 GB, 500106780160 bytes, 976771055 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0xe32a7afb

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048   767057601   383527777    7  HPFS/NTFS/exFAT
/dev/sdb2       767057920   771248127     2095104   82  Linux swap / Solaris
/dev/sdb3       771248128   813193215    20972544   83  Linux
/dev/sdb4       813193216   976769023    81787904   83  Linux

Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes, 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk label type: dos
Disk identifier: 0x0cabd99a

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1            2048  1953521663   976759808    7  HPFS/NTFS/exFAT

Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes, 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0xe8900690

   Device Boot      Start         End      Blocks   Id  System
/dev/sdd1              63  1953520064   976760001    7  HPFS/NTFS/exFAT


Okay.

Here is the way I would do it.

When the new drive arrives, install it and use something like GParted to partition it.

Give it a partition equal to or larger than the size of your current root partition, and another partition equal or larger than the size of your current home partition. Just create the partitions, don’t bother installing anything.

Set the root partition with the boot flag on the new drive.

Also, create a suitable swap partition (although I would probably instead leave a suitable swap partition on one of the non-SSD drives).

Then, use dd to transfer your root from the sdc location to the partition you made for root on the new drive, and do likewise for the home partition.

At that point, come back here, let me know.

I will then (or someone will) guide you through recreating GRUB2 for the new drive and installing it to the root partition (not the MBR) on the new drive. (Okay, you could put it in the MBR, but my experience shows that it tends to be less problematic to go to the root partition. Besides, it is a little tricky making certain the GRUB goes to the correct MBR on the correct drive in a multi-drive system.)

You would just have to use the function key that gives you a list of drives at boot and lets you choose which drive to boot from, and there choose the new drive from the list when you want to boot openSUSE. On the system I am using tonight, that is the F11 key. I have seen it as F2 on some other systems and as F10 on other systems.

You probably know which is the right key for your machine.

Then, when you want to boot Windows, you just boot normally the way you do now.

Or, you can set the new drive as the first boot device in the BIOS, and it should have GRUB entries that will boot either openSUSE or Windows.

If you do it that way, Windows should never mess up your Linux boot, which it sometimes does when it overwrites the MBR on the Windows drive during certain Updates or System Repair operations.

On 2014-06-05 06:26, mxcrowe wrote:
>
> Yes, that’s a good point I didn’t mention. When I removed the failed
> SSD that was sdb, all the drives moved up. Once I put the replacement
> SSD back in the system, I would like it to be sdb again. Sorry, I
> didn’t make that clear.

No, the names like sda, sdb, flow around and can be reused. Don’t rely
on them.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

Absolutely correct, so when installing, make absolutely certain that you are installing to the correct drive. Don’t rely on those drive letters, because as Carlos says, they can change. Doublecheck before proceeding.

(BTW: Both Carlos & I prefer to Label our partitions, then we mount our partitions by Label instead of device name.)

On 2014-06-05 21:36, Fraser Bell wrote:
> (BTW: Both Carlos & I prefer to Label our partitions, then we mount our
> partitions by Label instead of device name.)

True :slight_smile:


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

Thanks, guys, for the detailed guidance.

Then, use dd to transfer your root from the sdc location to the partition you made for root on the new drive, and do likewise for the home partition.

Actually, since all the partitions on the SSD were lost when it died, the current installation on the spinning drive is just a temporary, so I had something to play around with while the drive was being replaced. I am fine just doing a clean install to the replacement SSD when it arrives and just delete the linux partitions on the spinning 500GB drive.

I will then (or someone will) guide you through recreating GRUB2 for the new drive and installing it to the root partition (not the MBR) on the new drive. (Okay, you could put it in the MBR, but my experience shows that it tends to be less problematic to go to the root partition. Besides, it is a little tricky making certain the GRUB goes to the correct MBR on the correct drive in a multi-drive system.)

Having done this a few times now, I’m pretty comfortable getting it to work from a GRUB boot menu at system startup, versus triggering a boot-order menu. It requires that I used the DVD installer (not USB) and select the non-UEFI DVD in BIOS prior to install. As long as I do that, it will create a nice GRUB menu and I can boot to Win7 on the sda SSD or OpenSUSE on the sdb SSD. I once thought it had to do with selecting both MBR and root as the boot locations, but I determined during the last couple installs that I just need to ensure UEFI is not involved and pick MBR only.

If you do it that way, Windows should never mess up your Linux boot, which it sometimes does when it overwrites the MBR on the Windows drive during certain Updates or System Repair operations.

I’ve never had that happen, but I guess if it does, I will have to run some sort of GRUB recovery utility.

the names like sda, sdb, flow around and can be reused. Don’t rely
on them.

So, perhaps the only easy way around that is to disconnect the other drives (other than sda) when I clean install OpenSUSE on the replacement SSD, that way it will be sdb by default and the other drives will become sdc, etc when reconnected.

Both Carlos & I prefer to Label our partitions, then we mount our partitions by Label instead of device name.

Yes, I’d like to do that, too. Is that something I can do in Gparted?

So, circling all the way back, I’m pretty sure that when I do the Linux reinstall on the replacement SSD, it will just replace the current GRUB menu in the MBR on sda (which provides boot options to Win7 on sda or the temporary install of OpenSUSE on the 500GB drive) and will now provide boot options for both Win7 and OpenSUSE (now newly installed on sdb (the Corsair SSD)). Then, when I reconnect the other spinning drives, I can just delete the temporary OpenSUSE partitions currently on the 500GB drive and expand the existing NTFS partition there to fill the entire drive, and I’m back to where I was before the SSD failed. Does this make sense?

Okay, that makes things a lot easier.

Having done this a few times now, I’m pretty comfortable getting it to work from a GRUB boot menu at system startup, versus triggering a boot-order menu. It requires that I used the DVD installer (not USB) and select the non-UEFI DVD in BIOS prior to install. As long as I do that, it will create a nice GRUB menu and I can boot to Win7 on the sda SSD or OpenSUSE on the sdb SSD. I once thought it had to do with selecting both MBR and root as the boot locations, but I determined during the last couple installs that I just need to ensure UEFI is not involved and pick MBR only.

Still, I would not install the GRUB in the MBR. Instead, in the BIOS, make the SSD the first boot drive. That way, you won’t have to call up the boot-order menu to boot.

Install the GRUB to the root partition only, make that the partition with the boot or active flag, and it will contain the call to boot Windows, as well as to boot openSUSE.

The generic Windows MBR (use the command I gave you earlier to get that MBR) will just refer the process to GRUB in the boot/active partition, so you will be good to go. And, a lot easier to fix if anything does mess up the GRUB boot process.

So, perhaps the only easy way around that is to disconnect the other drives (other than sda) when I clean install OpenSUSE on the replacement SSD, that way it will be sdb by default and the other drives will become sdc, etc when reconnected.

Nope. If you are going to use the labels method, just create the Windows labels as I said, and create labels on the Linux partitions. When you install, you will choose Advanced Partitioning, and in there the labels will be plain as day, so you will not have to worry about making the wrong choice for your partitions or drives. You will be able to see exactly what you are doing with the labels in place.

And, yes, you can create those labels in Gparted.

When you are ready to start the actual openSUSE install, I will point you to a guide that will show you how to set up the installer to mount the Linux partitions by label.

So, circling all the way back, I’m pretty sure that when I do the Linux reinstall on the replacement SSD, it will just replace the current GRUB menu in the MBR on sda (which provides boot options to Win7 on sda or the temporary install of OpenSUSE on the 500GB drive) and will now provide boot options for both Win7 and OpenSUSE (now newly installed on sdb (the Corsair SSD)). Then, when I reconnect the other spinning drives, I can just delete the temporary OpenSUSE partitions currently on the 500GB drive and expand the existing NTFS partition there to fill the entire drive, and I’m back to where I was before the SSD failed. Does this make sense?

Yes, this does make perfect sense, although I still suggest the above change to the GRUB location and making the Corsair the first boot drive. Note that it can still wind up as sdb, because that is actually mostly determined by the drive position on the cables/controller, and so everything should work smoothly.

Ok, I will try it that way. Not quite as comfortable with that approach since it is quite different than what was working before the SSD died, but I recognize that this might be a better way to structure things longer term so that Windows does not somehow clobber the boot menu in the future.

Gerry, your process worked great. All drives and partitions are labelled clearly, the GRUB file is with the root partition on the replacement SSD, and the system boots cleanly into either O/S following the presentation of the GRUB menu at boot. All works well and is now set up properly.
Thanks for all the inputs and guidance!

Great to hear!

And, of course, you are very welcome.