Cannot boot from HDD (System Halted)

[sigi]

TeraByte Support(TP) wrote:


> I take it that you currently have 3 operating systems installed (1 Windows, 2 Linux),
> and 2 of the 3 are currently booting Ok from the BING boot menu? And the third one
> (Linux Mint 17) is not booting when you try to boot it from the BING boot menu?

That is correct. WinXP had been installed as the only OS. Then I additionally installed LM17, Linux Swap and LM12 following your (Tom Pfeifer’s) Generalized Disk Layout. Now WinXP and LM12 boot OK from HDD wheras LM17 is not bootable.

> If so, what happens when you try to boot LM17 from the BING boot menu? Any error
> messages?

When Rebooting out of the BING CD Maintenance Mode, the BING boot menu does not appear. It gets as far as "Bootit EMBRI 2.01 - Bootit EMBRL 2.04 - Read error loading EMBRM! System Halted!"

> For the LM17 partition, if you look at Partition Work - Properties for that
> partition, what does it say for "Bootable" status in the Additional
> Information section? (Bootable: Yes or Bootable: No).

At the moment I cannot access my son's computer. So I have to make use of my notes and they refer only to the message that I get when trying to boot the LM17 boot item. It reads: "The partition is not bootable! If you are in the process of installing an OS then insert the installation media and press ctrl-alt-del to initiate a reboot otherwise click OK to return to BootIt NG." However, I can see all LM17 data when working under LM12.

>
> The "HS" stands for head and sectors - please see page 30 of the BING
> manual.

Do I have to check "Align MBR Ending HS" and "Align MBR HS when Truncated" IN ADDITION to "Align on 1 Mib Boundaries" or are they alternative options?

[TeraByte Support(TP)]

sigi wrote:
> TeraByte Support(TP) wrote:
>
>
> > I take it that you currently have 3 operating systems installed (1 Windows, 2
> Linux),
> > and 2 of the 3 are currently booting Ok from the BING boot menu? And the third
> one
> > (Linux Mint 17) is not booting when you try to boot it from the BING boot menu?
>
> That is correct. WinXP had been installed as the only OS. Then I additionally
> installed LM17, Linux Swap and LM12 following your (Tom Pfeifer’s) Generalized Disk
> Layout. Now WinXP and LM12 boot OK from HDD wheras LM17 is not bootable.
>
> > If so, what happens when you try to boot LM17 from the BING boot menu? Any error
> > messages?
>
> When Rebooting out of the BING CD Maintenance Mode, the BING boot menu does not
> appear. It gets as far as "Bootit EMBRI 2.01 - Bootit EMBRL 2.04 - Read
> error loading EMBRM! System Halted!"

Do you have BING installed to the hard drive so that you can boot from the BING boot menu?

To put it another way, I guess I don't understand why you are booting from the BING CD instead of just booting up from the hard drive into BING, and then booting 1 of the 3 OSes from the BING boot menu. I can't really suggest anything else until I understand how you are using that system.

[TeraByte Support(TP)]

sigi wrote:

> > For the LM17 partition, if you look at Partition Work - Properties for that
> > partition, what does it say for "Bootable" status in the Additional
> > Information section? (Bootable: Yes or Bootable: No).
>
> At the moment I cannot access my son's computer. So I have to make use of my notes
> and they refer only to the message that I get when trying to boot the LM17 boot item.
> It reads: "The partition is not bootable! If you are in the process of
> installing an OS then insert the installation media and press ctrl-alt-del to
> initiate a reboot otherwise click OK to return to BootIt NG."


I overlooked this part of your response in my previous post....

If you are getting the "partition not bootable" message when you try to boot LM17 from the BING boot menu, that means either:

1. You have incorrectly configured the BING boot item for LM17 in Boot Edit. Check the boot item configuration in Boot Edit and make sure that the LM17 partition is set as the boot partition (the partition to boot from). It could be trying to boot the wrong partition.

OR

2. The Grub boot loader was not installed to the LM17 partition during the Linux installation. You can verify this by looking at Partition Work - Properties for the LM17 partition, and note what it says for bootable status in the Additional Information section. It should say either "Bootable: Yes" or "Bootable: No". If it says "Bootable: No", that means Grub was not installed to the partition during the Linux install. In that case, this KB article provides a method to reinstall Grub2: http://www.terabyteunlimited.com/kb/article.php?id=408

The other option would be to reinstall LM17 and make sure that Grub gets installed to the LM17 partition. This KB article has a suggested install procedure for Linux Mint: http://www.terabyteunlimited.com/kb/article.php?id=281

[TeraByte Support]

