On 2012-01-22 07:56, please try again wrote:
>
> The question is “How does Yast use GRUB?” not “What does Grub use when
> loading?”
Right.
> However we can try to answer both questions (starting with the easier
> one).
Ok.
> What_does_Grub_when_loading?_
>
> - if installed in MBR, it loads stage1.5 and looks for stage2 in the
> filesystem (safer, you can move stage2 in the filesystem)
> - if installed in partition, it looks for stage2 at the address block
> specified in stage1. (If you move stage2, you have to reinstall Grub)
Ok.
> - it doesn’t query the BIOS. I’m not aware of Linux BIOS interrupts.
Here we differ. Linux doesn’t use BIOS interrupts, but all bootloaders,
including GRUB, do so, because Linux is not available yet. They can redo
all the code needed to read from all types of devices (hd, cd, fd, usb,
etc…), or they simply use the available bios services. And this is what
they do, this is the reason they have to use bios disk ordering. It would
not make sense otherwise. Grub is going to use the Bios service that loads
sectors from device 80, as you said. Why 80? I don’t remember, that’s long
ago. I have the vague recollection that lower numbers are floppies.
(80 hex is 10000000, so you can consider it as zero with one bit flipped,
easy to detect as if it were a flag. Or as a negative short integer)
The fact is mentioned somewhere in the docs, don’t ask me where because I
don’t remember. The difference between having to use bios and later what
Linux says is the origin of the problem the users have choosing a disk to
boot from. What we think is not always what the computer “thinks”.
Ah, here:
> http://www.gnu.org/software/grub/manual/legacy/Low_002dlevel-disk-I_002fO.html#Low_002dlevel-disk-I_002fO
+++····················
D.8 INT 13H disk I/O interrupts
FIXME: I’m not sure where some part of the original chapter is derived, so
I will rewrite this chapter.
····················+±
It only says that, but it is enough to know that they use INT 13h from the
bios 
There is another chapter mentioning int 13, but it is also empty (I/O ports
detection: How to probe I/O ports used by INT 13H )
> And if you change the BIOS order, it won’t boot.
> - it doesn’t read the device.map. You can delete this file or write
> nonsense in it. It will still boot.
Right. I know.
The other day I made an usb stick to boot with cdrescue and grub, with
ext4. When I plug an stick and tell the bios to boot from it, this stick
becomes the first device, and the menu file refers to is as hd0. At least
it is so on two HP computers I tried.
> - it displays the menu if there is one. But the menu itself is not
> required. Without the menu, you get a Grub shell, where you can do
> what you want … (don’t you?)
Nope
I need a cheat sheet to be able to do it
> How_does_Yast_use_Grub?
This I haven’t studied, I only know the symptoms, and how to get Yast to do
what I want.
>> This function changes order of devices in device_mapping. All devices
There is a dialog that changes the order of devices in the map.
> - you don’t have device.map: you see kernel devices (/dev/sda,
> /dev/sdb). mapped to BIOS drives starting at 0 (more exactly at 0x80)
> in the order they appear to the kernel.
> This is bad, as we all know - well not all, unfortunately.
> - you have an incomplete device.map: you see only the drives defined
> in device.map. It would be the long names of the physical disks
> normally, but you could also put kernel device names (but don’t!)
> - you have an accurate device.map . It’s fine
> - you have a device.map containing invalid entries (like some
> sentences I won’t say here): you get kernel devices
> - you have a device.map containing obsolete entries: you get hard
> disks that don’t exist (anymore).
Interesting list.
> Now it’s not done, because yast will pass the disks as paramaters to
> the perl Bootloader, which will rewrite the menu (and remove the
> comments added by updategrub, but I know that you don’t care about
> that).
No, I don’t care is not correct. Not what I said or meant.
> Now device.map is not just an info file for us to read.
> It is read by YaST, passed to perl Bootloader and ends up in your
> menu.lst sooner or later, like after a kernel update.
In a manner of speaking. I meant that changing it does not change booting.
> But I don’t thing the problem here is related to device map. You have
> to find out what’s wrong in menu.lst and fix it.
As always
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)