Category Archives: Errors

RaspberryPi Camera not detected – Ubuntu 20.04.5 LTS

Hi everyone,

I ran into a bit of an issue with a RaspberryPi 4 running Ubuntu 20.04.5 this morning. Running vcgencmd get_camera should have returned supported=1 detected=1 but instead I was getting supported=0 detected=0.

This was a bit of a hard one to track down with Google but I eventually came across a stackoverflow post suggesting the following:

  • Run sudo nano /boot/firmware/config.txt
  • Add start_x=1 at the end
  • Reboot

Check out this post for more info: https://askubuntu.com/a/1244259/770194.

If you’re using a new camera you may also run into this error:

mmal: Cannot read camera info, keeping the defaults for OV5647
mmal: mmal_vc_component_create: failed to create component 'vc.ril.camera' (1:ENOMEM)
mmal: mmal_component_create_core: could not create component 'vc.ril.camera' (1)
mmal: Failed to create camera component
mmal: main: Failed to create camera component
mmal: Only 76M of gpu_mem is configured. Try running "sudo raspi-config" and ensure that "memory_split" has a value of 128 or greater

The fix for this one is to simply append another line to /boot/firmware/config.txt. All you’ll need is gpu_mem=128.

Another issue you might run into is VHCI initialization failed. Generally, that just means you need to add your current user to the video group.

# Check your current user's groups.
groups

# Add your user to the video group.
sudo usermod -aG video <username>

Once you’ve added the group, rebooting should be enough to get past that error.

Spawn entity timeout in Gazebo from Ros2

Hi everyone,

I’m currently following a tutorial to simulate a fairly basic lidar robot with ROS2 and Gazebo: https://www.youtube.com/watch?v=laWn7_cj434. Unfortunately, there have been a few updates since the tutorial was created and a number of the commands don’t map 1:1 (no copy and paste).

While trying to create a launch file I ran into the following error:

[create-3] [ERROR] [1668289712.483268807] [ros_gz_sim]: Request to create entity from service [/world/deafult/create] timed out.

This was the relevant line in the launch file:

# Run the spawner node from the gazebo_ros package. The entity name doesn't really matter if you only have a single robot.
spawn_entity = Node(package='ros_ign_gazebo', executable='create',
arguments=[
'-world', 'deafult',
'-topic', 'robot_description',
'-entity', 'my_bot'],
output='screen')

The issue causing it to hang is that the world doesn’t exist. In my case, it’s because of a typo. However, if you’ve defined a world that you haven’t created yet it will result in the same error.

libgl error pic id driver null – ros2 turtlesim

Hi everyone,

I’m currently following the ros2 turtlesim tutorial with Ubuntu on an M1 Mac with Parallels and Ubuntu. Unfortunately, I hit a ‘device not found’ when trying to start the control node.

A bit of Googling revealed that 3D acceleration might not be enabled. To fix this, all you need to do is the following:

  • Open settings in Parallels (the cog icon)
  • Click the Hardware tab up the top
  • Click Graphics on the left hand side
  • Click Advanced
  • Tick Enable 3D Acceleration

You’ll need to restart the VM, but once that’s done the libgl error should be resolved!

If this doesn’t work, there are a few other things you can check. First, double check that you’ve installed (or re-installed) Parallels Tools.

I have also found that the 3D Acceleration seems to randomly break or reset itself. If it hasn’t automatically unchecked itself, I’ve occasionally had to do the following to get it working again:

  • Stop the VM
  • Disable 3D Acceleration
  • Start the VM
  • Stop the VM
  • Enable 3D Acceleration
  • Start the VM

Another options mentioned in this thread is to set the following environment variable before starting rviz or gazebo:

export LIBGL_ALWAYS_SOFTWARE=1 

Errors pushing an image to a new ECR repo on AWS

Hey everyone,

I normally use DigitalOcean or Azure for docker and kubernetes but have decided to give AWS a go this time around. I was following a guide on deploying an image to a new ECR repo and hit a couple of issues.

The first was that running the login command output help options instead of the password I was expecting:

aws ecr get-login --no-include-email --region us-east-2

usage: aws [options] <command> <subcommand> [<subcommand> ...] [parameters]
To see help text, you can run:

  aws help
  aws <command> help
  aws <command> <subcommand> help

aws: error: argument operation: Invalid choice, valid choices are:

