[SOLVED] IBM Intellistation Question

[Just17]

As I don't know if this problem is hardware, firmware or software caused, it may need to be moved eventually, but first indications are hardware/firmware caused.

OK, an old dual processor IBM Intellistation with 4GB ram.
An expansion board to provide Sata sockets for drives, as it has none of its own.
One 80GB Sata drive connected. It has been wiped clean and the partition table rebuilt.
Three new partitions for PCLOS is all is there. First is the '/' partition.

Booted with PCLOS CD and installed without incident.

On rebooting, Grub fails to find its files on the HDD.
Different drives have been tried and the 80 GB has been tested in another machine.

So it appears to not be the HDD at fault.

The owner tried a couple of boot CDs without success, so I sent him a floppy image -----  yep! floppy! ---- and he hooked up a floppy drive to another PC and 'burned' the image, then swapped the drive to the IBM.

It booted fine from the floppy, and from there no problem to chainload the Grub on the HDD and boot the OS.

So, it appears that the HDD and its Grub install are OK.

BUT ....  Grub is being called by the BIOS because it is a Grub error that the user sees.
BTW ...  it is also Grub on the Floppy, where there is no problem.

All of that is a roundabout way of getting to the questions ....

Could there be something from the BIOS affecting the booting of the HDD directly? It seems to be the only logical conclusion

If so what might it possibly be?

My first thought was that it is the expansion card for SATA ....  but an IDE drive did not work when tried either. A real old 1.6GB IDE drive was tried ....  thinking the drive size might be causing some problem.

I don't have access to this machine, so have no detailed knowledge of the BIOS.

The owner has gone through the BIOS but not found any obvious HDD related settings that have not been tried.

Calling on bad memory, I believe I met with a similar problem a couple of years back and had to put LILO on it to get it booting. That is not a real alternative as I don't have access to this machine.

So, any thoughts why Grub might be failing to find its files when booted direct from BIOS?

If it is a BIOS setting problem, what might it be called?

If nothing comes to mind, what would be the best means of putting LILO onto the MBR from the running PCLOS that is installed on the HDD? (I will be looking at this myself as an option if it can be easily done)

What make ye of this?

Thanks for responses ..... 

[AS]

It booted fine from the floppy, and from there no problem to chainload the Grub on the HDD and boot the OS.

So, it appears that the HDD and its Grub install are OK.

BUT ....  Grub is being called by the BIOS because it is a Grub error that the user sees.
BTW ...  it is also Grub on the Floppy, where there is no problem.

That could sound perfectly fine if grub on HDD is installed on partition EBR instead of MBR.
Of course, I could be completely wrong! It's just an idea.

Like old-polack often says, "you are telling us a story ..."   

AS

[Just17]

It booted fine from the floppy, and from there no problem to chainload the Grub on the HDD and boot the OS.

the chainloader points to the HDD (MBR) and not to a partition ......  although if it did point to the partition boot sector then grub is installed there too.

The Grub installation is confirmed to be correct because it launches from being chainloaded from the Floppy.

Any other ideas?

[Hootiegibbon]

Just18,

I would look into seeing how IBM handle firmware support  for the added hardware, especially if its  afew years old.

Thinkpads used to only be able to handle certain "certified" hardware - wireless cards, hdd, etc as the bios (afaik)  has a inbuilt list of certifiable hardware by fru

Somthing similar may be at play with this machine.

Jase

[Just17]

Just18,

I would look into seeing how IBM handle firmware support  for the added hardware, especially if its  afew years old.

Thinkpads used to only be able to handle certain "certified" hardware - wireless cards, hdd, etc as the bios (afaik)  has a inbuilt list of certifiable hardware by fru

Somthing similar may be at play with this machine.

Jase

Thanks Jase .....  that might be a factor .....  definitely worth checking out.

[Just17]

Just18,

I would look into seeing how IBM handle firmware support  for the added hardware, especially if its  afew years old.