Note: in the past I recall there were some linux distros or options that was
attempting to reinstall grub on startup each time...

[sigi]

TeraByte Support(TP) wrote:

snip

> If you are getting the "partition not bootable" message when you try to
> boot LM17 from the BING boot menu, that means either:
>
> 1. You have incorrectly configured the BING boot item for LM17 in Boot Edit. Check
> the boot item configuration in Boot Edit and make sure that the LM17 partition is set
> as the boot partition (the partition to boot from). It could be trying to boot the
> wrong partition.

In my opinion the boot item configuration in Boot Edit is correct for LM17. It has been built analoguous to that for LM12 (just replacing LM12 by LM17).

> OR
>
> 2. The Grub boot loader was not installed to the LM17 partition during the Linux
> installation. You can verify this by looking at Partition Work - Properties for the
> LM17 partition, and note what it says for bootable status in the Additional
> Information section. It should say either "Bootable: Yes" or
> "Bootable: No". If it says "Bootable: No", that means Grub was
> not installed to the partition during the Linux install. In that case, this KB
> article provides a method to reinstall Grub2:
> http://www.terabyteunlimited.com/kb/article.php?id=408

The Additional Information section reads: "Bootable: No. - The location of this partition will prevent some operating systems from booting from it." I am attaching a screenshot of "View MBR" in case you can derive useful information on the defective location of LM17 from it. Just to supplement that information I have inserted LM12 for the purposes of this screenshot.

snip

Attachments

P1020438 (View MBR - LM17 active).jpg (88.96 KiB) Viewed 9996 times

[TeraByte Support(TP)]

sigi wrote:
>
> The Additional Information section reads: "Bootable: No. - The location of
> this partition will prevent some operating systems from booting from it." I am
> attaching a screenshot of "View MBR" in case you can derive useful
> information on the defective location of LM17 from it. Just to supplement that
> information I have inserted LM12 for the purposes of this screenshot.

The screenshot looks correct as far as what the MBR should look like when booting the LM17 boot item, meaning the LM17 partition is set active.

