# Smartest way to migrate a system from PII to VIA C3?[SOLVED]

## Stever

OK, I'm sure some of these questions will become obvious once I get the hardware in hand, but I'm trying to do as much as I can in advance to make a smooth transition.  This box is a pig when it comes to compiling, so I'm trying to get it right the first time.

I have a hardened gentoo router installation running OpenVPN, dnsmasq, shorewall, and not much else.  It has been running on a PII 300 for quite a while, but now I'm about to get my hands on a VIA C3 Samuel MB, which should be an upgrade performance wise (especially for OpenVPN).  I thought it would be quite painless to swap motherboards until I saw in the Safe CFLAGS wiki that this particular C3 needs i586 CHOST   :Sad: 

I've looked through both the official and wiki CHOST change guides, and it all looks like it is geared towards an upgrade rather than a downgrade, and they don't inspire much confidence that it will work in any case.

So my questions to anyone with experience in this area are:

1) Do I really need to change CHOST or would changing CFLAGS be sufficient?  Probably a silly idea, but one can hope  :Wink: 

2) Is it reasonably likely that  I can pull off a change of CHOST from i686 to i586?

3) Should I just throw in a new HD and start from scratch?  This would have the advantage of a quick recovery if I make a mess of things  :Smile: 

3a) If I start fresh, should I start with the x68 stage 3 tarball, or would that leave me right back where I started, needing to change CHOST?Last edited by Stever on Tue Nov 20, 2007 5:02 pm; edited 1 time in total

----------

## Keruskerfuerst

1. Actual CHOST variable?

2. Before you replace the mainboard, CPU you should recompile the whole system (CFLAGS, CHOST).

3. Changing the CFLAGS and CHOST may result in a broken system.

3a. stage3 x86: yes; you should check the preset make.conf.Last edited by Keruskerfuerst on Thu Nov 15, 2007 9:39 am; edited 1 time in total

----------

## desultory

 *Stever wrote:*   

> 1) Do I really need to change CHOST or would changing CFLAGS be sufficient?  Probably a silly idea, but one can hope 

 Changing CFLAGS would be insufficient, CHOST must be changed in this case, due to the new processor lacking certain features used by gcc with CHOST="i686-pc-linux-gnu".

 *Stever wrote:*   

> 2) Is it reasonably likely that  I can pull off a change of CHOST from i686 to i586?

 Theoretically, it should work.

 *Stever wrote:*   

> 3) Should I just throw in a new HD and start from scratch?  This would have the advantage of a quick recovery if I make a mess of things 

 It would also be simpler to implement. 

 *Stever wrote:*   

> 3a) If I start fresh, should I start with the x68 stage 3 tarball, or would that leave me right back where I started, needing to change CHOST?

 The x86 stage 3 tarballs use CHOST="i486-pc-linux-gnu", and CFLAGS="-O2 -mtune=i686 -pipe". So while changing the CHOST and CFLAGS settings would be beneficial, it would not be strictly necessary.

----------

## neysx

 *Stever wrote:*   

> I thought it would be quite painless to swap motherboards until I saw in the Safe CFLAGS wiki that this particular C3 needs i586 CHOST  

 C3 is i686.

Gentoo does not release suitable stage3 for that box, if you decide to perform a brand new install, you'd have to use either an unsupported stage1 or use the x86 stage3 that comes with i486.

Using your current box should be possible, but you'll probably need to recompile all packages with CFLAGS compatible with both PII and C3 unless you already have a compatible set of binaries. It depends on your current CFLAGS.

You do not have to downgrade your CHOST.

See

https://forums.gentoo.org/viewtopic-p-2879934.html#2879934

https://forums.gentoo.org/viewtopic-p-3439979.html#3439979

http://www.xs4all.nl/~neysx/cluster/

Hth

----------

## Stever

Wow, thanks for all the responses.  I think I have a better handle now on what to try:

1) Leave existing CHOST at i686 and rebuild existing system (kernel and all packages) with CFLAGS compatible with both PII and C3.  This only takes 5 minutes of MY time, seems to have minimal chance of breaking the existing system, and neysx has given me hope that it will work in the new.

2) Install new MB, if it works then buy neysx a virtual beer  :Smile: 

3) If not, it seems like a new install with x86 tarball is the way to go - then I can decide if it is worth the trouble of changing CHOST from 486 to 586 (my guess is probably not).

By the way, I like the C3 cluster - what do you use that for?

----------

## Stever

Hmmm, rebuilding the system (still on the PII) with CFLAGS="-O2 -march=pentium-mmx -pipe", but in a very bored moment I notice that the ebuild for glibc has decided it is smarter than me:

```
i686-pc-linux-gnu-gcc ../sysdeps/unix/sysv/linux/ftime.c -c -std=gnu99  -O2 ... -march=i686 -pipe ...
```

I have a feeling I may end up doing a new install...

----------

## neysx

 *Stever wrote:*   

> Hmmm, rebuilding the system (still on the PII) with CFLAGS="-O2 -march=pentium-mmx -pipe", but in a very bored moment I notice that the ebuild for glibc has decided it is smarter than me:
> 
> ```
> i686-pc-linux-gnu-gcc ../sysdeps/unix/sysv/linux/ftime.c -c -std=gnu99  -O2 ... -march=i686 -pipe ...
> ```
> ...

 Try with -mtune=pentium instead of -march

```
i686-pc-linux-gnu-gcc ../sysdeps/wordsize-32/divdi3.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -fno-strict-aliasing -mtune=pentium -pipe -Wstrict-prototypes -mpreferred-stack-boundary=4  -fPIC....
```

Hth

----------

## Stever

 *neysx wrote:*   

> Try with -mtune=pentium instead of -march

 

Thanks, that seems to have worked.  I wonder if I'll have the same problem if I change to -march=C3 once I install the new MB?

I guess I'll know soon enough, since it just came in the mail  :Smile: 

----------

## Stever

Well, finally got the new MB installed, but no luck.  With the old PII, I had changed to CFLAGS="-O2 -mtune=pentium -pipe", then did emerge -e system, followed by emerge -e world, followed by rebuilding kernel with CONFIG_M586.  Now with the new C3 MB, grub doesn't even load (did I need to reinstall it?), and if I boot with livecd I can't chroot into the old HD without getting "Illegal instruction".

At this point it seems the easiest path forward is to do a clean install, but I'm still curious whether I did something wrong, or if it is just not happy about the i686 CHOST.  I guess I have the whole weekend to try and find out before I need this box back up and running  :Smile: 

----------

## Stever

Still no luck.  Did clean install with stage3-x86-hardened-2.6-2007.0.tar.bz2, then changed CHOST to i686 following Changing the CHOST variable, with CFLAGS="-march=c3 -O2 -pipe -fomit-frame-pointer -fforce-addr".  Binutils builds OK, but gcc fail miserably with 

```
stage1/xgcc -Bstage1/ -B/usr/i686-pc-linux-gnu/bin/ -DEFAULT_PIE_SSP -DEFAULT_RELRO -DEFAULT_BIND_NOW    -march=c3 -O2 -pipe -fprofile-generate -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wold-style-definition     -DHAVE_CONFIG_H -DGENERATOR_FILE  -o genmodes \

         genmodes.o errors.o ../libiberty/libiberty.a

./genmodes -h > tmp-modes.h

/bin/sh: line 1: 16028 Illegal instruction     ./genmodes -h > tmp-modes.h

make[2]: *** [s-modes] Error 132

make[2]: Leaving directory `/var/tmp/portage/sys-devel/gcc-3.4.6-r2/work/build/gcc'

make[1]: *** [stageprofile_build] Error 2

make[1]: Leaving directory `/var/tmp/portage/sys-devel/gcc-3.4.6-r2/work/build/gcc'

make: *** [profiledbootstrap] Error 2
```

I'm starting to think i586 is the way to go...

----------

## loki_val

The C3 lacks the cmov instruction, which isn't technically part of the 686 specification, though every other 686 processor has it. It needs chost to be 586, otherwise it will bomb.

----------

## Stever

 *peteralf wrote:*   

> It needs chost to be 586, otherwise it will bomb.

 

