1 |
Hello all, |
2 |
|
3 |
I had posted a few weeks back requesting help with installing |
4 |
on a AS/2000 and had promised to get back with how it went |
5 |
|
6 |
this is how I did it, there are probably mistakes/ better ways |
7 |
of doing this, I would be interested in hearing any comments |
8 |
|
9 |
to recap, I could boot the system wiht 1.4 CD, but not with the |
10 |
2005.0 one. Since I was not sure if I could use a 2005.0 stage |
11 |
after booting with 1.4 kernel/glibc etc., I used stage 2 from |
12 |
1.4 to install the basic packages. the gentoo documentation |
13 |
was a great help here |
14 |
|
15 |
after getting a current portage snapshot and linking to 2005.0/2.4 |
16 |
profile, emerge (from 1.4) would fail with message |
17 |
>> update type "slot move" not recognized |
18 |
|
19 |
after much trial and error, linking to default-alpha-2004.0 |
20 |
allowed emerge to go forward but with a whole bunch of warnings/ |
21 |
errors. this allowed update to portage, python and I coudl link to |
22 |
2005.0/2.4 and emerge would go forward after manually putting |
23 |
in a world file (it helped to have a x86 gentoo system for |
24 |
reference to figure out file locations etc. here) |
25 |
|
26 |
initially I was using the CD to boot and then chrooting, and then |
27 |
I just copied over the kernel/initrd/modules from the 1.4 CD and |
28 |
used that as the entry in aboot.conf. compiling a current kernel |
29 |
was a challenge since each new try could go over 2 hours, before |
30 |
I eventually reduced the kernel config ot a minimum (this has only |
31 |
128M) and still get it to boot |
32 |
|
33 |
once that hurdle was over, updating the system was the next step. |
34 |
here the problem was that random segmentation faults would happen |
35 |
and the emerge would stop in between. eventually over many retries |
36 |
most of the system was updated and there was a binutils update |
37 |
and glibc update. trying to ugrade these actually led to more |
38 |
frequent errors. one approach that worked better here (for me) was |
39 |
to use "ebuild xyz.ebuild compile install qmerge" which updated the |
40 |
pkg with fewer faults (typically) |
41 |
|
42 |
one issue possibly was that I had -mcpu=ev45 in the CFLAGS since |
43 |
/proc/cpuinfo gave cpu as ev45. changing it to ev5 seemed to have |
44 |
improved the random failures |
45 |
|
46 |
repeating the process eventually got most of the pkgs compiled with |
47 |
the new binutils and am now trying to redo binutils/gcc/glibc |
48 |
to make sure that is stable. assuming that goes fine, next step |
49 |
would be to move to 2.6 kernel |
50 |
|
51 |
few points that I noted on the way |
52 |
|
53 |
gcc-3.3.2-r7 seem to ignore the -fortan USE flag and installs g77 |
54 |
anyway |
55 |
|
56 |
glibc update, when it went through fully and started to remove the |
57 |
build directory it caused filesystem issues and gave messages such |
58 |
as "journal aborted" etc and next reboot forced an fsck which needed |
59 |
manual intervention to clean up the system (ext3). I haven't tried |
60 |
with features="keepwork" to see if this can be avoided |
61 |
|
62 |
thanks for reading this far, all comments are appreciated |
63 |
|
64 |
best regards, Mathew |
65 |
|
66 |
|
67 |
-- |
68 |
gentoo-alpha@g.o mailing list |