1

The lab I work for recently got a new Dell Precision Tower 5810. We have a 4TB HDD in there in addition to the smaller one it traditionally comes with. Because the larger institution has standardized IT support, we cannot mess with the smaller drive and thus must use the 4TB for booting Ubuntu. I am trying to install Ubuntu 14.04 from a LiveCD which we have used in the past. Previous installations were successful on other computers of the same product name. The largest differences between the new computer and the old ones, as far as I know at the moment, is that the new computer has next-version processors and 2x the additional HDD space.

When I install Ubuntu on the HDD, it claims to be successful. Furthermore Windows' disk manager, although unable to identify the Ubuntu partitions, acknowledges that something is there. However, when I try to boot the computer from the 4TB drive, it insists it cannot find a bootloader.

I have reformatted the drive and reinstalled Ubuntu but that does not help. While reinstalling Ubuntu, I have also tried putting it in different sections on the HDD (ex. beginning versus end of the drive). I have also used the LiveCD to attempt a purge of Grub; no success there.

Because of this, I am starting to think that the computer just isn't able to boot from a 4TB drive. However, I have yet to find documentation to support this idea.

Does anyone have any ideas? Please keep in mind, I don't have much depth when it comes to the technical aspects of computers.


Edits:


Per a comment below, I am moving some relevant information into the original post.

Here is the boot info for the initial state of the issue. http://paste.ubuntu.com/23920806

I thought the issue might be were Grub was installed so I changed it and got the following. http://paste.ubuntu.com/23921965

I think I might have found a post about a similar problem, but there is no answer. Boot-Repair: "core.img can not be found"

To clarify, we are installing Ubuntu 14.04.3 on a secondary drive which has been partitioned using GPT. We use legacy boot. We install Grub on the secondary drive and then change the BIOS settings to boot from there instead of the primary drive. We do this using a live cd. This procedure has worked on previous Dell Precision Tower 5810s that have 2TB secondary drives. We are now trying to do this for a 4TB secondary drive. Based on the boot info, it appears that grub is not looking in the correct place for one of its image files. However, I have not been able to find a way to correct this. I have tried reinstalling Grub as well as reinstalling Ubuntu. In the case of reinstalling Ubuntu, I have tried both with and without reformatting the entire drive.


So, I tried to do this with a 2TB drive just like we have in the past. As can be seen at the following boot info page, it does not appear to have the same missing image file issue. However, the computer still will not boot from it. Please note that in this case, the 2TB drive is in the new computer so it is sdb not sdc. http://paste.ubuntu.com/23955960/


