[9fans] Kernel Compiling Problem

[9fans] Kernel Compiling Problem

[Rodolfo kix Garci­a]

Hi,

The last week I downloaded the plan9.iso.bz file from the sources. Then
I installed it in a vmware machine, perfect.

Then, I pulled and I tryed to compile the pccpuf kernel (with glenda). I
got a problem.

First time:

term% mk 'CONF=pccpuf'
8a $AFLAGS l.s
mk: don't know how to make '/386/bin/fossil/fossil' in directory
/sys/src/9/pc
term%

Second time:

term% mk 'CONF=pccpuf'
8a $AFLAGS plan9l.s
mk: don't know how to make '/386/bin/fossil/fossil' in directory
/sys/src/9/pc
term%

Third time:

term% mk 'CONF=pccpuf'
8c -FVw cga.c
mk: don't know how to make '/386/bin/fossil/fossil' in directory
/sys/src/9/pc
term%

Every time, the same error but with "the next" file to compile.

Yesterday, I tryed it with a new plan9.iso CD (the latest) and qemu. I
got the same problem.

I leave the qemu's image at http://www.kix.es/files/plan9/P9-try.rar
(with the windows binaries and the linux launcher)

Anybody can check the qemu's image or try to do a new installation with
the plan9.iso?

Thanks

kix

Re: [9fans] Kernel Compiling Problem

[a]

I'm assuming /386/bin/fossil/fossil does not, in fact, exist.

The fact that the last file completed changes is just a distraction
in this case; I suspect you have $NPROC>1 and mk is parallelizing
its work. I think if you set NPROC=1 before running mk you'll stop
seeing that last file change.

The problem is simply that the kernel mkfiles don't know how to
build things in /sys/src/cmd. The trivial work-around is to build
fossil yourself (cd /sys/src/cmd/fossil && mk install). There's
likely to be other similar binaries needed, so I'd recommend you
'mk install' all of /sys/src/cmd.
Anthony

Re: [9fans] Kernel Compiling Problem

[Rodolfo kix García]

> I'm assuming /386/bin/fossil/fossil does not, in fact, exist.


The file exists:

term% ls -l /386/bin/fossil/fossil
--rwxrwxr-x M 8 sys sys 366315 Dec 31  1969 /386/bin/fossil/fossil
term%

> The fact that the last file completed changes is just a distraction
> in this case; I suspect you have $NPROC>1 and mk is parallelizing
> its work. I think if you set NPROC=1 before running mk you'll stop
> seeing that last file change.

I am getting the same problem with or without setting NPROC=1

> The problem is simply that the kernel mkfiles don't know how to
> build things in /sys/src/cmd. The trivial work-around is to build
> fossil yourself (cd /sys/src/cmd/fossil && mk install). There's
> likely to be other similar binaries needed, so I'd recommend you
> 'mk install' all of /sys/src/cmd.

Yes!? Here is the problem:

If I compiled fossil and now, doing the mk with pccpuf, show me an error
with libip.a :-?
Then, I compiled libip.a and now the kernel is compiling ok.

The real problem is this is the official plan9.iso CD, with the default
installation, then other people will have the same problem.

> Anthony

Thank you Anthony,

>
>


-- 
Rodolfo García AKA kix
http://www.kix.es/
EA4ERH (@IN80ER)

Re: [9fans] Kernel Compiling Problem

[Richard Miller]

> term% ls -l /386/bin/fossil/fossil
> --rwxrwxr-x M 8 sys sys 366315 Dec 31  1969 /386/bin/fossil/fossil

December 1969?  I think not.

What does the date command on your system say?

What is the date on this file on your installation ISO image?

Re: [9fans] Kernel Compiling Problem

[Rodolfo kix García]

Hi,

yes, December 1969 is the date of this file. The file _fossil has the same
time.

In the plan9.iso the date for /386/bin/fossil/fossil is Feb 29 2008.

The size is equal in the plan9 installation and the plan9.iso, 336315 bytes


>> term% ls -l /386/bin/fossil/fossil
>> --rwxrwxr-x M 8 sys sys 366315 Dec 31  1969 /386/bin/fossil/fossil
>
> December 1969?  I think not.
>
> What does the date command on your system say?
>
> What is the date on this file on your installation ISO image?
>
>
>


-- 
Rodolfo García AKA kix
http://www.kix.es/
EA4ERH (@IN80ER)

Re: [9fans] Kernel Compiling Problem

[Richard Miller]

> yes, December 1969 is the date of this file. The file _fossil has the same
> time.

It seems that replica/applylog (which is used for both install
and pull) isn't setting the correct date on your files.

Please try the following commands:

  date
  ls -l /dist/replica/didplan9 /dist/replica/client
  cat /dist/replica/client/plan9.time
  grep 386/bin/fossil/fossil /dist/replica/client/plan9.db

Re: [9fans] Kernel Compiling Problem

[Rodolfo kix García]

Hi,

thanks for your reply

>> yes, December 1969 is the date of this file. The file _fossil has the
>> same
>> time.
>
> It seems that replica/applylog (which is used for both install
> and pull) isn't setting the correct date on your files.
>
> Please try the following commands:
>
>   date

Mon Mar 24 18:22:08 EST 2008 (now :-) )

>   ls -l /dist/replica/didplan9 /dist/replica/client

--rw-rw-r-- M 8 glenda sys 0 Mar 22 20:17 /dist/replica/didplan9

>   cat /dist/replica/client/plan9.time

1206163804  0

>   grep 386/bin/fossil/fossil /dist/replica/client/plan9.db

