Not able to basecalling in MinKNOW

[lixiaopi1985]

Hi @sirselim, thank you for your tutorial. I was able to have guppy 5.0.11 shown in the nvidia-smi output. However, when I was trying basecalling in the minKNOW UI, it did not fire up, and util I plugged in the minION, an error message just showed. I am not sure why this happens.

Here is some of the output of mk_manager_log, seems like minknow is pointing to the wrong path to guppy (it is located in /opt/ont/guppy/), while in the app_config, the guppy is set to the right path.

2021-08-03 12:17:03.420968   ERROR: guppy_executable_missing (util)
    executable: /opt/ont/minknow/guppy/bin/guppy_basecall_server
2021-08-03 12:17:03.442638 WARNING: cannot_read_component_version (shmem)
    version_file: <unknown type>
2021-08-03 12:17:03.442741 WARNING: cannot_read_component_version (shmem)
    version_file: <unknown type>
2021-08-03 12:17:03.443505    INFO: ping_flusher_network_up (mk_manager)
2021-08-03 12:17:03.444539   ERROR: guppy_executable_missing (util)
    executable: guppy/bin/guppy_basecall_server
2021-08-03 12:17:03.444968    INFO: mk_manager_starting (mk_manager)
    core_version: 4.3.4
    config_version: Unknown
    bream_version: Unknown
    system: User-provided system running on ubuntu 18.04
    distribution_version: unknown
    distribution_status: modified
    guppy_version: unknown
2021-08-03 12:17:03.454171   ERROR: guppy_executable_missing (util)
    executable: guppy/bin/guppy_basecall_server
2021-08-03 12:17:03.454429    INFO: starting_guppy_server (mk_manager)
    path: guppy/bin/guppy_basecall_server
    guppy_version: unknown
2021-08-03 12:17:03.457371    INFO: local_auth_token (host)
    path: /tmp/minknow-auth-token.json
2021-08-03 12:17:03.457825    INFO: mk_manager_initialised (mk_manager)
    pid: 5165
2021-08-03 12:17:03.459931    INFO: common_process_started (host)
    name: guppy
2021-08-03 12:17:03.462136    INFO: common_process_started (host)
    name: grpcwebproxy
2021-08-03 12:17:03.464377    INFO: common_process_started (host)
    name: basecall_manager
2021-08-03 12:17:03.464642   ERROR: common_process_crashed (host)
    arguments: --config
               dna_r9.4.1_450bps_fast.cfg
               --port
               5555
               --log_path
               /var/log/minknow/guppy
               --ipc_threads
               3
               --max_queued_reads
               5000
               --num_callers
               1
               --cpu_threads_per_caller
               30
    name: guppy
    executable: guppy/bin/guppy_basecall_server
    exit_code: 1
    recent_output: 
2021-08-03 12:17:03.496755    INFO: rpc_delegate_is_listening (host)
    executable: basecall_manager
    port: 33993
    security: tls
2021-08-03 12:17:03.500220    INFO: common_process_started (host)
    name: basecall_manager:grpcwebproxy
2021-08-03 12:17:03.511583    INFO: rpc_delegate_proxy_is_listening (host)
    executable: basecall_manager
    tls_port: 9505
2021-08-03 12:17:33.465197 WARNING: common_process_failed_to_setup_input_pipe (host)
    name: guppy
    std_ec: (1:std::boost.asio.misc): [0x0x7f1324005e30]: Already open
2021-08-03 12:17:33.467815    INFO: common_process_started (host)
    name: guppy
2021-08-03 12:17:33.468878   ERROR: common_process_crashed (host)
    arguments: --config
               dna_r9.4.1_450bps_fast.cfg
               --port
               5555
               --log_path
               /var/log/minknow/guppy
               --ipc_threads
               3
               --max_queued_reads
               5000

If you can give me some of your insight, that might help me to resolve this issue.

Thank you, Xiaoping

[sirselim]

Hi @lixiaopi1985 - I'm wondering if you might have installed the ont-guppyd-for-minion package? If you run the following do you get any output?

systemctl status guppyd

or

sudo service guppyd status

[lixiaopi1985]

Hi @sirselim, following the command, it says guppyd.service could not be found.

[sirselim]

OK, what about systemctl status minknow.service?

[lixiaopi1985]

Here is the output:

● minknow.service - MinKNOW Instrument Software for MinION (daemon)
   Loaded: loaded (/lib/systemd/system/minknow.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2021-08-03 22:57:24 EDT; 10h ago
  Process: 1279 ExecStartPre=/bin/sleep 15 (code=exited, status=0/SUCCESS)
 Main PID: 1295 (mk_manager_svc)
    Tasks: 189 (limit: 4915)
   CGroup: /system.slice/minknow.service
           ├─1295 /opt/ont/minknow/bin/mk_manager_svc
           ├─1297 /opt/ont/minknow/bin/crashpad_handler --database=/var/lib/minknow/data/core-dump-db --metrics-dir=/var/lib/minknow/data/core-dump-db --url=https://submit.backtrace.io/nanoporetech/6e3c4958cfd996b7000dadb02a931ff700986aa48b33903b5902dff716c95809/minidump --annotati
           ├─1350 /opt/ont/guppy/bin/guppy_basecall_server --config dna_r9.4.1_450bps_fast.cfg --port 5555 --log_path /var/log/minknow/guppy --ipc_threads 4 --max_queued_reads 5000 --chunks_per_runner 80 --num_callers 6 -x cuda:all --gpu_runners_per_device 1
           ├─1351 /opt/ont/minknow/bin/grpcwebproxy --server_tls_cert_file=/opt/ont/minknow/conf/rpc-certs/localhost.crt --server_tls_key_file=/opt/ont/minknow/conf/rpc-certs/localhost.key --backend_addr=127.0.0.1:46003 --backend_tls_noverify --backend_tls=true --server_bind_addres
           ├─1352 /opt/ont/minknow/bin/basecall_manager --guppy-address 5555 --conf /opt/ont/minknow/conf --insecure 127.0.0.1:9504 --secure 127.0.0.1:0 --queued-command-count 1
           ├─1359 /opt/ont/minknow/bin/crashpad_handler --database=/var/lib/minknow/data/core-dump-db --metrics-dir=/var/lib/minknow/data/core-dump-db --url=https://submit.backtrace.io/nanoporetech/6e3c4958cfd996b7000dadb02a931ff700986aa48b33903b5902dff716c95809/minidump --annotati
           ├─1364 /opt/ont/guppy/bin/crashpad_handler --database=/var/log/minknow/guppy/guppy_basecall_server-core-dump-db --metrics-dir=/var/log/minknow/guppy/guppy_basecall_server-core-dump-db --url=https://submit.backtrace.io/nanoporetech/7a24030541d099764b8e1c5b9aed2dd678c747bb
           └─1418 /opt/ont/minknow/bin/grpcwebproxy --server_tls_cert_file=/opt/ont/minknow/conf/rpc-certs/localhost.crt --server_tls_key_file=/opt/ont/minknow/conf/rpc-certs/localhost.key --backend_addr=127.0.0.1:38457 --backend_tls_noverify --backend_tls=true --server_bind_addres

[sirselim]

@lixiaopi1985 - OK I've just seen your most recent post on the Nanopore forum. It's useful if you are asking for help in multiple places to include all the information at each place you ask, otherwise effort gets duplicated.

As I said on the forum, it looks like minknow isn't finding guppy at the suggested location (/opt/ont/guppy/bin/).

What does the below report?

/opt/ont/guppy/bin/guppy_basecaller --version

[lixiaopi1985]

Yes, while your notes are extremely helpful in most of the cases, I was asking it again on the forum in hope to maybe get a wider support and also I have been trying other approach as well. Hopefully, a solution can be surfaced and be shared for this matter.

So the version is 5.0.11, installed via sudo apt install ont-guppy. Guppy Basecalling Software, (C) Oxford Nanopore Technologies, Limited. Version 5.0.11+2b6dbffa5

[sirselim]

If you want GPU enabled basecalling you can't install the guppy from the ONT repository, using sudo apt install ont-guppy is not a solution on Linux machines running GPUs.

If you download the compressed binaries from the software download page and follow either ONT or my instructions for setting up GPU guppy this should solve the issue.

[sirselim]

@lixiaopi1985 - just to clarify my previous statement was supporting asking for help, but please remember if you are asking in different places to include all information everywhere you ask and update this information for all. It saves people spending their time duplicating effort solving 'problems' that might not need to be solved if they have all the pieces of the puzzle. 😉

[lixiaopi1985]

@sirselim I was using the compressed binary guppy earlier, which did not work, that is why I installed ont-guppy last night to see if it might help because I am using ubuntu 18.04. I will give the compressed version another shot again.

Roger on the courtesy of aksing for help and thank you for the help!

[sirselim]

@lixiaopi1985 no problem, happy to offer what help I can.

The issue with the guppy versions that are part of the ONT repository are that one is CPU only and the other whilst being GPU enabled is compiled against CUDA 9 - even though your running 18.04 I'm guessing your using a newer version of CUDA than that...?

Hence the need to use the version from the forums that is compiled by ONT for GPU. It's compiled against CUDA 11.1 (from memory) and has backwards compatibility, meaning a system with CUDA 10.2 installed on it will also work with the pre-compiled binaries.

I'm not sure what else I can say at the moment other than just today I set up a laptop running Ubuntu 20.04 with the latest version of minknow and guppy using my process and its currently sequencing with live basecalling. I have started using a slightly updated process that includes a guppy service (guppyd.service), but this is more testing for future builds that will require it, it's not currently necessary. You'll find the update in my notes about live basecalling.

[lixiaopi1985]

@sirselim I uninstalled the ont-guppy, and downloaded the guppy for linux (GPU version). Although the error message on the wrong guppy path is not there anymore, the minKNOW still can not start the basecalling or start the "experiment".

mk_manager log is shown as below:

2021-08-08 17:04:59.700833    INFO: ping_flusher_network_up (mk_manager)
2021-08-08 17:04:59.715229    INFO: mk_manager_starting (mk_manager)
    bream_version: 6.2.5
    system: User-provided system running on ubuntu 18.04
    distribution_version: unknown
    distribution_status: modified
    core_version: 4.3.4
    guppy_version: 5.0.11+2b6dbff
    config_version: 4.3.9
2021-08-08 17:04:59.739622    INFO: starting_guppy_server (mk_manager)
    path: /opt/ont/ont-guppy_5.0.11/bin/guppy_basecall_server
    guppy_version: 5.0.11+2b6dbff
2021-08-08 17:04:59.742959    INFO: local_auth_token (host)
    path: /tmp/minknow-auth-token.json
2021-08-08 17:04:59.743474    INFO: mk_manager_initialised (mk_manager)
    pid: 17861
2021-08-08 17:04:59.745727    INFO: common_process_started (host)
    name: guppy
2021-08-08 17:04:59.747929    INFO: common_process_started (host)
    name: grpcwebproxy
2021-08-08 17:04:59.750089    INFO: common_process_started (host)
    name: basecall_manager
2021-08-08 17:04:59.806871    INFO: rpc_delegate_is_listening (host)
    security: tls
    executable: basecall_manager
    port: 36341
2021-08-08 17:04:59.809518    INFO: common_process_started (host)
    name: basecall_manager:grpcwebproxy
2021-08-08 17:04:59.819355    INFO: rpc_delegate_proxy_is_listening (host)
    executable: basecall_manager
    tls_port: 9505
2021-08-08 17:06:57.241244    INFO: sending_telemetry_message (ping)
    data: {"mk_authentication_result":{"access_requested":"MinKNOWAccess","approved":true,"authorised_email":false,"device_requested":"","errors":[],"groups"...
2021-08-08 17:12:15.624505    INFO: ping_flusher_network_changed (mk_manager)

basecall_manage log:

2021-08-08 17:04:59.766674    INFO: starting_up (basecall_manager)
    version: 4.3.4
    hostname: SE-A-CH2-SCRI
2021-08-08 17:04:59.806567    INFO: manager_notified_new_local_auth_token (util)
    expires_in: 89999936527562ns
2021-08-08 17:12:32.893951    INFO: running_client (basecall_manager)
    arguments: --port
               5555
               --server_file_load_timeout
               600
               --num_callers=1
               --save_path
               /media/.../Soil_wholegenome/out
               --config
               dna_r9.4.1_450bps_hac.cfg
               --input_path
               /media/.../Soil_wholegenome/VAC1/20190715_2119_MN30506_FAK92323_5a6c0c9c/fast5_pass
               --compress_fastq
               --progress_stats_frequency=2
    id: 1
    executable: /opt/ont/ont-guppy_5.0.11/bin/guppy_basecall_client
2021-08-08 17:12:32.918031 WARNING: output_unexpectedly_terminated (basecall_manager)
    id: 1
    error: (2:std::asio.misc): [0x0x11328d8]: End of file
2021-08-08 17:12:32.918829   ERROR: analysis_process_failed (basecall_manager)
    output: boost::filesystem::status: Permission denied: "/media/.../Soil_wholegenome/out"

    exit_code: 255
    id: 1

... in the path was just to remove lab information.

The error message says permission denied, however I set the folder with sudo chmod -R 777 out/, so you can see:

drwxrwxr-x 5 ch2 ch2 12288 Aug  4 03:44 basecalled_guppystandalone
drwxrwxrwx 2 ch2 ch2  4096 Aug  8 17:07 out
drwxrwxrwx 5 ch2 ch2  4096 Nov 19  2019 VAC1

Have you done post sequencing basecalling besides live basecalling? Is it more of a minKNOW software issue?

Again, thank you,

Xiaoping

[sirselim]

Hi @lixiaopi1985 - great, it looks like the GPU version of Guppy is happy now and correctly being launched and detected in the background.

What does your minknow.service file look like? You can print it to terminal using:

cat /lib/systemd/system/minknow.service

I'm wondering if it's got the correct permissions set. When you ran sudo chmod -R 777 out/ did you restart the minknow.service? Sometimes that can help. Also those permissions should probably be set at the very root of the directory structure in case MinKNOW is trying to write somewhere higher up.

sudo chmod -R 777 /media/.../*

The above assumes that the "..." is where MinKNOW is writing out all the experiments/data. If not then you'll have to change it to the that dir. Please note: we shouldn't have to manually change these permissions, it's an indication that something not quite right is going on. If it fixes the issue, great! If not we'll have to dig deeper - I have another solution but it's quite ezxperimental, let me know how you get on and we can maybe move to that (I'm running it on a couple of Linux machines and they are working well).

Have you done post sequencing basecalling besides live basecalling? Is it more of a minKNOW software issue?

We do more post-sequencing basecalling than live basecalling. Is there a reason you are wanting to do it in MinKNOW rather than just using Guppy? We call Guppy from the command line for all our re-basecalling/post-basecalling needs.

A typical high accuracy basecalling command for us (depending on what server/GPUs we are using) looks something like this:

guppy_basecaller -c dna_r9.4.1_450bps_hac.cfg -i example_fast5/ -s example_fastq -x 'auto' --recursive --chunks_per_runner XXX

*the XXX above represents an optimised value based on the GPU(s) being used. You can happily remove this argument and run the default settings, or you can try and optimise the --chunks_per_runner command for your compute set up.

Another question: does live sequencing basecalling work for you? If Guppy is having permission issues I'm assuming not...

[lixiaopi1985]

@sirselim Thanks for the reply. The minknow service looks like this:

[Unit]
Description=MinKNOW Instrument Software for MinION (daemon)
Wants=guppyd.service
After=guppyd.service

[Service]
ExecStart=/opt/ont/minknow/bin/mk_manager_svc
WorkingDirectory=/opt/ont/minknow
KillMode=mixed
User=minknow
Group=minknow
SyslogIdentifier=minknow
LogsDirectory=minknow
LimitCORE=infinity
LimitNICE=40
NoNewPrivileges=true
ExecStartPre=/bin/sleep 15

[Install]will have sequencing 
WantedBy=multi-user.target

And I set the permission of the output path to 2 levels up and restarted the minknow service. Still I am getting the permission denied error message for the output path. Is it because the WorkingDirectory=/opt/ont/minknow in the minknow.service?

I have seen in the nanopore community, people have problem on starting experiment, not sure if that is related to this issue.

We do more post-sequencing basecalling than live basecalling. Is there a reason you are wanting to do it in MinKNOW rather than just using Guppy? We call Guppy from the command line for all our re-basecalling/post-basecalling needs.

There are other people in the lab that use minKNOW, but they are not quite commandline savvy so they prefer minKNOW. I need to make sure the basecalling working on minKNOW. Besides, I have samples to sequence so I want to use live basecalling as well.

[sirselim]

@lixiaopi1985

Is it because the WorkingDirectory=/opt/ont/minknow in the minknow.service?

No, don't change that path.

MinKNOW is expecting the folders it's writing to either belong to, or have permissions set for, the user minknow, these two lines:

User=minknow
Group=minknow

It could be worth a try making the folder 'belong' to the minknow user, i.e. sudo chown minknow:minknow /media/.../* - make sure the dir path is correct. Restart MinKNOW service and try again.

[WARNING: the below is experimental. It works for me but I'm not going to accept any liability. :)]

If the above doesn't work we could try and create the guppyd.service that it looks like MinKNOW is expecting (as indicated at the top of you output). You could create a file called guppyd.service with the following contents:

[Unit]
Description=Service to manage the guppy basecall server.
Documentation=https://community.nanoporetech.com/protocols/Guppy-protocol/v/GPB_2003_v1_revQ_14Dec2018

[Service]
Type=simple
ExecStart=/usr/bin/guppy_basecall_server --log_path /var/log/guppy --config dna_r9.4.1_450bps_fast.cfg --port 5555 -x cuda:all 
Restart=always
User=root
MemoryLimit=8G
MemoryHigh=8G
CPUQuota=200%

[Install]
Alias=guppyd.service
WantedBy=multi-user.target

You want to make sure that the path to guppy is correct in the line starting with ExecStart=, i.e. ExecStart=/usr/bin/guppy_basecall_server. The options after this are what you want the basecallier server to be running by default. Assuming you have a GPU you can change the amount of GPU RAM that is available to Guppy as well (this example uses 8GB, just change that to how ever much RAM your card has).

Then move or copy this file to /lib/systemd/system/, so something like:

sudo cp guppyd.service /lib/systemd/system/

You would start this service using:

systemctl start guppyd.service

... and check it using:

systemctl status guppyd.service

Hopefully it looks like it's running OK. Then restart MinKNOW:

systemctl restart minknow.service

Then cross your fingers and try basecalling in MinKNOW again.

I think just changing the folder permissions to the minknow user should be enough, unless there is some other error behind the scenes. But if the guppyd.service doesn't work I think we'll have to go right back to square one, i.e. delete ALL ONT software and start a fresh.

[lixiaopi1985]

@sirselim Changing folder permission and adding guppyd.servce file did not work, still have the permission error. Then I uninstalled and re-installed the minknow-core-minion-nc and other components you suggested to install them manually in the blog. The problem remains.

I noticed that the guppyd.service status showing it had been disabled?

● guppyd.service - Service to manage the guppy basecall server.
   Loaded: loaded (/lib/systemd/system/guppyd.service; disabled; vendor preset: enabled)
   Active: active (running) since Mon 2021-08-09 10:46:06 EDT; 15min ago
     Docs: https://community.nanoporetech.com/protocols/Guppy-protocol/v/GPB_2003_v1_revQ_14Dec2018
 Main PID: 12619 (guppy_basecall_)
    Tasks: 50 (limit: 4915)
   CGroup: /system.slice/guppyd.service
           └─12619 /usr/bin/guppy_basecall_server --log_path /var/log/minknow/guppy --config dna_r9.4.1_450bps_fast.cfg

Aug 09 10:46:06 SE-A-CHHONG2-SCRI guppy_basecall_server[12619]: max returned events: 50000
Aug 09 10:46:06 SE-A-CHHONG2-SCRI guppy_basecall_server[12619]: gpu device:          cuda:all
Aug 09 10:46:06 SE-A-CHHONG2-SCRI guppy_basecall_server[12619]: kernel path:
Aug 09 10:46:06 SE-A-CHHONG2-SCRI guppy_basecall_server[12619]: runners per device:  8
Aug 09 10:46:08 SE-A-CHHONG2-SCRI guppy_basecall_server[12619]: Config loaded:
Aug 09 10:46:08 SE-A-CHHONG2-SCRI guppy_basecall_server[12619]: config file:               /opt/ont/ont-guppy_5.0.11/da
Aug 09 10:46:08 SE-A-CHHONG2-SCRI guppy_basecall_server[12619]: model file:                /opt/ont/ont-guppy_5.0.11/da
Aug 09 10:46:08 SE-A-CHHONG2-SCRI guppy_basecall_server[12619]: model version id           2021-05-17_dna_r9.4.1_minion
Aug 09 10:46:08 SE-A-CHHONG2-SCRI guppy_basecall_server[12619]: adapter scaler model file: None
Aug 09 10:46:08 SE-A-CHHONG2-SCRI guppy_basecall_server[12619]: Starting server on port: 5555

And I also see other people have the same error message. Changing /opt/ont/minknow/conf/user_conf output_directory caused the minknow.service to not start.

---

update: copied some fast5 files and used the default output path /var/lib/minknow/data/ still generated the permission denied error

[sirselim]

@lixiaopi1985 - OK, I'm really struggling now. As a sanity check I wiped a spare laptop and ran through the same procedure that I've documented in my notes. I was able to get up and running with live GPU basecalling without error. So I'm really confused as to where exactly things are going wrong for you.

I have tested on a laptop that was running 20.04, I then wiped and installed 21.04 (for fun) and everything still works A-OK (using the 20.04 repos).

I noticed that the guppyd.service status showing it had been disabled?

The information you have provided about the guppyd.service looks just fine, it's loaded and active (green active (running) is good) - it looks identical to what is running on the machine I am currently typing on. So in my mind that is pointing the finger back at MinKNOW.

update: copied some fast5 files and used the default output path /var/lib/minknow/data/ still generated the permission denied error

That is NOT the default data path, please do not try to change permission or write there! By default the path in user_conf is something like /data. I'm assuming that you have changed that dir and it is that dir that you have been having permission issues with.

If you are happy to share it might be worth while for you to attach the following files:

• user_conf
• app_conf
• minknow.service
• guppyd.service

I'll take a look at them and see if there is anything that I can suggest.

• Miles

[lixiaopi1985]

Hi @sirselim Please see the attached. Thanks a lot for sticking around to help me on the issue. Could it be a problem with the boost library included in the minKNOW installation according the error message?

Is there a cache file used by minKNOW? I noticed that after uninstallation and reinstallation, the UI logged straight in with my account, without even bother asking me for credentials, which struck me weird. Maybe there were some hidden files that I had not purged completely? Another question is, where the minknow.service should be found, /lib/systemd/system/multi-user.target.wants or /etc/systemd/system/multi-user.target? I found the minknow.service in the /etc/.../multi-user.target this path.

nanoporefiles.zip

[sirselim]

Hi @lixiaopi1985 - for some reason that zip file seems incomplete or corrupted. You can actually attach individual files to these posts just by dragging them into the post itself, that might be a good way of doing it?

In terms of a "cache", if you are just un-installing with apt remove or even apt remove --purge then there will be specific dirs and files that are left behind. For instance you'll find that /opt/ont/minknow/ will still be there after removing minknow-nc and all it's dependencies. You can delete these manually - it just means you lose any modified config files etc, which in your case probably isn't a bad thing.

[lixiaopi1985]

@sirselim github does not support the original format, so I gzip each individual file in the attachment. Hope it works this time.

I am aware of that, so each time after uninstallation, I delete those files and folders related to ont, unless there other particular files belonging to ont which I am not aware of. So that's why I think it is weird.

minknow.service.gz user_conf.gz app_conf.gz guppyd.service.gz

[sirselim]

@lixiaopi1985 - OK I can see a few things that may be causing problems.

1. The first thing I note is that the data path provided in user_conf should not be there:

        "output_dirs": {
            "cereal_class_version": 2,
            "base": {
                "value0": "/var/lib/minknow/data/"
            },

Pointing at /var/lib/minknow/data/ is a VERY bad idea (as I mentioned earlier) - this is likely on your root partition, and you most likely don't want to fill that up with sequence data!

This should be something like:

        "output_dirs": {
            "cereal_class_version": 2,
            "base": {
                "value0": "/media/data/minknow/"
            },

Here /media/data/minknow/ is the location you want minknow to write experiments out to. Note that this can be any directory and you will need to change it to what you want, but it should have read/write privileges for the minknow user:

sudo chown minknow:minknow -R /media/data/minknow/

2. The second thing is this section of your app_conf:

            "client_executable": "/opt/ont/ont-guppy_5.0.11/bin/guppy_basecall_client",
            "barcoding_executable": "/opt/ont/ont-guppy_5.0.11/bin/guppy_barcoder",
            "alignment_executable": "/opt/ont/ont-guppy_5.0.11/bin/guppy_aligner",
            "server_executable": "/opt/ont/ont-guppy_5.0.11/bin/guppy_basecall_server",
            "minimap_executable": "/opt/ont/ont-guppy_5.0.11/bin/minimap2",

If you have followed my notes I actually sym link the GPU version of Guppy to /usr/bin, I know people say you don't have to but I have found I don't get any errors when I do this. So if you have your Guppy binaries sym linked it will look like this:

            "client_executable": "/usr/bin/guppy_basecall_client",
            "barcoding_executable": "/usr/bin/guppy_barcoder",
            "alignment_executable": "/usr/bin/guppy_aligner",
            "server_executable": "/usr/bin/guppy_basecall_server",
            "minimap_executable": "/usr/bin/minimap2",

Then that means that you are 100% sure that the same version of Guppy sever is being loaded by guppyd.service, this is what is in yours:

ExecStart=/usr/bin/guppy_basecall_server --log_path /var/log/minknow/guppy --config dna_r9.4.1_450bps_fast.cfg --port 5555 -x cuda:all 

Note the path at: ExecStart=/usr/bin/guppy_basecall_server - this is currently mismatching what you have in your app_conf under the Guppy configuration section.

After amending these things I'd recommend restarting both guppyd.service and minknow.service and then check their status.

If this doesn't work I think you probably need to go back and either follow my notes from the beginning with a fresh install, or try and force minion-nc to install through it's dependencies and then try and point it at the GPU version of Guppy.

[lixiaopi1985]

Hi @sirselim,

Pointing at /var/lib/minknow/data/ is a VERY bad idea (as I mentioned earlier) - this is likely on your root partition, and you most likely don't want to fill that up with sequence data!

This is by default, I did not set it.

So I uninstalled those software and re-installed following your protocol, set the guppy symlink to /usr/bin/ and have the symlink in the app_conf file, restart guppy service and minknow service, still having permission error with the output pointing the the folder that is accessible and has minknow as the group and user.

I would go back and install minion-nc to see if there is any different.

---

update: @sirselim I installed minion-nc, and investigated a bit. Even if with cpu version, the same error showed up to that folder I had set permission to 777 and user/group set to minknow. Does it have to do with the "boost" library?

[lixiaopi1985]

@sirselim So after sudo chmod -R 777 /media/, now I got it running (files now being written out in the output folder I specified in the minKNOW), but the problem is that minKNOW ui does not show the progress or anything in the experiment console. I think that is something I need to contact nanopore about.

Sincerely I appreciate your help along the way! Xiaoping