batch-check-layer-availability           | batch-delete-image                      
batch-get-image                          | batch-get-repository-scanning-configuration
complete-layer-upload                    | create-pull-through-cache-rule          
create-repository                        | delete-lifecycle-policy                 
delete-pull-through-cache-rule           | delete-registry-policy                  
delete-repository                        | delete-repository-policy                
describe-image-replication-status        | describe-image-scan-findings            
describe-images                          | describe-pull-through-cache-rules       
...

This turned out to be an issue because the command had been deprecated. Instead, use the following:

aws ecr get-login-password | docker login --username AWS --password-stdin "$(aws sts get-caller-identity --query Account --output text).dkr.ecr.<REGION_ID>.amazonaws.com"

There’s a pretty detailed thread on github here: https://github.com/aws/aws-cli/issues/5014

The second issue I ran into was an error while trying to run the new command:

An error occurred (AccessDeniedException) when calling the GetAuthorizationToken operation: User: arn:aws:iam::<ACCOUNT_ID>:user/<USER> is not authorized to perform: ecr:GetAuthorizationToken on resource: * because no identity-based policy allows the ecr:GetAuthorizationToken action

Adding the following role to my user resolved the issue: AmazonEC2ContainerRegistryPowerUser

Once I was passed this, I hit another issue using the command from the github link above:

Error response from daemon: login attempt to https://<ACCOUNT_ID>.dkr.ecr.us-east-2.amazonaws.com/v2/ failed with status: 400 Bad Request

This took a bit of digging, but eventually I came across a thread where someone was using the same command and had hit the same issue. Adding the region to the get-login-password call seemed to fix it:

aws ecr get-login-password --region <REGION_ID> | docker login --username AWS --password-stdin "$(aws sts get-caller-identity --query Account --output text).dkr.ecr.<REGION_ID>.amazonaws.com"

I was finally getting a login succeeded message and my push was working. This was the thread mentioning the region id just in case you need a bit more info: https://github.com/aws/aws-cli/issues/5317#issuecomment-835645395

Console.log output not appearing – AWS SAM Node.js

Hi everyone,

I ran into a bit of an interesting issue today after updating AWS SAM. All of my node log output stopped appearing in my console locally.

For now, there’s a pretty simple workaround:

sam build --use-container && sam local start-api 2>&1 | tr "\r" "\n"

Append 2>&1 | tr “\r” “\n” (including quotes) to your start-api command and you should begin to see the output as expected:

Thanks to the following links for the info:

CREATE_IN_PROGRESS when creating a certificate with CloudFormation

Hi everyone,

I ran into a bit of an issue today while creating a certificate with CloudFormation. After kicking the stack off it ended up hanging on a step to create a domain verification entry in Route 53.

I had used this script multiple times for creating a certificate for a subdomain, but this time I included an apex domain as well. In order to narrow things down a little further I checked out the certificate via the console:

While the subdomain had passed the apex domain was still sitting in pending. Surprisingly, in Route53 the record DID exist. In order to get things moving again I manually deleted the record and then clicked “Create records in Route 53”.

This re-created the record I’d just deleted, and after a couple of minutes the domain validation passed and then the certificate was created:

This was a bit of a weird one that I have been unable to reproduce. I’m not certain why the DNS validation ended up hanging but retriggering the process seems to have resolved it.

Note that there are other legitimate reasons why your deployment might be hanging at this step:

When you use the AWS::CertificateManager::Certificate resource in a CloudFormation stack, domain validation is handled automatically if all three of the following are true: The certificate domain is hosted in Amazon Route 53, the domain resides in your AWS account, and you are using DNS validation.

However, if the certificate uses email validation, or if the domain is not hosted in Route 53, then the stack will remain in the CREATE_IN_PROGRESS state. Further stack operations are delayed until you validate the certificate request, either by acting upon the instructions in the validation email, or by adding a CNAME record to your DNS configuration. For more information, see Option 1: DNS Validation and Option 2: Email Validation.

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-certificatemanager-certificate.html

No matches for kind “Deployment” in version “apps/v1beta2” – DigitalOcean

Hey everyone,

I’ve been working on a small golang app and decided to try out Kubernetes on DigitalOcean instead of the usual Azure or AWS. In order to get started I followed the tutorial at this link: https://www.digitalocean.com/community/tutorials/webinar-series-a-closer-look-at-kubernetes

