Re: problems with savedefault

[Thierry Laronde]

On Wed, Jan 31, 2001 at 09:39:17PM +0900, OKUJI Yoshinori wrote:
> From: Thierry Laronde <address@hidden>
> 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