So, it was brought to my attention that using a GPT partitioned drive for Grub requires a dedicated Grub partition. I was previously unaware of this because that particular information appears as a short paragraph in the Grub installation instructions (https://help.ubuntu.com/community/Grub2/Installing#BIOS.2FGPT_Notes) but is not in the general Ubuntu installation instructions. At this point, I have put the 4TB drive back into the new computer and have resumed attempts to install Ubuntu on it. However, despite following the online instructions to the best of my knowledge, Grub still does not work. Based on the boot info, the previous issue of a missing image file appears to have re-emerged. The following boot info is from after an attempt to purge and reinstall Grub. The screenshot shows what GParted displays when examining the 4TB drive. When installing Grub, during both Ubuntu installation and Grub reinstallation, I select sdb as the installation location for Grub.

http://paste.ubuntu.com/23958163/

Screenshot with GParted showing the 4TB drive partitions


As requested by oldfred, I have checked the Secure Boot settings. I am working on Windows 7 Enterprise so msinfo32 does not display this status. However, I was able to check by accessing the boot settings upon booting the computer. If anyone knows a simpler method, feel free to share. Regardless, below are two images showing the current Secure Boot configuration for the computer in question.

Image of computer screen showing legacy ROMs enabled

Image of computer screen showing Secure Boot disabled


Reinstalled but not purged using Boot-Repair: http://paste.ubuntu.com/23969162/


Per ubfan1's suggestion (and apparent "fine print" at https://help.ubuntu.com/community/DiskSpace#BIOS-Boot_or_EFI_partition_.28required_on_GPT_disks.29), I have moved the bios_grub partition to the front of the disk. However, it still doesn't boot.

http://paste.ubuntu.com/23990368/

Per ubfan1's suggestion (and https://help.ubuntu.com/community/DiskSpace#Separate_.2Fboot_.28sometimes_required.29), I created a separate boot partition. I then reinstalled Ubuntu but it still will not boot.

http://paste.ubuntu.com/23990755/

I have used Boot-Repair to purge and reinstall Grub but it still won't boot.

http://paste.ubuntu.com/23990829/


Per oldfred's comment, I have tried to add the "boot" flag to a partition. I have done so in the following configurations without success.

+---------------+-----------+-------------+-------------+-----------------------+
| configuration | partition | mount point | file system |         flags         |
+---------------+-----------+-------------+-------------+-----------------------+
|               |     1     |             |  biosgrub   | bios_grub legacy_boot |
|               +-----------+-------------+-------------+-----------------------+
|               |     2     |    /boot    |    ext4     |                       |
|       1       +-----------+-------------+-------------+-----------------------+
|               |     3     |             |    swap     |                       |
|               +-----------+-------------+-------------+-----------------------+
|               |     4     |      /      |    ext4     |                       |
+---------------+-----------+-------------+-------------+-----------------------+
|               |     1     |             |  biosgrub   |         boot          |
|               +-----------+-------------+-------------+-----------------------+
|               |     2     |    /boot    |    ext4     |                       |
|       2       +-----------+-------------+-------------+-----------------------+
|               |     3     |             |    swap     |                       |
|               +-----------+-------------+-------------+-----------------------+
|               |     4     |      /      |    ext4     |                       |
+---------------+-----------+-------------+-------------+-----------------------+
|               |     1     |             |  biosgrub   |       bios_grub       |
|               +-----------+-------------+-------------+-----------------------+
|               |     2     |             |    ext4     |      legacy_boot      |
|               +-----------+-------------+-------------+-----------------------+
|       3       |     3     |    /boot    |    ext4     |                       |
|               +-----------+-------------+-------------+-----------------------+
|               |     4     |             |    swap     |                       |
|               +-----------+-------------+-------------+-----------------------+
|               |     5     |      /      |    ext4     |                       |
+---------------+-----------+-------------+-------------+-----------------------+
|               |     1     |             |  biosgrub   |       bios_grub       |
|               +-----------+-------------+-------------+-----------------------+
|               |     2     |             |    ext4     |         boot          |
|               +-----------+-------------+-------------+-----------------------+
|       4       |     3     |    /boot    |    ext4     |                       |
|               +-----------+-------------+-------------+-----------------------+
|               |     4     |             |    swap     |                       |
|               +-----------+-------------+-------------+-----------------------+
|               |     5     |      /      |    ext4     |                       |
+---------------+-----------+-------------+-------------+-----------------------+
|               |     1     |             |  biosgrub   |       bios_grub       |
|               +-----------+-------------+-------------+-----------------------+
|               |     2     |             |    ntfs     |         boot          |
|               +-----------+-------------+-------------+-----------------------+
|       5       |     3     |    /boot    |    ext4     |                       |
|               +-----------+-------------+-------------+-----------------------+
|               |     4     |             |    swap     |                       |
|               +-----------+-------------+-------------+-----------------------+
|               |     5     |      /      |    ext4     |                       |
+---------------+-----------+-------------+-------------+-----------------------+
|               |     1     |             |  biosgrub   |       bios_grub       |
|               +-----------+-------------+-------------+-----------------------+
|               |     2     |             |    ntfs     |   boot legacy_boot    |
|               +-----------+-------------+-------------+-----------------------+
|       6       |     3     |    /boot    |    ext4     |                       |
|               +-----------+-------------+-------------+-----------------------+
|               |     4     |             |    swap     |                       |
|               +-----------+-------------+-------------+-----------------------+
|               |     5     |      /      |    ext4     |                       |
+---------------+-----------+-------------+-------------+-----------------------+
|               |     1     |             |  biosgrub   |       bios_grub       |
|               +-----------+-------------+-------------+-----------------------+
|               |     2     |             |    fat32    |   boot legacy_boot    |
|               +-----------+-------------+-------------+-----------------------+
|       7       |     3     |    /boot    |    ext4     |                       |
|               +-----------+-------------+-------------+-----------------------+
|               |     4     |             |    swap     |                       |
|               +-----------+-------------+-------------+-----------------------+
|               |     5     |      /      |    ext4     |                       |
+---------------+-----------+-------------+-------------+-----------------------+

Someone (not on here) suggested wiping the entire drive. I did so using "sudo dd if=/dev/zero of=/dev/sdb". I then set the drive to use GPT. I tried installing Ubuntu and I am having the same issue as the previous attempt.

http://paste.ubuntu.com/24009927/

  • What OS is already installed (in the main drive)? If Windows then most likely in UEFI mode. If Ubuntu was correctly installed in the same mode you always be booting from the first drive, the one that contains the ESP (EFI System Partition). –  Feb 03 '17 at 03:26
  • Windows 7 Enterprise is installed on the main drive. As I stated above, we aren't supposed to mess with that because of the University's standardized IT procedures. We have dual booted from the secondary drive on several other computers without incident.

    I wasn't being extremely methodic, but one of my attempts did include using the LiveCD in UEFI mode. However, in the past, we have used "legacy boot". Typically, after installing Ubuntu, we just change the boot order in the BIOS settings.

    – Andrew Shum Feb 03 '17 at 16:21
  • It sounds like your primary hard disk is locked down by IT, and won't let you write the GRUB bootloader to it. I don't remember if you can specify where the GRUB bootloader is installed during Ubuntu install, but if you can, you should probably say /dev/sdb (the 4TB drive). Then you can BIOS boot to the 4TB. All things said... IT might have a problem with what you're trying to do anyway. – heynnema Feb 03 '17 at 16:33
  • 3
    Your 4TB drive must be gpt partitioned. That normally is for UEFI, but with Ubuntu you can install in BIOS boot mode with a bios_grub partition. I add both the ESP - efi system partition for UEFI boot even if not now needing it as inserting it at beginning of drive is difficult once drive has lots of data. If Windows is in BIOS boot mode you must install Ubuntu in BIOS boot mode as you do not have an ESP on sda (Windows drive). So UEFI grub will not install. http://askubuntu.com/questions/743095/how-to-prepare-a-disk-on-an-efi-based-pc-for-ubuntu & https://help.ubuntu.com/community/DiskSpace – oldfred Feb 03 '17 at 17:08
  • Could you please run Boot-Info and [edit] your question to include a link to its resulting info log? Thanks. – David Foerster Feb 03 '17 at 17:35
  • Here is the report from Boot-Info: http://paste.ubuntu.com/23920806/

    A few comments about the situation. I have since removed the 4TB drive from the new computer and tried using it through USB to boot one of the older computers that already has a working version of Ubuntu. That didn't work so I reformatted the drive and tried installing Ubuntu again (through USB). In the linked report, sda is the primary drive of the old computer, sdb is the secondary drive of the old computer (where the working Ubuntu is), and sdc is the 4TB drive in question.

    – Andrew Shum Feb 03 '17 at 21:53
  • heynnema - That is exactly what we typically do and it isn't working in this case.

    oldfred - It is usually formatted as NTFS in Windows which, I beleive requires you to use GPT. Then, when we install ubuntu, we shrink the NTFS to make room for the ext4 and the swap for ubuntu.

    – Andrew Shum Feb 03 '17 at 22:05
  • Looking at the report, it seems that the issue might be where I placed Grub. Here is another shot. I'll tell you if it worked. http://paste.ubuntu.com/23921965/ – Andrew Shum Feb 04 '17 at 01:17
  • So, that still didn't work. I tried using a working Ubuntu to find the supposed missing file, core.img. On both the working and non-working Ubuntu drives, I found the file in directory /boot/grub/i386-pc. The one on the non-working Ubuntu is 59 bytes smaller than the other. However, I am going to guess the reason is the difference in versions (14.04.5 versus 14.04.3). – Andrew Shum Feb 04 '17 at 01:46
  • @DavidFoerster So, it looks like someone else had a similar problem here (http://askubuntu.com/questions/785752/boot-repair-core-img-can-not-be-found). Do you know if they every got their issue resolved? – Andrew Shum Feb 07 '17 at 02:12
  • Could you please [edit] your post, when you want to add information? It’s best to have everything relevant in one place. Additionally, comments may be deleted for various reasons. Thanks. – David Foerster Feb 07 '17 at 22:37
  • 1
    Just use gparted to add the bios_grub partition. It can be anywhere on drive, must be unformatted, only needs to be 1 or 2MB and must have bios_grub flag for grub to be able to install to protective MBR on gpt partitioned drives. Do not install grub to a partition like you have shown as BIOS only boots from MBR. If you add bios_grub and do a full uninstall/reinstall of grub in BIOS mode, your system will boot from sdc.https://help.ubuntu.com/community/DiskSpace – oldfred Feb 07 '17 at 23:28
  • @oldfred How is this different than the designated MBR of the drive? According to the boot info, Grub is in the MBR of the drive. Also, for the latter attempt with the 4TB drive and the new attempt with the 2TB, I told the installation program to install Grub on sdc and sdb respectively. These are different options from something like sdc3 which is what I tried to do for the attempt associated with the first boot info. Are you saying that selecting the sdb option still installs in on a particular partition? – Andrew Shum Feb 08 '17 at 19:37
  • 1
    You always select a drive to install grub into. But with MBR grub is in MBR, but core.img is in the sectors just after the MBR. But with gpt partitioning the gpt has no sectors after the MBR available. So for grub to install its core.img, it must have the bios_grub. Otherwise grub does not correctly install with BIOS boot on gpt partitioned drive. You can always install grub to another MBR on a MBR(msdos) partitioned drive as MBR partitioning has the space, but then both drives have to be present to boot. Why do you not want the bios_grub partition? It is only 1 or 2MB. – oldfred Feb 08 '17 at 20:49
  • @oldfred It isn't a case of not wanting it. It is a case of wondering why it is needed. I am more of a novice than an expert when it comes to dealing with Ubuntu and bootloading so I don't understand all the steps and what they require. Because the installation instructions for Ubuntu do not mention GPT versus MBR, I didn't realize it made a difference. The only thing I knew about GPT versus MBR up till now is that GPT is newer and needed for drives larger than 2TB. I'll give your solution a try. – Andrew Shum Feb 09 '17 at 00:05
  • @oldfred Okay, even though the instructions for installing Ubuntu (https://help.ubuntu.com/community/Installation) do not mention the bios_grub partition, apparently the separate instructions for installing Grub (https://help.ubuntu.com/community/Grub2/Installing) do. However, even then, it is a rather small paragraph in the middle of an otherwise long page. If you would compose and post an answer, I would be happy to mark it as the answer. – Andrew Shum Feb 09 '17 at 00:22
  • @oldfred So, I tried what you suggested on the 4TB drive. The old problem seems to have re-emerged. I will provide the info in the original post. – Andrew Shum Feb 09 '17 at 02:20
  • 1
    The gpt protective MBR says core.img not found at location. It should be at first sector of bios_grub or 6,790,035,456. Run the suggested fix by Boot-Repair. It also says Secure boot may be on. Make sure it is off as BIOS/CSM is not Secure Boot. – oldfred Feb 09 '17 at 05:12
  • @oldfred So, if I am understanding you correctly, I want to tell the installation program to install Grub on sdb2 not sdb? There doesn't appear to be a way for me to move core.img because it is always automatically placed on the Ubuntu root partition. As for boot repair, is there a way to select which change to make. I tried it in response to one of the previous comments and it ended up installing Grub on all 3 drives; overwriting my windows bootloader in the process. I will go check the Secure Boot setting. However, if it is enabled, wouldn't I have issues booting the primary drive as well? – Andrew Shum Feb 09 '17 at 19:58
  • @oldfred I have added the images. – Andrew Shum Feb 09 '17 at 20:24
  • You almost never install grub to a partition. You install grub to sdb, and grub just uses the bios_grub partition to store extra data in core.img. It must be with your system Boot-Repair could not tell if UEFI Secure Boot was on or not. Leave that off. – oldfred Feb 09 '17 at 22:07
  • @oldfred So is there anything else I can do (within the previously mentioned limits) to try to get Grub to work? – Andrew Shum Feb 09 '17 at 23:08
  • Did you use Boot-Repair's advanced mode and fully uninstall/reinstall grub-pc for BIOS boot after creating the bios_grub partition? – oldfred Feb 09 '17 at 23:35
  • @oldfred I did not use Boot-Repair but I did purge and reinstall Grub as per the instructions here (https://help.ubuntu.com/community/Grub2/Installing#via_Terminal_Commands). – Andrew Shum Feb 10 '17 at 19:35
  • Was that a full chroot into system? Boot-Repair makes sure partitions are correctly mounted. Post new summary report from Boot-Repair. – oldfred Feb 10 '17 at 20:31
  • @oldfred Yes, when I purged and reinstalled Grub from the terminal, I followed steps 1-9 from the previous section to get root permissions. The result from that attempt is the previous report (http://paste.ubuntu.com/23958163/). Just to try everything, I just used Boot-Repair to reinstall (but not purge) Grub. I have added those results to the OP but am also placing them here (http://paste.ubuntu.com/23969162/). – Andrew Shum Feb 10 '17 at 21:12
  • Take a look at http://www.rodsbooks.com/gdisk/bios.html . Can you move the 4T disk onto another computer, or put it into a USB enclosure rated for 4T to see if it works? – ubfan1 Feb 14 '17 at 02:14
  • @ubfan1 Yes, I suppose I could try it on another computer. I haven't done that since adding the bios_grub partition. With regards to the link you provided: steps 3, 4, and 10 have already been done; 8 and 9 are not applicable; 1, 5, and 6 I am starting to get confused about the terminology; 2, 7, and 11 I am a bit nervous about trying because I don't see a means of restoring the previous state if the new state ends up being worse. I am running out of characters here so I'll post a 2nd comment. – Andrew Shum Feb 14 '17 at 19:53
  • Step 2, I don't understand how the values would be different if the physical location of the data doesn't actually change. Step 7, first, what is a non-boot disk? Second, he mentions blanking out the boot loader. Is this something that can be undone if it doesn't help. Also, I thought Grub was the boot loader. How would this be different from simply removing Grub? With regards to 1, 5, and 6, he talks about partitions in the MBR. On his page about hybrid MBRs, he mentions a usual single partition can be as large as 2TB. Are these separate from what you see in GParted/Window's Disk Management? – Andrew Shum Feb 14 '17 at 20:05
  • Please continue this discussion in chat. There's a link above. – wizzwizz4 Feb 14 '17 at 20:23

2 Answers2

2

According to oldfred from his post post above, the 4 tb hard drive must be GPT partitioned. This is actually incorrect. If the OP partitions the 4 tb hard drive as two 2 terabyte hard drives, then he can access them as MBR partition. https://superuser.com/questions/368173/what-is-the-maximum-number-of-partitions-that-can-be-made-on-a-hard-drive

Also, read this https://superuser.com/questions/562331/mbr-partition-with-more-than-2-tb

  • 1
    A few drive mfg have non-standard MBR configurations to try to use MBR with drives over 2TiB. Only use gpt if drive is over 2TiB if you want to follow normal standards and avoid issues. MBR details including 2TiB limit and GPT link http://en.wikipedia.org/wiki/Master_boot_record and: http://askubuntu.com/questions/629470/gpt-vs-mbr-why-not-mbr I now only use gpt for all drives whether system is BIOS or UEFI. – oldfred Feb 03 '17 at 20:07
1

Forgive me if I missed something in the discussion, but did you try putting the grub-bios partition first? I see it second, but still 3T into the disk. Try the below GPT partitioning:

  1. 2M grub-bios flag
  2. 500M future EFI partition (easier than trying to move partitions later.
  3. 500M /boot partition. So the kernels don't wind up 3T into the disk.
  4. The rest, ntfs, swap, and ext4 root.

    You can try the above, if it works, try without the /boot -- those usually cause trouble when full because you have too many old kernels, but they used to be necessary for BIOS limitations on addressing, which maybe we're seeing again with the big disks.

I use a legacy Win10 main disk, but have a GPT second disk, to which I did a legacy install, and later added UEFI boot capability by populating the ESP on the second disk. Things to check, that you can actually boot from the sdc disk.


A 1M size for the bios-grub would be sufficient, but then maybe the 2M suggestion is to keep alignment. Check your disk mfg recommendations. Consider the ESP planning for the future, or someone's (arbitrary) decision that UEFI is the way to go. Make it smaller if space is an issue, Ubuntu's bootloaders can fix in 6m, including a backup copy in /EFI/Boot. You don't have to set anything up, just allocate the partition, and leave it empty.

ubfan1
  • 17,838
  • Thanks for the suggestion. I'll give it a try when I get the chance and let you know how it goes. I probably won't set aside the EFI partition since I don't think we will ever need it. As stated in the original post, the Windows side is maintained by the University's IT department and they use legacy boot. From what I have heard from oldfred, trying to use both legacy boot and EFI would make things even more complicated. From other things I have read online, I'll probably shrink the bios_grub to 1MB. – Andrew Shum Feb 12 '17 at 23:19
  • Thanks for the update. The 2MB size for bios-grub was only a suggested upper limit by oldfred. I did that to ensure that there was enough space. From what I am seeing online, the common suggested size is 1MB. From previous experience with other hard drives (both this manufacturer and others), the 1MB alignment requirement implemented by most GUI partitioning programs is sufficient to keep the drive working without any issues. – Andrew Shum Feb 13 '17 at 19:55
  • there are a few BIOS that will not boot without boot flag. And with gpt the only partition that is supposed to have boot flag is the ESP. I normally with all gpt drives add both an ESP for UEFI boot and a bios_grub for BIOS boot as first two partitions. If not ever using UEFI, you can make a tiny FAT32 formatted partition with boot flag. If drive may later be used with UEFI, make an ESP that is 300 to 500MB. UEFI suggests it be first, but Windows often makes it second or third partition, but not far into drive. – oldfred Feb 13 '17 at 21:07
  • I have updated my OP with the results. I am afraid that Boot-Info appears to see nothing wrong but it still won't boot. – Andrew Shum Feb 13 '17 at 21:09
  • @oldfred We commented at about the same time so I only just saw your comment. I will try adding the boot flag. – Andrew Shum Feb 13 '17 at 21:18
  • @oldfred Did not work in any of the configurations I tried. I have listed them in the OP. – Andrew Shum Feb 14 '17 at 01:39