This walkthrough is for a FreeBSD-compatible Metin2 branch whose server files, schema and matching client you already have permission to use. It explains the installation order and what must pass at each stage. A C# or Go emulator has a different deployment process. Do not apply this layout to those projects.
1. Write the compatibility sheet before installing
Record the source revision, documented OS/release, CPU architecture, compiler, database version, game/db binaries, schema and matching client revision. If the pack has no build notes, inventory it before choosing an OS. A newer host does not automatically run an old 32-bit executable. Keep obsolete environments private while planning a supported replacement; do not expose a legacy VM as your public server.
2. Prepare an isolated VM
Use the official FreeBSD installation guide and a supported release compatible with your build plan. Give the VM a private network and keep console access. Take a clean snapshot before importing server data. Create a dedicated unprivileged game service account and a separate administrative account. Do not run game processes as root simply because an old start script does.
On FreeBSD, collect these read-only checks and retain their output:
uname -a
uname -m
freebsd-version
sockstat -4 -6 -lThe last command shows listeners, not whether a firewall permits remote access. Record who should reach each listener. Database, inter-core and administration traffic should not be public by default.
3. Stage files without overwriting the host
Inspect archive paths and startup scripts before extraction or execution. Use a dedicated staging directory; do not unpack an unknown filesystem archive over /. Identify game, db, auth/channel configurations, locale/quest data and symbolic links. Match each startup command to its working directory and binary. Give the runtime account write access only where it needs logs or state. Do not use recursive chmod 777 as an installation fix.
4. Initialise the database separately
Install the database version supported by your branch using its own documentation. Restore schema/data only into the isolated test database. SQL exports and a raw database directory require different restore procedures; copying old data files into a running newer database is not a migration. Replace supplied passwords, keep database access on a local/private interface and give the game account only the privileges its schema needs. Keep migration privileges separate. Never point a test game at the production database.
5. Configure and start one layer at a time
Read the branch's configuration names rather than guessing a universal CONFIG file. Map database credentials, internal addresses, public/client-facing addresses, per-core ports and map/channel assignments. Avoid reusing one port for two processes. Start the database, then the branch's db service, then auth and one game channel in the order its startup scripts document. Check each layer's log before starting the next. The exact process layout varies between serverfiles.
6. Prove a first login and persistence
Use a new test account created through your branch's normal account tool. Connect with the matching client, select/create a character, enter a map, move, perform one inventory action, log out and restart the test services cleanly. Confirm the expected state persists. A listening port or login screen alone is not a successful installation.
OS / architecture:
Source and deployed binary revisions:
Database version and schema revision:
Matching client revision:
First failing layer:
Relevant log lines, without passwords:
Login / map entry / persistence result:Validation and next steps
This is an original installation procedure, not a claim that M2City booted your pack. Commands were checked against FreeBSD documentation; a full VM/game installation was not performed for this article. For access controls read the server exposure guide; before changing player data, follow the restore drill. Post the compatibility sheet and the first failing stage in this discussion.