Yes, that is the conclusion I also finally reached.  I was stubbornly hoping that I could leave CHOST as i686 - I'm not sure what neysx has done differently to get their system working with i686, but I was unable to find a way.

In the end here is what worked:

New install with stage3-x86-hardened-2.6-2007.0.tar.bz2

Changed CHOST to "i586-pc-linux-gnu", following the official guide

emerge -e world

In hindsight it might have been easier to change CHOST and rebuild before installing the new MB, but by the time I decided to change CHOST it wasn't worth the trouble to change back the hardware.

Final Results:

```
$ cat /proc/cpuinfo

processor       : 0

vendor_id       : CentaurHauls

cpu family      : 6

model           : 7

model name      : VIA Samuel 2

stepping        : 3

cpu MHz         : 796.183

cache size      : 64 KB

fdiv_bug        : no

hlt_bug         : no

f00f_bug        : no

coma_bug        : no

fpu             : yes

fpu_exception   : yes

cpuid level     : 1

wp              : yes

flags           : fpu de tsc msr cx8 mtrr pge mmx 3dnow

bogomips        : 1593.98

clflush size    : 32

$ emerge --info

Portage 2.1.3.19 (hardened/x86/2.6, gcc-3.4.6, glibc-2.6.1-r0, 2.6.22-hardened-r8 i686)

=================================================================

System uname: 2.6.22-hardened-r8 i686 VIA Samuel 2

Timestamp of tree: Mon, 19 Nov 2007 22:46:01 +0000

ccache version 2.4 [enabled]

app-shells/bash:     3.2_p17

dev-lang/python:     2.4.4-r6

dev-python/pycrypto: 2.0.1-r6

dev-util/ccache:     2.4-r7

sys-apps/baselayout: 1.12.9-r2

sys-apps/sandbox:    1.2.18.1-r2

sys-devel/autoconf:  2.61-r1

sys-devel/automake:  1.10

sys-devel/binutils:  2.18-r1

sys-devel/gcc-config: 1.3.16

sys-devel/libtool:   1.5.24

virtual/os-headers:  2.6.22-r2

ACCEPT_KEYWORDS="x86"

CBUILD="i586-pc-linux-gnu"

CFLAGS="-march=c3 -O2 -pipe -fomit-frame-pointer -fforce-addr"

CHOST="i586-pc-linux-gnu"

CONFIG_PROTECT="/etc"

CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d"

CXXFLAGS="-march=c3 -O2 -pipe -fomit-frame-pointer -fforce-addr"

DISTDIR="/usr/portage/distfiles"

FEATURES="ccache distlocks metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch"

GENTOO_MIRRORS="http://open-systems.ufl.edu/mirrors/gentoo http://gentoo.mirrors.pair.com http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo"

MAKEOPTS="-j2"

PKGDIR="/usr/portage/packages"

PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*"

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/usr/portage"

SYNC="rsync://katana/gentoo-portage"

USE="berkdb bzip2 cracklib crypt hardened iproute2 midi nls nosendmail nptl nptlonly pam pic readline ssl urandom x86 xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="mouse keyboard" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="apm ark chips cirrus cyrix dummy fbdev glint i128 i740 i810 imstt mach64 mga neomagic nsc nv r128 radeon rendition s3 s3virge savage siliconmotion sis sisusb tdfx tga trident tseng v4l vesa vga via vmware voodoo"

Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY

```

Interesting though that uname still reports i686   :Confused: 

----------

## neysx

 *Stever wrote:*   

>  *peteralf wrote:*   It needs chost to be 586, otherwise it will bomb. 
> 
> Yes, that is the conclusion I also finally reached.  I was stubbornly hoping that I could leave CHOST as i686 - I'm not sure what neysx has done differently to get their system working with i686, but I was unable to find a way.

 Actually, the only reason it bombs out is Gentoo clobbers your -march=c3 with -march=i686.

I'm sorry I wasted your time with silly advice about trying -mcpu.

It turned out the build system removes your -march setting and forces -march=i686 based on your CHOST.

I filed bug #199334 but have little hope about it.

My box was built at a time when all this crap did not happen.

I noticed it when trying to upgrade my glibc following this thread.

