Licensing Issue


We currently have bitkeeper installed on a host where it’s true that the license has expired, in some sense. Rather than possibly damage the existing installation, I’d like to clone all of its repos to a different host. The latter has an instance of bk installed: bk-6.1.3 20150310145524 for x86-glibc213-linux.

What steps should I take to get that 6.1.3 installation to bk-7.3.2 for x86_64-glibc223-linux ?

On the old instance:

1035      2647  0.0  0.0  12208  1252 ?        Ss   Sep01   0:16 bk bkd -D -l/var/local/bitkeeper/log/system.log -P/var/local/bitkeeper/run/pid.system -d -p5562 -xcd -xpush
 -P/var/local/bitkeeper/run/pid.system-alpha -d -p5563 -xcd -xpush
 -P/var/local/bitkeeper/run/pid.eng-dev.d -d -p5546 -C -xpush
997       2662  0.0  0.0   5876  1016 ?        Ss   Sep01   0:03 bk bkd -D -l/var/local/bitkeeper/log/client-dev.d.log -P/var/local/bitkeeper/run/pid.client-dev.d -d -p5547 -C -xpush

So, it seems to be listening on 5562, 5563, 5546, 5547. My plan was to get the 2nd instance up to , then run the following, against each of those ports:

bk clone -sALL

I’ve instructions on installing a fresh copy of 7.3.2, but I wasn’t sure if those would apply, where what is essentially an upgrade is concerned.



If the license has expired on the old machine, then running a ‘bk clone’ isn’t going to work since bk-6.1.3 on the old machine won’t have a license to read the data.

I would suggest you install bk on the new machine and then use rsync to copy over all of the repositories. Then you can use the same script to start the bkd’s on the new machine to make them accessible.

For validation, I suggest running ‘bk repocheck’ on each repository on the new machine to make sure it is able to read and parse all of them.

If you do want to run ‘bk clone’ then I suggest adding --upgrade to make sure they get rewritten using the latest repository format.

Ok, when you speak of running rsync, I’m not sure exactly what you mean. I know the command, but are there particular options that I should use? Which folders on the old host should I target?

The host that I’m looking to move the repos to already has bk installed. It’s on 6.1.3. How do I go about getting it to bk-7.3.2 for x86_64-glibc223-linux ?

Oh, and based on that “ps” output, I looked at “/var/local/bitkeeper”:

hutz:/var/local/bitkeeper# ls
log repositories.20041101.30465 repositories.20060807.2242
repositories repositories.20041213.31555 repositories.20080604.833
repositories~ repositories.20050110.8602 repositories.20110321.6136
repositories.20040601.17750 repositories.20050126.28481 repositories.20110321.7436
repositories.20040624.12699 repositories.20050225.966 repositories.20130222.24203
repositories.20041020.10517 repositories.20050301.27317 run
repositories.20041020.23563 repositories.20050308.2418

hutz:/var/local/bitkeeper# ls -al run/
total 40
drwxrwxrwx 2 root staff 4096 2017-09-01 09:16 .
drwxr-xr-x 4 root staff 4096 2013-02-22 16:03 …
-rw-rw-r-- 1 bkd-client-dev bkd 5 2017-10-25 12:46 pid.client-dev.d
-rw-rw-r-- 1 bkd-eng-dev bkd 5 2017-10-25 12:46 pid.eng-dev.d
-rw-rw-r-- 1 bkd-libproduct-common-0-11 bkd 5 2013-02-22 11:58 pid.libproduct-common-0.11
-rw-rw-r-- 1 bkd-product-stable bkd 5 2013-02-22 11:58 pid.product-1.6
-rw-rw-r-- 1 bkd-product-dev bkd 5 2013-02-22 11:58 pid.product-1.7
-rw-rw-r-- 1 bkd-product-rngl-0-1 bkd 5 2013-02-22 11:58 pid.product-rngl-0.1
-rw-rw-r-- 1 bkd-system bkd 5 2017-10-25 12:46 pid.system
-rw-rw-r-- 1 bkd-system-alpha bkd 5 2017-10-25 12:46 pid.system-alpha

Perhaps I just should have said: copy the data from the old machine to the new one. I would use rsync to do that copy.

rsync -av oldmachine:/path /path-on-new

That machine probably has a /etc/init.d/bitkeeper init script that starts the bkds. It reads the /var/local/bitkeeper/repositories file to see which bkd’s to start and puts the pids in ‘run’.

If you have a link that points to complete instructions for getting bk-7.3.2 installed, could you send that over, please? I’m still wondering if the installer will simply overwrite the version that’s there on the new host, if one or more processes need to be stopped, ahead of running the installer, etc.

Install instructions are linked from the download page.

Without X you probably just want:

OLDBIN=`bk bin`
rm -rf $OLDBIN
./bk-7.3.2-x86-glibc219-linux.bin $OLDBIN

(or something similar)

And yeah you will need to kill and restart the bkd’s. The man pages for that are here:

Where you wrote “Install instructions are linked from the download page”, I’m afraid this didn’t really make sense to me. I see nothing that looks to be that link, any where on the current page (Licensing Issue)

Another concern has come up for me, also. A number of our hosts (including the one that I’m looking to move the bk data and instance to… let’s call it “targethost”) are running nfsroot-based setups. For example (this is from targethost):

df -h | grep ‘/usr’

/dev/sda5 94G 12G 82G 13% /usr/local

While “/” is nfsrooted:
192.xx.yy.zz:/home/nfsroot/wheezy 120G 32G 88G 27% /

On all hosts:

