On Wed, Jan 31, 2001 at 09:39:17PM +0900, OKUJI Yoshinori wrote:
> From: Thierry Laronde <[EMAIL PROTECTED]>
> Subject: Re: problems with savedefault
> Date: Wed, 31 Jan 2001 12:44:37 +0100
>
> > I had a quick look and the functions used by `install' (which work to write
> > sectors) and savedefault (which fails to write the modified sector of stage2
> > if this is not a floppy) are not the same. Perhaps something to look.
>
> Before tryig to guess what is wrong, describe what happened more
> precisely. All I know is that something wrong happened for Thierry
> and Torvald, and I still don't know what happened actually.
What was described by Torvald. If one sets :
default saved
and then have entries in "menu.lst" with the command "savedefault" if you
use it from a floppy the default is changed and the following reboot selects
the new default entry.
But if one uses it with (Torvald) 4th IDE or (Thierry) 1st SCSI this fails.
So I have not try to guess, I had a quick look. The procedure is the
following :
1) *entryno_ptr = current_entryno;
So (debug) : has current_entryno the good value ? Obviously yes
because this works with the floppy ;
2) write buffer to first sector place;
Does this work ? With floppy : yes ; with hard drive : no. So what
is the differences between the two ? The functions called by
rawwrite (boot_drive, install_second_sector, buffer) which calls
biosdisk, which is a "frontend" to specific devices functions.
Is grub able to write sectors ordinarily ? In at least one case, the
answer is yes : with the install command. So this succeeds with
install and fails with a function using the previous functions. So
the question : what is the differences between the use of these
functions in `savedefault' and `install' ?
I must say that the way used for tracing the problem _may_ seem logical.
But this is not guaranteed... It will be logical if finally we find the
problem here ;)
>
> > PS : in shared.h, the address for the saved_entryno is given as 0xc for an
> > int, but in asm.S, this entry is defined as a long. Thus, if I'm not
> > mistaken, this will work only with little endian machines and we could
> > perhaps add a remainder for possible futur ports to other architectures.
>
> That's wrong. That's not related to endian. What is undesirable here
> is that the code assumes sizeof(int) == sizeof(long).
But this is related to endian because the code writes an int at the
_beginning_ of an area used by a long, and because if one thinks he can have
the value of this int using the long, this works in little endian (low byte
first), and will fails with big endian ( value of long will be distinct from
value of int) --- the area is initialized to 0.
--
Thierry LARONDE, Centre de Ressources Informatiques, Archamps - France
http://www.cri74.org
PingOO, serveur de com sur distribution GNU/Linux: http://www.pingoo.org
_______________________________________________
Bug-grub mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-grub