I ran into a small issue while trying to using the provided deployment.yaml.

error: unable to recognize "./api/deploy/prod/deployment.yaml": no matches for kind "Deployment" in version "apps/v1beta2"

This turned out to be an issue with the apiVersion being used. Changing the first line to apps/v1 resolved it:

apiVersion: apps/v1beta2
kind: Deployment
metadata:

apiVersion: apps/v1
kind: Deployment
metadata:

Thanks to this link on github for pointing me in the right direction: https://github.com/coreos/etcd-operator/issues/2126

Support for password authentication was removed on August 13, 2021. Please use a personal access token instead – Fix for Mac

Hey everyone,

If you’re like me and a bit slack with your personal projects you might’ve started receiving the following error today:

admin@Admins-iMac ui % git push
remote: Support for password authentication was removed on August 13, 2021. Please use a personal access token instead.
remote: Please see https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/ for more information.
fatal: unable to access 'https://github.com/Buzzology/referrer.git/': The requested URL returned error: 403

As the message says, Github wants you to start using a Personal Access Token (PAT) instead of password authentication. Luckily, the fix is pretty straight forward – you’ll need to create a Personal Access Token and then update your keychain.

Step #1: Create a Personal Access Token (PAT)

To create the personal access token, login to Github and go to the following page: https://github.com/settings/tokens

You can also get to this page via the following:

  1. Click on your profile dropdown
  2. Click settings
  3. Click Develop Settings (on the left)
  4. Click Personal access tokens (on the left)

Once you’re on the Personal Access Tokens page you should see something like the following:

Click the Generate new token button, set an expiry and then copy the generated value (you’ll need it in the next step).

Step #2: Updating your keychain

Now that you’ve got your Personal Access Token you need to replace the password that you’ve currently got stored in your keychain. To start, open search and bring up Keychain Access:

If you’ve got quite a few keys there you can filter them by searching for github. You’ll then need to double click on each of the entries and replace the stored password with your personal access token:

Note that you’ll first need to click Show Password.

Now that your keychain is updated, close and then re-open any of your terminals and you should be good to go.

admin@Admins-iMac ui % git push
Enumerating objects: 110, done.
Counting objects: 100% (110/110), done.
Delta compression using up to 4 threads
Compressing objects: 100% (91/91), done.
Writing objects: 100% (93/93), 15.30 KiB | 2.19 MiB/s, done.
Total 93 (delta 64), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (64/64), completed with 14 local objects.
To https://github.com/Buzzology/referrer.git
   0d2ecf0..97f2716  master -> master
admin@Admins-iMac ui % 

Thanks to the following Stackoverflow post for the additional info: https://stackoverflow.com/a/67650257/522859

Goland Unable to Resolve Directory – Modules not loading (Mac)

Hi everyone,

I’m trying out Goland on an old Mac and hit a bit of an issue where it was unable to resolve most of my modules. The weird thing was that if I ran the project from a terminal it was fine so this seemed to rule out any path issues.

This ended up being a few IDE settings – double check the following:

  • Click “Goland” in the top left
  • Click “Preferences”
  • Expand “Go” in the sidebar
  • Click “Go Modules”
    • Check “Enable Go modules integration”
  • Click “GO PATH” in the sidebar
    • Ensure that there are zero entries under the “Project GOPATH” and “Module GOPATH” headings
    • Ensure that “Use GOPATH that’s defined in system environment” is checked
    • Ensure that “Index entire GOPATH” is checked
  • Click “Apply” and “OK”

You may need to wait a short while for that indexing to refresh. If it doesn’t look like it’s doing anything run “go mod download” from your terminal. If it’s still broken restarting Goland seems to fix it up sometimes as well.

“‘protoc-gen-go’ is not recognized as an internal or external command” – Go

Hi everyone,

I’m currently looking into Go and have hit the following error while trying to run proto:

`protoc-gen-go` is not recognized as an internal or external command

I am using Windows and have installed the required libraries:

go get -u github.com/golang/protobuf/proto
go get -u github.com/golang/protobuf/protoc-gen-go

In my case the issue turned out to be that proto-gen hadn’t been added to my path: E:\repos\gocode\bin

Note that the new path won’t be available until you restart your terminal.

A subsequent error I encountered was the following:

'protoc-gen-go-grpc' is not recognized as an internal or external command,
operable program or batch file.

I just had to run the following to resolve it:

go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest