Subject: Re: Undefined PLT symbol "__stat30" (symnum = 44)
To: Sarton O'Brien <bsd-xen@roguewrt.org>
From: Kenneth Freidank <kennethcf@earthlink.net>
List: current-users
Date: 10/02/2007 18:05:35
OK. 4.99.31 installed !!

I started over with my 4.99.19 system, clearing all intermediate builds, 
object files, and tartgets (aka /usr/destdir).
With a clean /usr/obj (nothing in it), and 4.99.31 source ready, I did 
the following.

1) $ ./build.sh -U tools            <- this got me my tools
2) $ ./build.sh -U release        <- this got me my release, but I forgot X
3) $ ./build.sh -U -u -x release       <- this added the x "gz" 
distribution files to my release, without re-doing everything
4) $ ./build.sh -U -u iso-image       <- this created an iso image from 
my work

I ftp'd the iso file to a windows box with a CD burner, and made a CD.  
Now I have a bootable 4.99.31 distribution CD that I used to upgrade all 
my machines.  Something to note as a learning experience was that after 
I upgraded my 4.99.19 system to 4.99.31, my builds were out of sync 
again.  So before I could tune my kernel, I erased the /usr/obj 
directory, and rebuilt tools.

1) $ ./build.sh -U tools          <- this got me my tools on my new 
4.99.31 system
2) $ ./build.sh -U kernel=MYKERNEL     <- this got me a customized (from 
GENERIC) kernel for my new 4.99.31 system

Thank you everyone for your help!

P.S.  I used my newly created 4.99.31 distribution CD to upgrade my 
eMachines T5048 without any customization of the installation kernel on 
my part.  If you search the mail archives on T5048, you will find a mess 
of notes on how the bootable distribution CD for 3.1, downloaded from 
the mirrors, refused to work with the T5048 without customizing the 
kernel.  I eventually got it to work (see the e-mails), but I did not 
have to customize the INSTALL or GENERIC kernels with 4.99.31.  This 
machine flies on compiles...at least in comparison to my other older 
machines.

Sarton O'Brien wrote:
> On Thu, 27 Sep 2007 04:35:50 pm Kenneth Freidank wrote:
>   
>> Thanks for all the insights and help.
>> 1)  I went to box B, and switched my kernel back to the factory
>> distribution 3.1, and rebuilt the tools for 3.1 from a 3.1 box.  Tools
>> built fine.
>> ./build.sh -U tools
>>     
>
> You should have stuck with the latest kernel you had, and built the tools 
> within that kernel. If you had of ./build.sh tools under the _new_ kernel, 
> all would be well.
>
>   
>> 2) From box B, I tried to install the distribution I had previously
>> built on box A 4.99.19.  So I'm running 3.1 on box B and
>> ./build.sh -O /usr/obj -D /usr/destdir -x -U install=/
>> (/usr/obj & /usr/desdir are NFS mounted to my 4.99.19 box A)
>>
>> The base installed on box B, then everything fell apart.
>>     
>
> Yep, you blew away all the 3.1 associated userland while it was in use, hence 
> the reason for building the tools under the new kernel and maintaining an 
> upgrade path.
>
> Admittedly none of it is perfect but you are doing a major upgrade. 
> Incremental upgrades aren't so pronounced.
>
>   
>> mkdir quit working, ls quit working, so I started over, reformatted and
>> reinstalled 3.1
>>     
>
> Why not go with 4 beta or rc? The problem you had is less likely to occur but 
> it is probably still best to understand what is actually going on.
>
>   
>>  From my native and freshly installed 3.1, with my /usr/src directory
>> NFS mounted, I am building 4.99.31.  This should work, but it is taking
>> me forever and a day.  I wish I had known more about the distribution
>> sets.  I thought the tools, once compiled in a 3.1 environment, would be
>> able to access and install the 4.99.31 userland built on my 4.99.19
>> system, but it didn't.  I'll try the tarball approach next time.  Seems
>> like an awful waste of time having to compile 4.99.31 on my old and slow
>> system running 3.1.
>>     
>
> It's not necessary to build the kernel on box B. Heck, you could download a 
> snapshot kernel if you want, so long as you boot using the kernel associated 
> with the intended userland.
>
> No matter what you do ... you will have to provide valid tools under box B.
>
> Easiest method would be:
>
> * boot using new kernel
> * cd /usr/src&&./build.sh tools&&./build.sh install=/
>
> But obviously doesn't apply to your custom structure.
>
> Funnily enough, you were almost there on the first email you sent and have 
> taken a few steps back.
>
> Good luck!
>
> Sarton
>
>