If it says "Bootable: No" in Properties for the LM17 partition, that means there's no boot code installed (no Grub2 installed), so it's not going to boot until Grub2 does get installed to the boot sector of that partition. That would have to be done either by manually reinstalling Grub2 ( http://www.terabyteunlimited.com/kb/article.php?id=408 ), or by just reinstalling the LM17 OS.

If unfamiliar with working manually with Grub, reinstalling the OS is probably the easier option, assuming the installation is relatively new so that you're not losing too much data or configuration time, etc. ( http://www.terabyteunlimited.com/kb/article.php?id=281)

[sigi]

TeraByte Support(TP) wrote:

snip>
> If it says "Bootable: No" in Properties for the LM17 partition, that means
> there's no boot code installed (no Grub2 installed), so it's not going to boot until
> Grub2 does get installed to the boot sector of that partition. That would have to be
> done either by manually reinstalling Grub2 (
> http://www.terabyteunlimited.com/kb/article.php?id=408 ), or by just reinstalling the
> LM17 OS.
snip

Unfortunately I have been waiting too long with this answer, so I cannot remember exactly the various boot situations. Anyway, I will do my best to recapitulate the steps towards complete bootability.

LM17 was not bootable before - obviously due to missing boot code in the LM17 partition (although I am not aware how that could have happened). I followed your above link and installed Grub2 to the LM17 partition. When working through the items in Grub Article #4 I had to skip paras 4 and 5 for some reason I cannot remember. I succeeded albeit with some obscure warning, which ATTACHMENT 1 illustrates.

The translation of the German text reads as follows:

warning:
File system 'ext2' doesn't support embedding.
warning:
Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.

DO I HAVE TO CARE ABOUT THESE WARNINGS? WHAT IS THEIR MEANING?

The result was that LM17 did boot from HDD but for one time only. Thereafter the boot process from HDD ended with the following message "SP < Min" (I cannot remember the exact wording). Only the non-Linux partitions were concerned by this error. Applying the "Fill E-CHS" button to the faulty partitions restored the bootability from HDD again and again for one time only.

It was not before I changed the Drive Settings in BIBM that the bootability from HDD (all OS's including LM17) became permanent (cf. ATTACHMENT 2 - 1st screenshot = old settings, 2nd screenshot = new settings).

Attachments

Attachment 1 (Grub2 install).jpg (79.85 KiB) Viewed 9848 times

Attachment 2 (Drive Settings).jpg (225.34 KiB) Viewed 9853 times

[TeraByte Support(TP)]

sigi wrote:
> LM17 was not bootable before - obviously due to missing boot code in the LM17
> partition (although I am not aware how that could have happened). I followed your
> above link and installed Grub2 to the LM17 partition. When working through the items
> in Grub Article #4 I had to skip paras 4 and 5 for some reason I cannot remember. I
> succeeded albeit with some obscure warning, which ATTACHMENT 1 illustrates.
>
> The translation of the German text reads as follows:
>
> warning:
> File system 'ext2' doesn't support embedding.
> warning:
> Embedding is not possible. GRUB can only be installed in this setup by using
> blocklists. However, blocklists are UNRELIABLE and their use is discouraged.
>
> DO I HAVE TO CARE ABOUT THESE WARNINGS? WHAT IS THEIR MEANING?
>

That's a normal message when installing grub2 to a partition (as opposed to the MBR). Grub2 won't allow installing to a partition unless you use the --force parameter in the 'grub-install' command line (as you did). This wiki page explains the warnings you see:
https://wiki.archlinux.org/index.php/GR ... nless_disk

Despite the warnings, most users don't have any problems from what I've seen. I use grub2 this way myself, including on my main Linux install of Debian, and have never seen any problems through many many updates. In any case, there's no choice if you want to use BIBM as boot manager (or any 3rd party boot manager). The boot manager needs to occupy the MBR, so grub can't be installed there.

> The result was that LM17 did boot from HDD but for one time only. Thereafter the boot
> process from HDD ended with the following message "SP < Min" (I cannot
> remember the exact wording). Only the non-Linux partitions were concerned by this
> error. Applying the "Fill E-CHS" button to the faulty partitions restored
> the bootability from HDD again and again for one time only.
>
> It was not before I changed the Drive Settings in BIBM that the bootability from HDD
> (all OS's including LM17) became permanent (cf. ATTACHMENT 2 - 1st screenshot = old
> settings, 2nd screenshot = new settings).

I don't know what the issue is/was with the drive settings, but hopefully it's settled now.

[sigi]

TeraByte Support(TP) wrote:

> This wiki page explains the warningsyou see:
> https://wiki.archlinux.org/index.php/GR ... nless_disk
>
> Despite the warnings, most users don't have any problems from what I've seen. I use
> grub2 this way myself, including on my main Linux install of Debian, and have never
> seen any problems through many many updates. In any case, there's no choice if you
> want to use BIBM as boot manager (or any 3rd party boot manager). The boot manager
> needs to occupy the MBR, so grub can't be installed there.

I do not have any problems either. Thank you for your valuable help so far. The material contained under your above link is for the most part beyond my understanding and therefore gives me some trouble. So please forgive me if I ask a silly question concerning the following quotation:
"The reason why grub-setup does not by default allow this is because in case of partition or a partitionless disk is that GRUB relies on embedded blocklists in the partition bootsector to locate the /boot/grub/i386-pc/core.img file and the prefix directory /boot/grub. The sector locations of core.img may change whenever the file system in the partition is being altered (files copied, deleted etc.)."
What is meant here with "files copied, deleted etc."? Isn't that something that could happen quite incidentally? What kind of files is here addressed?


> I don't know what the issue is/was with the drive settings, but hopefully it's
> settled now.

Yes, it is settled now. Thank you.

[TeraByte Support(TP)]

sigi wrote:

> I do not have any problems either. Thank you for your valuable help so far. The
> material contained under your above link is for the most part beyond my understanding
> and therefore gives me some trouble. So please forgive me if I ask a silly question
> concerning the following quotation:
> "The reason why grub-setup does not by default allow this is because in case of
> partition or a partitionless disk is that GRUB relies on embedded blocklists in the
> partition bootsector to locate the /boot/grub/i386-pc/core.img file and the prefix
> directory /boot/grub. The sector locations of core.img may change whenever the file
> system in the partition is being altered (files copied, deleted etc.)."
> What is meant here with "files copied, deleted etc."? Isn't that something
> that could happen quite incidentally? What kind of files is here addressed?

Apparently it can under some conditions. All I can say is that I've never seen it happen while just running a Linux OS normally, including copying or deleting files, OS updates, etc. Of course if you delete and overwrite the file /boot/grub/core.img mentioned above, you will have a problem. Normally, there's never any reason for a user to do anything with that file.

That file (core.img) contains the core of Grub, including the code that can read file systems. When Grub is installed in a partition boot sector (512 bytes), there's no room there for the file system code. So it can't read file systems until it finds core.img, which it has to find based on its physical location on the disk, which is stored in block lists in the boot sector. On the other hand, if Grub is installed in the MBR/first track, it has room to fit the file system code there, and this isn't an issue.