386/bin/fossil/fossil - 755 sys sys 0 366315
386/bin/fossil/fossil - 755 sys sys 0 366315
386/bin/fossil/fossil - 755 sys sys 0 366315

>
>
>


-- 
Rodolfo García AKA kix
http://www.kix.es/
EA4ERH (@IN80ER)

Re: [9fans] Kernel Compiling Problem

[Richard Miller]

>>   grep 386/bin/fossil/fossil /dist/replica/client/plan9.db
>
> 386/bin/fossil/fossil - 755 sys sys 0 366315
> 386/bin/fossil/fossil - 755 sys sys 0 366315
> 386/bin/fossil/fossil - 755 sys sys 0 366315

The '0' is what replica/applylog wrote as the file modification time -
clearly the wrong thing to do.  I don't understand this, because as
far as I can see the mtime should be taken from the actual mtime of
the file being copied from the CD (install) or sources (pull).

Re: [9fans] Kernel Compiling Problem

[Rodolfo kix Garci­a]

I don't run pull in this default installation, then the install CD do 
not write this value.

I got the same problem with two different CD images, three days ago and 
one week ago, installing them in vmware and qemu virtual machines.

Thanks Richard

Richard Miller escribió:
>>>   grep 386/bin/fossil/fossil /dist/replica/client/plan9.db
>>>       
>> 386/bin/fossil/fossil - 755 sys sys 0 366315
>> 386/bin/fossil/fossil - 755 sys sys 0 366315
>> 386/bin/fossil/fossil - 755 sys sys 0 366315
>>     
>
> The '0' is what replica/applylog wrote as the file modification time -
> clearly the wrong thing to do.  I don't understand this, because as
> far as I can see the mtime should be taken from the actual mtime of
> the file being copied from the CD (install) or sources (pull).
>
>
>   

Re: [9fans] Kernel Compiling Problem

[Richard Miller]

I said:

> I don't understand this, because as
> far as I can see the mtime should be taken from the actual mtime of
> the file being copied from the CD (install) ...

I've now traced the problem to a leap-year bug in the Plan 9 ISO9660
file server.

Several files in the distribution (including /386/bin/fossil/fossil)
were made on 29 February this year.  A logic error in 9660srv rejects
this as an impossible date, so it sets mtime for those files to zero.

Patch 9660srv-leapyear should fix the error.

Re: [9fans] Kernel Compiling Problem

[david]

On Mar 24, 6:42 pm, k...@kix.es (Rodolfo kix Garci­a) wrote:
> I don't run pull in this default installation, then the install CD do
> not write this value.
>
> I got the same problem with two different CD images, three days ago and
> one week ago, installing them in vmware and qemu virtual machines.
>
> Thanks Richard
>
> Richard Miller escribió:
>
> >>>   grep 386/bin/fossil/fossil /dist/replica/client/plan9.db
>
> >> 386/bin/fossil/fossil - 755 sys sys 0 366315
> >> 386/bin/fossil/fossil - 755 sys sys 0 366315
> >> 386/bin/fossil/fossil - 755 sys sys 0 366315
>
> > The '0' is what replica/applylog wrote as the file modification time -
> > clearly the wrong thing to do.  I don't understand this, because as
> > far as I can see the mtime should be taken from the actual mtime of
> > the file being copied from the CD (install) or sources (pull).

I experienced the same problem about two weeks ago and gave up,
thinking it was oddly related to the VMWARE installation. I used the
lated release of VMWARE workstation and everything seemed fine with
exception to building the kernel and the screen acting quirky (mouse
cursor, snarf acting inconsistent etc.) I plan to install on a PC this
weekend and slowly build a network of machines for research. Will
report my findings if relevant.  Thanks
david

Re: [9fans] Kernel Compiling Problem

[Richard Miller]

> I experienced the same problem about two weeks ago and gave up,

This has been fixed as of 28 March.

%   patch/list applied/9660srv-leapyear

Re: [9fans] Kernel Compiling Problem

[lupin636]

> > I experienced the same problem about two weeks ago and gave up,
>
> This has been fixed as of 28 March.
>
> %   patch/list applied/9660srv-leapyear

I have the same problem, but i haven't got an internet connection, so
i would like to know how you resolved it....if you did it....thanks

Armando

ps: i downloaded the iso file from the bell site last week.

Re: [9fans] Kernel Compiling Problem

[erik quanstrom]

>> > I experienced the same problem about two weeks ago and gave up,
>>
>> This has been fixed as of 28 March.
>>
>> %   patch/list applied/9660srv-leapyear
>
> I have the same problem, but i haven't got an internet connection, so
> i would like to know how you resolved it....if you did it....thanks
>
> Armando
>
> ps: i downloaded the iso file from the bell site last week.

then reinstall from that cd.

- erik

Re: [9fans] Kernel Compiling Problem

[john]

>> term% ls -l /386/bin/fossil/fossil
>> --rwxrwxr-x M 8 sys sys 366315 Dec 31  1969 /386/bin/fossil/fossil
>
> December 1969?  I think not.
>

Ah yes, the day before time began :)

Re: [9fans] Kernel Compiling Problem

[a]

As others have noted, the date on your fossil is suspect. It looks like
you've got other issues going on. Beyond, that, however, you say the
fossil exists, but then "If I compiled fossil and now...", with some
changed behavior. What happened here? You also skipped over the
question of what 'date' on your system returns.

// The real problem is this is the official plan9.iso CD, with the default
// installation, then other people will have the same problem.

True as far as it goes, but we don't know what the problem is yet. I
suspect the issue is simply that you're trying to build the kernels
without the prerequisites in place, which (if anything) would make
this mostly a documentation bug (although I don't offhand have a
good idea where to document this).

Anthony