Look for setup_flags() in /usr/portage/sys-libs/glibc/files/eblits/common.eblit

All I did was comment out the bit of code that replaces -march and voilà! glibc-2.7 builds and runs fine:

```
oreilly ~ # emerge --info

Portage 2.1.3.19 (hardened/x86/2.6, gcc-3.4.6, glibc-2.7-r0, 2.6.23-hardened-r1 i686)

=================================================================

System uname: 2.6.23-hardened-r1 i686 VIA Ezra

Timestamp of tree: Wed, 21 Nov 2007 13:46:01 +0000

app-shells/bash:     3.2_p17-r1

dev-lang/python:     2.4.4-r4, 2.5.1-r4

dev-python/pycrypto: 2.0.1-r6

sys-apps/baselayout: 1.12.10-r5

sys-apps/sandbox:    1.2.18.1-r2

sys-devel/autoconf:  2.13, 2.61-r1

sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10

sys-devel/binutils:  2.18-r1

sys-devel/gcc-config: 1.4.0-r4

sys-devel/libtool:   1.5.24

virtual/os-headers:  2.6.23-r2

ACCEPT_KEYWORDS="x86 ~x86"

CBUILD="i686-pc-linux-gnu"

CFLAGS="-march=c3 -Os -pipe -fomit-frame-pointer"

CHOST="i686-pc-linux-gnu"

CONFIG_PROTECT="/etc"

CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d"

CXXFLAGS="-march=c3 -Os -pipe -fomit-frame-pointer"

DISTDIR="/usr/portage/distfiles"

EMERGE_DEFAULT_OPTS="--alphabetical --nospinner"

FEATURES="ccache distlocks metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch"

GENTOO_MIRRORS="ftp://polly.a.la.maison/gentoo http://www.mirrorservice.org/sites/www.ibiblio.org/gentoo"

MAKEOPTS="-j2"

PKGDIR="/usr/portage/packages"

PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*"

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/usr/portage"

SYNC="rsync://polly/portage"

USE="apache2 bash-completion berkdb bzip2 cracklib crypt curl dpms hardened imap imlib maildir mailwrapper midi moznocompose moznoirc ncurses network nptl nptlonly pic python readline rtc ruby slang ssl symlink unicode urandom usb userlocales x86 xml2 xorg zlib" ELIBC="glibc" KERNEL="linux" USERLAND="GNU"

Unset:  CPPFLAGS, CTARGET, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY

oreilly ~ # cat /proc/cpuinfo

processor       : 0

vendor_id       : CentaurHauls

cpu family      : 6

model           : 7

model name      : VIA Ezra

stepping        : 8

cpu MHz         : 800.065

cache size      : 64 KB

fdiv_bug        : no

hlt_bug         : no

f00f_bug        : no

coma_bug        : no

fpu             : yes

fpu_exception   : yes

cpuid level     : 1

wp              : yes

flags           : fpu de tsc msr cx8 mtrr pge mmx 3dnow

bogomips        : 1602.02

clflush size    : 32

oreilly ~ # ls -l /lib/libc.so.6

lrwxrwxrwx 1 root root 11 Nov 19 09:12 /lib/libc.so.6 -> libc-2.7.so

oreilly ~ # /lib/libc.so.6 

GNU C Library stable release version 2.7, by Roland McGrath et al.

Copyright (C) 2007 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.

There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A

PARTICULAR PURPOSE.

Compiled by GNU CC version 3.4.6 (Gentoo Hardened 3.4.6-r2, ssp-3.4.6-1.0, pie-8.7.9).

Compiled on a Linux >>2.6.23-hardened-r1<< system on 2007-11-18.

Available extensions:

        C stubs add-on version 2.1.2

        crypt add-on version 2.1 by Michael Glad and others

        Gentoo patchset 1.2

        GNU Libidn by Simon Josefsson

        Native POSIX Threads Library by Ulrich Drepper et al

        Support for some architectures added on, not maintained in glibc core.

        BIND-8.2.3-T5B

For bug reporting instructions, please see:

<http://www.gnu.org/software/libc/bugs.html>.

oreilly ~ # uname -a

Linux oreilly 2.6.23-hardened-r1 #2 Fri Nov 16 16:54:30 CET 2007 i686 VIA Ezra CentaurHauls GNU/Linux
```