Thinkpads used to only be able to handle certain "certified" hardware - wireless cards, hdd, etc as the bios (afaik)  has a inbuilt list of certifiable hardware by fru

Somthing similar may be at play with this machine.

Jase

The SuperMicro card must be OK with the machine as the disk attached to the card is enumerated during POST. Changing the disk among the available SATA connectors causes a similar change in the enumerating during POST.

Also, it should be borne in mind that an IDE attached drive with Grub installed, which has been used for years to kick start old PCs, failed to boot either. That drive was only 1.6GB in size so I guess any concerns about LBA are not applicable.

I checked as much as I possibly could on both IBM and SuperMicro sites, but nothing jumped out at me.

So Grub will not load properly from any HDD tried.
It will load from a Floppy, and from there successfully boot the OS on the HDD using a chainloader command.

I think the next reasonable thing is to install LILO to the HDD and see if that works.

My reasoning behind that is as follows ......  if grub is using space on the first sector that is outside what the machine might regard as acceptable, then maybe there is some security function which prevents those few bytes from being accessed from BIOS.
I don't know how reasonable that view might be ....  but I am grasping at straws here 


So to LILO ...... has anyone installed LILO from PCLOS recently?  It has been nearly 7 years since I last installed it IIRC, and even then I hadn't a clue what was happening.
Apparently it needs   /etc/lilo.conf  to be present and populated.
So that the first problem .....  unless there is an automatic means of generating the file.


If anyone can help with this, I would appreciate it.
I will have to do it here and then try to explain to the user over a phone line what is needed.
    

Thanks for the help and if LILO fixes the booting problem we can all wonder why 

regards

[Just17]

Damn!

I can tell him to use the LILO installer through PCC!!!!!!!

Shoot I can be so ....  <fill in as required> ......  at times      

I will report back after that is tried.       

NOTE:  It is all Andy's fault anyway .....  he deleted his post with the lovely pic of the PCC bootmanager installer 

[Just17]

Trying now to figure out how to prevent the LILO install from putting UUIDs into the /etc/lilo.conf file 

Seems he will have to install LILO from the Konsole after editing the conf file .....

.....  more to come ....

                               SUCCESS!!!!!!!

After the failure to install LILO through PCC - Boot  we edited the produced /etc/lilo.conf file to change the root partition from a UUID to  /dev/sda1.
Next we installed LILO from the command line using

Code: [Select]

lilo -C /etc/lilo.conf  -b /dev/sda
The machine booted first time using LILO!

So .......  why?  .......  not that I care a damn at this stage, but it might be informative to know why this happened. 

Thank you all

regards.

[Just17]

With the euphoria of a successful boot behind us, it is now time to consider what has happened.

First is LILO.
You can attempt to install it through PCC but that will not work.
It does produce a config file, but because it populates that config file with UUIDs the install fails.
Even editing the entries while going through the LILO install procedure does not help, because although it shows the root device in the form of  /dev/sd?  it actually populates the config file with its UUID number 

So the solution used above was to go through the LILO install procedure, which produced an unusable config file, then edit that file replacing the UUIDs with /dev/sd?? notation.
Then install from the command line so the config file would not be written again by the install procedure.

This raises the question - from where does LILO get the info with which it populates the config? It apparently is picking up the UUIDs instead of the /dev/ notation which it requires.

In the end, LILO is still alive and well, and apparently has its uses, despite it being a bit of a pain to install.

***

The second aspect of all this is the question 'Why does Grub not work?'

I have no ideas presently other than the one I mentioned earlier ......  maybe Grub is writing some of its code outside the strict limit allowed by the BIOS, and is therefore not being read in full.
I did not think Grub wrote outside the strict limit of the MBR unless Stage1 was embedded .....  which it was not - it failed to do so.

Yet Grub was quite happy to boot once it was not called by the BIOS in this machine ....

So if anyone has any ideas what may have caused this situation, let's hear them.

Maybe there is a simple explanation I have not thought of .....