| 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 |
Archives