Glad you're back on your feet despite my "help"  :Wink: 

----------

## loki_val

 *neysx wrote:*   

> Actually, the only reason it bombs out is Gentoo clobbers your -march=c3 with -march=i686.
> 
> I'm sorry I wasted your time with silly advice about trying -mcpu.
> 
> It turned out the build system removes your -march setting and forces -march=i686 based on your CHOST.
> ...

 

No, that only affects glibc ebuilds. And, anyway, march=i686 is what all i686-class CPUs should be able to take. The VIA C3 isn't one in the language of GCC since it doesn't have the cmov instruction. Do a search for via c3 cmov to confirm this.

BTW

The reason glibc clobbers your march flags is that compilation of a newer glibc will fail if people use a >4.2 i686 gcc to build a march=i386 glibc.

----------

## neysx

 *peteralf wrote:*   

>  *neysx wrote:*   It turned out the build system removes your -march setting and forces -march=i686 based on your CHOST.
> 
> I filed bug #199334 but have little hope about it. 
> 
> No, that only affects glibc ebuilds.

 I guess you meant yes since there's nothing above that says otherwise. *peteralf wrote:*   

> And, anyway, march=i686 is what all i686-class CPUs should be able to take.

 Ideally, yes, but unfortunately gcc considers i686 includes the optional cmov instruction. *peteralf wrote:*   

> The VIA C3 isn't one in the language of GCC since it doesn't have the cmov instruction. Do a search for via c3 cmov to confirm this.

 First hit is a post from 2004 that confirms C3 is i686 and it includes a patch to make gcc-3.3.3 better support the C3. *peteralf wrote:*   

> BTW
> 
> The reason glibc clobbers your march flags is that compilation of a newer glibc will fail if people use a >4.2 i686 gcc to build a march=i386 glibc.

 Wrong. glibc does not clobber the -march setting, Gentoo does, as clearly explained above. Dunno why you bring i386 into this discussion. It's not supported anymore by glibc and it's not relevant to this discussion.

```
oreilly / # gcc -v

Using built-in specs.

Target: i686-pc-linux-gnu

Configured with: /var/tmp/portage/sys-devel/gcc-4.2.2/work/gcc-4.2.2/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.2.2 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.2.2/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.2.2 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.2.2/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.2.2/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.2.2/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --disable-nls --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-libunwind-exceptions --disable-multilib --enable-libmudflap --disable-libssp --disable-libgcj --with-arch=i686 --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu

Thread model: posix

gcc version 4.2.2 (Gentoo 4.2.2 p1.0)

oreilly / # /lib/libc.so.6 

GNU C Library stable release version 2.7, by Roland McGrath et al.

Copyright (C) 2007 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.

There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A

PARTICULAR PURPOSE.

Compiled by GNU CC version 4.2.2 (Gentoo 4.2.2 p1.0).

Compiled on a Linux >>2.6.23-hardened-r1<< system on 2007-11-22.

Available extensions:

        C stubs add-on version 2.1.2

        crypt add-on version 2.1 by Michael Glad and others

        Gentoo patchset 1.2

        GNU Libidn by Simon Josefsson

        Native POSIX Threads Library by Ulrich Drepper et al

        Support for some architectures added on, not maintained in glibc core.

        BIND-8.2.3-T5B

For bug reporting instructions, please see:

<http://www.gnu.org/software/libc/bugs.html>.

oreilly / # uname -a

Linux oreilly 2.6.23-hardened-r1 #2 Fri Nov 16 16:54:30 CET 2007 i686 VIA Ezra CentaurHauls GNU/Linux
```

----------

## Stever

I think he is referring to i386 in reference to this bug, which seems to be at least one of the reasons glibc is clobbering the -march.

And no worries about wasting my time - it is only wasted if I didn't learn anything, and at this point I think I have learned a bunch.

Now a potentially stupid question - what would break if I set CHOST="c3-pc-linux-gnu" ?

----------

