| View previous topic :: View next topic |
| Author |
Message |
alexdu
n00b
Joined: 25 Oct 2005
Posts: 49
Location: Moscow, Russia
|
 Posted: Sat Oct 12, 2019 5:11 pm Post subject: A way to simply update slow Gentoo host with a fast one |
 |
|
Hi.
If you are unlucky enough to have a some old-old-old & slow-slow-slow Gentoo host/PC, but you are lucky enough to have at the same LAN a new & fast Gentoo host/PC there is a simple way to fast update an old PC. No distcc, no virtualization, just old good NFS + chroot!
The idea is just simple:
mount via network the whole file-system of a slow host to the fast one, chroot there and update everything.
0. Limitation:
- Both sides MUST have the same arch (CHOST@make.conf). (Crossdev is another story)
- Do not to use -march=native. (Directly setup your arch, e.g. -march=core2)
- For a build (powerful, fast) host recommendations are (by July of 2018):
- CPU No. (including HT) 8+, great choose - 16+
- RAM size 8+, great choose - 16+
- Networking:
- wired is better: fe (100Mb) - is absolutely ok, ge (1Gb) an more - just great
- wireless is not good, but possible with a some slowdown (average inter-host networking T/R rate is about 10Mb/s)
- disk: SSD preferably
- For a target (old, slow) host(s) recommendations are: almost any kind of H/W
- All the target host(s) CPU flags set must be subset of the build host CPU flags set.
E.g., core2 as a target and sandybrige as a build hosts are ok, but not vice-versa.
Alternatively it is possible not to use all targets CPU flags but it is finally slow down binaries.
An example
1. Advantages:
- Per-target host's FLAGS, USE, world and any other system optimizations are working.
- Almost as fast as the build host is fast. (about 90% with 100Mb/s ethernet)
- Simplicity - the old and good NFS+chroot.
I. Installation
- The target host(s) part:
- Enable NFS server in kernel.
- Config NFS for export rootfs (/):
| Code: | # mcedit /etc/exports
# add the line:
/ 10.0.0.0/24(rw,async,crossmnt,no_root_squash,no_subtree_check,insecure,fsid=0)
/boot 10.0.0.0/24(rw,async,no_root_squash,no_subtree_check,insecure) |
- where:
- mcedit - an example text editor
- 10.0.0.0/24 - an example trusted LAN
- /boot - an example submount for kernel compiling; for proper working submounts should not have "crossmnt" & "fsid=0" options
Config NFS server for using newer protocols and using more threads:
| Code: | # mcedit /etc/conf.d/nfs
# add or edit the line:
OPTS_RPC_NFSD="32 -N 2 -V 3 -V 4 -V 4.1" |
Setup in make.conf job amount as on the fast host. E.g. for 8 CPU & 16 RAM on fast host: | Code: | # grep -e MAKE -e OPT /etc/make.conf
MAKEOPTS="-j16 -l16" # -j RAM in Gb -l #CPU * 2
EMERGE_DEFAULT_OPTS="--fail-clean --with-bdeps y --keep-going --binpkg-respect-use -j16 --color=y --autounmask" # -j #CPU * 2 |
The build host part:
- Enable NFS client in kernel.
- Install the tool (the tool source is below) to somewhere like /usr/local/bin/
| Code: | | # cat > /usr/local/bin/chroot-slowPC.sh |
Update the paths in CONSTS section to yours.
II. Usage
- The target host(s) part:
- Start NFS server on all target hosts:
| Code: | | # /etc/init.d/nfs start |
Check it:
| Code: | # exportfs -rv
exporting 10.0.0.0/24:/boot
exporting 10.0.0.0/24:/ |
The build host part:
- Start NFS+chroot tool on the build host:
| Code: | | # chroot-slowPC.sh c300 |
- where:
- c300 - an example host name. Possible to use an IP address or host name if it is resolving to IP.
(If case of something going wrong the tool is produce an error with description.)
III. Notes
- Warning: security setups is not covered with the post - it is assumed that your hosts are inside the trusted LAN.
- It is ok to start the tool for one target host several times on the same build host.
The last instance of the tool will cleanup temp dirs and unmount everything for the target.
- Under chroot on the build host mounted target rootfs points to root (/), in the same time in unchrooted (real) environment it points
to some path (/mnt/nfs/* by default).
- Running building for several target hosts at the same time is absolutely ok unless the build host is powerful enough.
- If you wish to reduce build host load via PORTAGE_NICENESS level - do edit make.conf on THE TARGET host(s).
- Temporary network down is not impacting the process (NFS timeouts are rather big). (So it is generally ok to replug ethernet cord
 )
A. Example part of .config for NFS enable.
The target host must have NFS server and the build host - NFS client. To have server+client on both sides is ok.
| Code: | CONFIG_KERNFS=y
CONFIG_NFS_FS=m
CONFIG_NFS_V2=m
CONFIG_NFS_V3=m
# CONFIG_NFS_V3_ACL is not set
CONFIG_NFS_V4=m
# CONFIG_NFS_SWAP is not set
CONFIG_NFS_V4_1=y
# CONFIG_NFS_V4_2 is not set
CONFIG_PNFS_FILE_LAYOUT=m
CONFIG_PNFS_FLEXFILE_LAYOUT=m
CONFIG_NFS_V4_1_IMPLEMENTATION_ID_DOMAIN="kernel.org"
# CONFIG_NFS_V4_1_MIGRATION is not set
CONFIG_NFS_FSCACHE=y
# CONFIG_NFS_USE_LEGACY_DNS is not set
CONFIG_NFS_USE_KERNEL_DNS=y
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V3_ACL is not set
CONFIG_NFSD_V4=y
CONFIG_NFSD_PNFS=y
CONFIG_NFSD_BLOCKLAYOUT=y
CONFIG_NFSD_SCSILAYOUT=y
CONFIG_NFSD_FLEXFILELAYOUT=y
CONFIG_NFS_COMMON=y
|
B. The tool to mount NFS and chroot to it.
| Code: | #!/bin/bash
# chroot-slowPC.sh
# A tool to mount remote rootfs NFS to local disk and chroot to it.
# Remote host must be passed as 1st param to the tool.
# This can be an IP addres or a hostname. With the second case
# that name must be added to /etc/hosts before invoking the tool.
# Unmounts and cleanups all the temps at exit if no more chroot is
# active. Detecting amount of active chroots by env var with
# target dir searching.
# alexdu @ forums.gentoo.org
# 2018-07-07: Ver 1.1
# 2018-07-12 Ver 1.2
# + check_for_error
# + portageq
# - portageq (slow, please edit manually)
# - check for nfs fs: starting rpc.statd is enought
# 2019-07-17 Ver 1.3
# = changed /lib64 -> /lib
# 2019-10-15 Ver 1.4
# = rpc.statd -> nfsclient
#
_VER=1.4
echo " * chroot-slowPC Ver: ${_VER}"
# load Gentoo funcs for nice echo
source /lib/gentoo/functions.sh
# CONSTS
TARGET=${1} # set (remote) target name by 1st param
MNTROOT="/mnt/nfs/" # local root for mounting and chrooting all targets
TARGETDIR="${MNTROOT}${TARGET}/" # where to mount remote rootfs
NFSCLIENT="/etc/init.d/nfsclient" # command to start NFSCLIENT daemon
TMPFSSIZE="9G" # maximum size of RAM disk (tmpfs) binded to /var/tmp/portage
CCACHE_DIR="/var/tmp/ccache"
PORTAGE_TMPDIR="/var/tmp/portage" # "$(portageq envvar PORTAGE_TMPDIR)/portage"
PORTAGE_LOGDIR="/var/log/portage" # "$(portageq envvar PORT_LOGDIR)"
PORTAGE_DISTDIR="/usr/portage/distfiles" # "$(portageq distdir)"
SPECIALPATHS=(dev sys tmp ${PORTAGE_TMPDIR} ${PORTAGE_DISTDIR} ${CCACHE_DIR} ${PORTAGE_LOGDIR})
# comma separated list of special paths that must be binded
# to chrooted enviroment
function check2ndcroot {
/bin/echo $(/bin/ps ae | /bin/grep -v grep | /bin/grep "${TARGETDIR}" | /bin/wc -l)
}
# todo: put sud for errors
check_for_error() {
if (($?)); then
eerror $1
eend 1
exit $2
fi
}
# check for root
if ((${EUID})); then
eerror "This script must be run as root!" 1>&2
exit 1
fi
# check if one argument is suppled
if [[ "${TARGET}" == "" ]]; then
ewarn "Usage: ${0} <slow PC IP address or name from /etc/hosts>"
exit 12
fi
einfo "Starting up with remote ${TARGET}:"
# starting
# check for 1st session
isFirstSession=0
if (($(check2ndcroot) < 1 )); then
isFirstSession=1
# pre checks
# ebegin " - checking system config for build host"
# # check NFS client support
# # ebegin "\tNFS support"
# if [[ $(/bin/grep "nfs$" /proc/filesystems) == "" ]]; then
# eerror "Kernel NFS client support disabled - please enable it! May be 'modprobe nfs' ?"
# eend 1
# exit 3
# fi
# eend 0
#statements
ebegin " - starting NFS session"
# check and start NFS client
${NFSCLIENT} status > /dev/null 2>&1
if (($?)); then
einfo " - starting NFS Client:"
${NFSCLIENT} start
check_for_error "Can't start NFS Client - please enable it!" 11
# else
# echo "Already started"
fi
# ping the target
/bin/ping -c1 ${TARGET} > /dev/null 2>&1
check_for_error "Can't ping the ${TARGET} - please check connection to it and ${TARGET} hostname resolution!" 12
# make sure mount point exists
if [[ "${HOSTDIS}" == "/" ]]; then
eerror "Internal error!"
eend 1
exit 101
fi
/bin/mkdir -p ${TARGETDIR} > /dev/null 2>&1
check_for_error "Can't create mount point for NFS - please check paths and access!" 13
# mount the slow NFS
/bin/mount -o noatime,fsc ${TARGET}:/ ${TARGETDIR}
if (($?)); then
eerror "Can't connect (mount) NFS for ${TARGET} - please check paths, access and NFSD is running on the target!"
ewarn "Cleaning up ..."
/bin/umount -R ${TARGETDIR}/sys ${TARGETDIR}/dev ${TARGETDIR} > /dev/null 2>&1
rm -rf ${TARGETDIR}
eend 1
exit 14
fi
eend 0
ebegin " - starting chroot session"
# bind special paths
for mp in ${SPECIALPATHS[@]}; do
/bin/mkdir -p ${TARGETDIR}${mp} > /dev/null 2>&1
check_for_error "Can't create special dir ${TARGETDIR}${mp} on NFS volume!" 21
/bin/mount --rbind /${mp} ${TARGETDIR}${mp}
check_for_error "Can't rbind special dir ${TARGETDIR}${mp} on NFS volume!" 22
/bin/mount --make-rslave ${TARGETDIR}${mp};
check_for_error "Can't rslave special dir ${TARGETDIR}${mp} on NFS volume!" 23
done
/bin/mount -t proc /proc ${TARGETDIR}proc
check_for_error "Can't create special dir ${TARGETDIR}${mp} on NFS volume!" 24
eend 0
else
ebegin " - another chroot session detected, skip connecting remote rootfs"
eend 0
fi
einfo ""
einfo "Welcome to interactive NFS chrooted shell for ${TARGET},"
einfo "remote rootfs connected to ${TARGETDIR}."
einfo ""
if ((isFirstSession)); then
einfo " please unmount /var/tmp/portage if do not need tmpfs:"
einfo " # umount /var/tmp/portage"
einfo ""
TARGETDIR="${TARGETDIR}" /bin/chroot ${TARGETDIR} /bin/bash --init-file \
<(/bin/echo ". \"$HOME/.bashrc\"; \
/usr/sbin/env-update && source /etc/profile; \
export PS1=\"\h (chroot@${TARGET}) \w # \"; \
/bin/mount -t tmpfs tmpfs /var/tmp/portage -o size=${TMPFSSIZE}")
# /bin/df -h | /bin/grep /var/tmp/portage; \
# export TARGETDIR=\"${TARGETDIR}\"; \
else
TARGETDIR="${TARGETDIR}" /bin/chroot ${TARGETDIR} /bin/bash --init-file \
<(/bin/echo ". \"$HOME/.bashrc\"; \
export PS1=\"\h (chroot@${TARGET}) \w # \"" )
# /bin/mount -t tmpfs tmpfs /var/tmp/portage -o size=${TMPFSSIZE}")
# /usr/sbin/env-update && source /etc/profile; \
fi
check_for_error "Oops, something going wrong with chroot!" 31
einfo "Cleaning up with remote ${TARGET}:"
if (($(check2ndcroot) < 1 )); then
ebegin " - disconnecting remote rootfs"
umount -R ${TARGETDIR} && \
(eend 0 ; \
ebegin " - removing temp dir ${TARGETDIR}" ;
rm -rf ${TARGETDIR})
eend $?
else
ebegin " - secondary chroot session detected, skip cleaning"
eend 0
fi
# einfo "Buy."
|
Your comments and suggestions are welcome.
C. Troubleshooting.
- List of reasons of slow NFS i/o and tools to check it:
- Network i/o. Tool to check - iperf. To measure start it at both hosts.
- NFS i/o. Tool to check - bonnie++.
| Code: | | # bonnie++ -d /mnt/nfs/bonnie/ -s 2048 -r 1024 -u 0 |
Target PC disk i/o. Tool to check - hdparm.
| Code: | | # hdparm -tT /dev/sd? |
Updates:
2019-10-15: ver 1.4
2019-10-15: Troubleshooting.
2019-10-15: fixes in examples
2019-10-21: an example of CPU subset
Last edited by alexdu on Mon Oct 21, 2019 3:48 pm; edited 3 times in total |
|
| Back to top |
|
 |
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54619
Location: 56N 3W
|
| Posted: Sun Oct 13, 2019 10:43 am Post subject: |
|
|
alexdu,
With the chroot, the fast build box has to execute at least some of the code intended to run on the target.
e.g. the tool chain, shell etc.
Its a good idea to check that the build box instruction set is a superset of the slow box.
You really don't want an Illegal Instruction exception running on the build box because say bash just got rebuilt with an instruction the build box can't execute.
It won't do any harm to the target but it will stop your update in its tracks.
Trial and error is harmless. The way out is to rebuild affected packages on the slow host so that they can run on the fast one.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
alexdu
n00b
Joined: 25 Oct 2005
Posts: 49
Location: Moscow, Russia
|
| Posted: Tue Oct 15, 2019 4:34 pm Post subject: |
|
|
| NeddySeagoon wrote: | alexdu,
Trial and error is harmless. The way out is to rebuild affected packages on the slow host so that they can run on the fast one. |
I guess it is possible but the list of "tool-chain" will be long. It is not C tool chain, it is portage tool chain including python, various cashes updates and system dependencies as glib and others. And probably it should be done several times.
Find "compat" CPUs I guess it is simpler. |
|
| Back to top |
|
|
alexdu
n00b
Joined: 25 Oct 2005
Posts: 49
Location: Moscow, Russia
|
| Posted: Tue Oct 15, 2019 4:37 pm Post subject: |
|
|
The tool is updated to ver. 1.4
Staring rpc.statd instead of nfsclient can slowdown NFS i/o. Moved to start nfsclient. |
|
| Back to top |
|
|
Arvo
n00b
Joined: 30 Sep 2019
Posts: 9
|
| Posted: Mon Oct 21, 2019 2:05 pm Post subject: |
|
|
Newbie here, who is looking to compile everything from my desktop. This is a tremendous post you have made alexdu, thank you so much for sharing. This seems to be a lot easier to set up than to set up distcc.
I have a silly question:
I just recently finished my desktop installation and I'm planning on installing gentoo on my slow laptop.
The fastbox is running all AMD stuff (AMD Phenom X4 965 BE Cpu) and the laptop would is all intel (i7-7500u, 2 cores 4 threads).
| NeddySeagoon wrote: |
...
Its a good idea to check that the build box instruction set is a superset of the slow box.
You really don't want an Illegal Instruction exception running on the build box because say bash just got rebuilt with an instruction the build box can't execute.
It won't do any harm to the target but it will stop your update in its tracks.
...
|
Correct me if I am wrong but we're talking about the CPU instruction set here are we? Would this be a problematic for my purpose? |
|
| Back to top |
|
|
alexdu
n00b
Joined: 25 Oct 2005
Posts: 49
Location: Moscow, Russia
|
| Posted: Mon Oct 21, 2019 3:37 pm Post subject: |
|
|
| Arvo wrote: | | Newbie here, who is looking to compile everything from my desktop. This is a tremendous post you have made alexdu, thank you so much for sharing. This seems to be a lot easier to set up than to set up distcc. |
By my measures distcc is slower.
| Arvo wrote: | I just recently finished my desktop installation and I'm planning on installing gentoo on my slow laptop.
The fastbox is running all AMD stuff (AMD Phenom X4 965 BE Cpu) and the laptop would is all intel (i7-7500u, 2 cores 4 threads).
Correct me if I am wrong but we're talking about the CPU instruction set here are we? Would this be a problematic for my purpose? |
Yes, we are talking about CPU instructions set, target set should be subset for build host.
For example... there are 1 target host and 2 candidates for build host:
To get instructions set of CPU do:
| Code: | | # cat /proc/cpuinfo | grep flags | head -n1 |
A sample target (slow) host with Intel(R) Atom(TM) CPU 330 @ 1.60GHz:
| Code: | # cat /proc/cpuinfo | grep flags | head -n1
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts nopl cpuid aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm dtherm |
A sample build (fast) host 1 with Intel(R) Core(TM) i7-3770S CPU @ 3.10GHz:
| Code: | # cat /proc/cpuinfo | grep flags | head -n1
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm cpuid_fault epb ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts md_clear flush_l1d |
A sample build (fast) host 2 with Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz:
| Code: | # cat /proc/cpuinfo | grep flags | head -n1
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm cpuid_fault epb invpcid_single ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt dtherm ida arat pln pts md_clear flush_l1d
|
Here the target host CPU has instruction [set] named "movbe", while 1st possible build host has no the instruction and the 2nd one has "mobve". Here we have two chooses:
- Use 2nd build host and "CFLAGS="-mmovbe""
- or use 1st build host and CFLAGS without movbe (it can be specified directly or via -Ox option (please see man gcc)
In first case target binaries will build with "movbe" use, in second - without.
Note 1.
But not all CPU flags are indicate an instruction set, for example, apic, acpi and many others not related to a code but describe CPU hardware. Those flags can be skipped safely.
To check what flags are meaningful for C compiler gcc, you can run:
| Code: | | # gcc -march=native -Q --help=target |
or more specific for you CPU and optimization, e.g.:
| Code: | | # gcc -O2 -march=haswell -Q --help=target |
returning to the question about AMD and Intel...
It is the same. You can compare flags of both CPUs to check if the target absolutely binary compatible with the build CPU. Or post here flags of both CPU to compare together. Or just try - if emerging stops with "Illegal instruction" or "Segfault" - no, not compatible and you have 2 chooses above... |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54619
Location: 56N 3W
|
| Posted: Mon Oct 21, 2019 4:58 pm Post subject: |
|
|
Arvo,
There are no silly questions, except the one you don't ask as you never learn the answer.
Be on you guard for silly answers though.
AMD and Intel CPUs have a core set of instructions in common. That's what you get when you set CFLAGS as it is in the stage3 as the stage3 needs to run everywhere.
Hold that thought.
If you force portage to use | Code: | | CFLAGS="-mtune=generic -pipe -O2" |
for the packages in the stage3, at least your toolchain won't break.
Then you can use the real target CFLAGS everywhere else.
Homework: Read not all of it ... yet :)
Pay particular attention to /etc/portage/env/ and /etc/portage/package.env
This Wiki page is useful too.
Its not quite as simple as I make out as some build systems compile code during the course of the build, then attempt to run it on the build host.
Than may cause you Illegal Instruction exceptions but you will notice them.
There are packages where speed doesn't matter.
Do you care how long libreoffice waits for your keystrokes?
On the other hand, it can be important for multimedia applications, either directly, to avoid frame dropping, or indirectly, to extend battery life.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9838
Location: almost Mile High in the USA
|
| Posted: Mon Oct 21, 2019 7:15 pm Post subject: |
|
|
I gave up on nfs (or even direct connect disk access) builds because invariably my fast machine (i7) does not support all the instructions of my slow ones (atom) and vice versa. Kept on getting illegal instruction because some software packages simply assume the machine you're compiling on is the machine you're running on, though gcc is getting better, the packages' build routines are not.
Ultimately need some separation between the build machine and run machine, so I try my best to get distcc to work properly, and may even have to resort to qemu to emulate instructions (including illegal instructions, which it does not always do properly!!! *1) as needed to make sure the target host gets binaries that will work and run as fast as possible.
And yes I care how fast firefox and libreoffice responds to my keystrokes. Lately firefox sometimes takes a second or so before it responds to keystrokes and that gets annoying fast, probably due to interpreting HTML5 - even when not using multimedia libraries to speed those up.
Ever wonder why firefox takes forever to clear cookie and history entries (relatively speaking)? What gives?
---
*1 - I was trying to build Gentoo for a 486 at one point with my i7, and found that qemu will run instructions that a real 486 will not, even when you specify 486 as the emulation CPU.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
alexdu
n00b
Joined: 25 Oct 2005
Posts: 49
Location: Moscow, Russia
|
| Posted: Tue Oct 22, 2019 9:15 am Post subject: |
|
|
| eccerr0r wrote: |
*1 - I was trying to build Gentoo for a 486 at one point with my i7, and found that qemu will run instructions that a real 486 will not, even when you specify 486 as the emulation CPU. |
I tried to sep up qemu for Atom on i7, it's not good. There are two modes in qemu: native (or hardware virtualization) and emulation. In native mode it uses kvm which uses physical CPU to run code, so it is impossible use instructions not supported by the physical CPU. In second mode qemu can emulate some CPU (but not any) but this is real software virtualization with very low speed. |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9838
Location: almost Mile High in the USA
|
| Posted: Tue Oct 22, 2019 3:37 pm Post subject: |
|
|
To be honest, it wasn't qemu's fault, but it failed to alert me that something was wrong until I introduced the image to the target machine.
QEMU at least reports the correct CPUID to the build process and the build process is aware that it needs to target the other machine -- this is the most valuable bit of information that QEMU provides. However the build process happened to have a bug that assumed a different processor and built it for that other processor anyway, generating binaries that would work in QEMU but not on the 486. I don't think I could have run the build script on the 486 but I think it would have failed to build working binaries on the real hardware too, just that it was too bad that I'd rather see the illegal instructions run on fast virtualization before seeing it fail on real hardware.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Documentation, Tips & Tricks