which bk


So, my concern is that upgrading bk on targethost will make it such that users of other hosts (who also have their “/usr” sitting on 192.xx.yy.zz:/home/nfsroot/wheezy) will suddenly start trying to hit bk-6.1.3 data with a bk-7.3.2 binary.

Does this make sense? Is 7.3.2 backward compatible to the extent that it will make this a non-issue?

Ok, referencing these instructions:

    bk clone -sTHERE bk://
    cd bugfix/src
    bk -U^G co
    make p image
    cd utils
    # there will be a file here like
    # bk-7.3.2-x86_64-glibc223-linux.bin
    # that is your install image, run that as root and install it

I get an error on the first step:

bk clone -sTHERE bk://

clone: bugfix: Permission denied

Close is trying to create a directory called ‘bugfix’ in the current directory and you don’t have write permission to create that directory.

But do you really need to build from source? I would recommend just using one of the pre-made binary images.

Arrg! I was logged in as root and running the command from /root, so I didn’t expect to have a permissions problem. It’s this blasted nfsroot setup: makes it such that “/root” is on a read-only filesystem.

Oh, and I would actually prefer to use pre-made binaries. 'Still not clear, though, on that “Install instructions are linked from the download page”, from your earlier message.

The nfsroot thing is still a major concern for me. I really don’t want to have folks on my team locked out of bk, but

192.xx.yy.zz:/home/nfsroot/wheezy 120G 32G 88G 27% /

Is likely the setup for a number of our hosts. “/usr/bin/bk” is on that filesystem.

More info on our current setup (that 192.xx.yy.zz host, in particular):

192.xx.yy.zz:which bk

192.xx.yy.zz:bk version

BitKeeper version is bk-6.1.3 20150310145524 for x86_64-glibc213-linux

192.xx.yy.zz:cd /home/nfsroot/wheezy/usr/bin
192.xx.yy.zz:ls -al bk
lrwxrwxrwx 1 root root 21 Apr 16 2015 bk -> /usr/lib/bitkeeper/bk

Ok, I need to get this done, so that our Devs are not locked out of bitkeeper. So, I decided to try and just push ahead with building from source.

I was hoping to install to a location other than the one that’s on the nfsrooted filesystem. I created a /var/local/bitkeeper7 folder, and started working from there, but the installer is trying to work against the blasted nfsrooted stuff and having trouble, of course, because the target filesystem is read-only:

192.xx.yy.zz:/var/local/bitkeeper7# bk clone -sTHERE bk://
lockfile: /root/.bk/lease is not writable.
Clone bk://
-> file:///var/local/bitkeeper7/bugfix
. 0% | |
lockfile: /root/.bk/lease is not writable.

lockfile: /root/.bk/lease is not writable.
. 5% |= |
lockfile: /root/.bk/lease is not writable.
lockfile: /root/.bk/lease is not writable. |
lockfile: /root/.bk/lease is not writable.= |
lockfile: /root/.bk/lease is not writable.=========================== |
. 100% |==============================|
lockfile: /root/.bk/lease is not writable.
lockfile: /root/.bk/lease is not writable.
lockfile: /root/.bk/lease is not writable.

I’m thinking, at this point, that it might be best to run “”/etc/init.d/bitkeeper stop" on the host that has those daemons up and rsync off the entire “/var/local/bitkeeper” folder to a backup location. Then, run the bk7 installer on that host and on the 192.xx.yy.zz that’s nfsroot-sharing out a root partition to a number of others, and, finally, bring up bk7.

My concerns are likely obvious, but how does this course of action sound?

  • goto
  • click Download
  • see the Linux header
  • download the 64-bit installer that matches your machine
  • right under those see the link labeled “Installation Instructions”, click that
  • Read the part about the “Command Line Installer”

There is no need to install as root. Install as some user that doesn’t have permissions to mess up /usr/bin. The installer gives you a directory and tries to create a symlink for ‘bk’. You can put those wherever you want. Copy the directory to /usr/libexec/bitkeeper-7.3.2 and then put a symlink to /usr/libexec/bitkeeper/7.3.2/bk on your PATH in a place where it will only impact this machine while testing.

This is running the old bk which needs to get a license, but you don’t have a writable HOME directory.

Note that bk-6.1.3 can’t read repositories created by the bk-7.x series. We have a new disk layout for a huge performance win. So you can’t clone the bk source with your old bk. bk-7.0 was released in 2015.

If you wanted to build from source, then you need to download the source tarball from the downloads area on the webpage.

Thanks. I’ll run with this…

And, yeah, I figured we were dealing with very old software, but most of the infrastructure that I’m wrestling with is state of the art, circa 2004. I’m part of a team that’s working on upgrading things, but we all started, within the past month or so. Fun, fun.

Ok, I managed to get 7.3.2 installed on the alternate host. I’m wondering about the bit-clone option, again, though: will it work to run the bk7.3.2 executable against the bk6 host, to clone off to the alternate host? To cut-over, we could then just run “/etc/init.d/bitkeeper stop” on the old server and “/etc/init.d/bitkeeper start” on the new one.

bk-7.3.2 should be able to read and write all your existing repositories and it won’t upgrade them unless you clone with --upgrade so it shouldn’t prevent your older bk from running.

Also, the newer bkd should be fully compatible with the older clients.

So it is my belief you can upgrade that bk without breaking anything. So yeah stop the old bkd’s and start the new ones and then start testing.

When you are fully upgraded then doing a --upgrade on your main repositories is a good idea because it is a big performance win.

Thanks. We’ll give it a go.