1

I started using a system that has sat dormant for about a year, so unfortunately some of the setup details are a little hazy. Grub is loaded with 1 instance of Ubuntu 14 inside the grub loader. This instance can only see about 4GB of the much larger (~200+GB) drive. I think this means the entirety of the grub partition is only 4GB.

There is a second instance of Ubuntu, this time Ubuntu 16 on the PC. When it boots up it does not go through the Grub dialogue. It also has access to much more of the hard drive (Don't have the exact number, but well over 150GB).

When the computer boots up I arbitrarily get grub->14 or 16. It used to be I mostly got 16 which was fine, it has all the work I do. Occasionally it would boot grub->14 which has no work and is basically a blank install on a small drive. I would reboot and again end up at 16. Not ideal but I'm lazy, don't reboot much, and it was workable. However recently 16 did an updated, needed a reboot and now it's only booting grub-14.

Based on the behavior above I believe 16 and grub are logical siblings when grub should be a logical parent of ANY operating system on the machine.

I'm looking for options to dig myself out of this hole. A complete reinstall is an option but not preferred. I don't have a problem blowing away the grub->14 partition as it was a failure. I am interested in what if any are my options in getting 16 inside a grub control after the fact.

Edit1: There is a comment suggesting a grub update and a duplicate flag indicating the same. I ran grub update grub 2 update both with reboots. No difference in behavior. Is there a configuration file that needs a new entry? If so do I need to indicate the location of the missing OS? How would I find out such a thing?

Edit2: I ran lsblk and sudo parted -l to get the following. Apologies for the screenshot. The 14 install doesn't have the right network card drivers for connectivity to copy/paste.

lsblk output parted output

Edit 3:pvdisplay produces the following

pvdisplay output

Eldergeek asked the following in the comments:

Just so I'm clear, you installed Ubuntu 14.04 on one drive and 16.04 on the other within hours of each other?

No, originally I installed 2 copies of 14.04. I think my plan was to put the bootable details on the faster of the two drives. I mixed them up and did a second install on the otber drive, That was recently upgraded to 16.04 shortly before I lost all access to that install. If I prioritize that drive I get a grub rescue prompt. I believe this is a new development, not positive though.

The intention is to boot the 16.04 Ubuntu and provide additional space for that.

Yes

The 14.04 Ubuntu is unimportant

Yes

muru
  • 197,895
  • 55
  • 485
  • 740
BZN_DBer
  • 111
  • 5
    grub is a boot loader and typically lives in the MBR of the drive. There's no need to do a complete re-install. Just update grub – Elder Geek Nov 30 '16 at 15:16
  • @ElderGeek thanks but a simple update was not sufficient. – BZN_DBer Dec 01 '16 at 01:44
  • Weird. Looks like the 14.04 system is a USB drive or something that's intermittently being detected at boot. In either OS, run lsblk and sudo parted -l and add the output to your post, please. – muru Dec 01 '16 at 01:47
  • @muru done and done – BZN_DBer Dec 01 '16 at 02:03
  • Based on your updated info, it looks very much like at least the partition table from /dev/sda is identical to /dev/sdb. This is odd considering the disparate sizes of the disks involved. Did you by any chance run dd using one of these as the source and the other as the target? Have you tried using testdisk to search for overwritten partitions? – Elder Geek Dec 01 '16 at 15:19
  • @ElderGeek I did not run dd. I installed both operating systems with within hours of each other from the same source disk. I believe I was aiming to boot from the faster solid state drive leaving the larger drive for storage purposes. I'll check testdisk when I'm back in front of the machine. – BZN_DBer Dec 01 '16 at 16:11
  • Just so I'm clear, you installed Ubuntu 14.04 on one drive and 16.04 on the other within hours of each other? I'll admit I'm having a hard time parsing your situation. Be that as it may, I'm seeing some lvm volumes so it might be beneficial to determine which physical volumes are holding what and if something is awry there. Please [edit] your post to include the output of pvdisplay and let me know if the following statements are true. A) The intention is to boot the 16.04 Ubuntu and provide additional space for that. B) The 14.04 Ubuntu is unimportant. – Elder Geek Dec 01 '16 at 18:15
  • @ElderGeek. No I installed 14.04 twice within hours. I used one of the installations and at some point upgraded to 16.04. The other install of 14.04 was not really ever used, but now it is the only one I can boot into. – BZN_DBer Dec 01 '16 at 18:23
  • Please drop me a comment when you've [edit]ed in the output of pvdisplay and which if any of the statements A & B are true. Thank you for helping us help you! – Elder Geek Dec 01 '16 at 18:31
  • @ElderGeek thanks for taking the time to help me fumble through this. Requested edits made. – BZN_DBer Dec 02 '16 at 02:40

1 Answers1

1

The first thing we have to do is determine where the critical data is. Since you state that it's on the volume that contains Ubuntu 16.04 we can simply mount the usual suspects and examine the content of /etc/issue On a 14.04 install (the one you don't want) the content will be start with:

Ubuntu 14.04

On a 16.04 install (the one you want) will of course start with:

Ubuntu 16.04

In the case of /dev/sdb5 and /dev/sda5 these partitions appear to contain volume groups.

I assume you already have the lvm2 package installed. You can determine what logical volume to mount on each of these partitions and how to do so by following the guidelines in both the Q & A here.

Once you've successfully mounted the correct volume and located your data it's a fine idea to back it up. There are numerous tools available for this task. I would avoid backing up to either of the internal drives (sda and sdb) in question at this point for safeties sake and ideally backup the critical data to another drive entirely.

Once you've correctly determined the appropriate installation and backed up your critical data you can reclaim (de-allocate) the space used by the previous installation that you don't need and then simply extend the volume you wish to add space to. Or you could simply revert to your original plan of booting and running the OS off of the SSD (dev/sdb) and utiltize /dev/sda for your /home directory (data storage)

Community
  • 1
Elder Geek
  • 36,023
  • 25
  • 98
  • 183