Error with latest Ansible pull (2020-01-21 18:17:18)

SatNOGS Software
1

Running on a RasPi 3b, from the 2019091100 tag image.
Did an update a few days ago to correct the PyPi/settuptools issue, and everything was working fine after that update. No errors from running the satnogs-config, or any config changes (i.e. rtlsdr RF gain, etc…)

Did another update today: (missed the actual output, but results after doing it a second time are shown below so you can see the git hash it found and is currently using)

Starting Ansible Pull at 2020-01-21 18:17:18
/usr/bin/ansible-pull -d /root/.satnogs/ansible -U librespacefoundation / SatNOGS / satnogs-ansible · GitLab -C stable -t satnogs-setup
[WARNING]: Could not match supplied host pattern, ignoring: satnogspi
localhost | SUCCESS => {
“after”: “356bab724444f6c128f254478a091fc12f4d86cf”,
“before”: “356bab724444f6c128f254478a091fc12f4d86cf”,
“changed”: false,
“remote_url_changed”: false
}
[WARNING]: Could not match supplied host pattern, ignoring: satnogspi
Executing playbook local.yml

  • localhost on hosts: localhost -
    Gathering Facts…

and that completed fine. It found an update (different hash #) and pulled things down. The above was just having done it a second time because I missed capturing the output earlier.

After the update, I tried to the configuration (using the satnogs-setup) and eventually got to this error (in red):

Unload SDR modules…
An exception occurred during task execution. To see the full traceback, use -vvv. The error was: IOError: [Errno 2] No such file or directory: ‘/lib/modules/4.19.75-v7+/modules.builtin’
localhost failed | msg: [Errno 2] No such file or directory: ‘/lib/modules/4.19.75-v7+/modules.builtin’
localhost failed

first time I’ve seen this error.
Upon inspecting the /lib/modules folder I see this:

satnogspi :: ~ » ls /lib/modules
4.19.93+ 4.19.93-v7+ 4.19.93-v7l+ 4.19.93-v8+
satnogspi :: ~ »

so obviously it’s bombing expecting a 4.19.75-v7+ folder, and everything in there is more current. Not even sure WHY it thinks that modules folder would be there… hard coded path ?? cached modules history ??

the problem is it doesn’t complete the so exiting the (satnogs-setup) squawks an error about not applying or saving… which is gonna be a little weird for some folks who don’t know how to troubleshoot whether the client is actually running.

doing a systemctl status query on the satnogs.service shows it running fine, but just for good measure I restarted it manually, and the client is operating “normally” after scheduling a few obs. I still have issues with the quality of the obs, but that’s a separate issue :wink:

Do you need more info to pin this down?
and where in all of the GitLab git repo should I report this ?

Thanks !

-frank

2 Likes
2

What kernel are you running? Did you reboot after update? I’m not sure if it helps but here’s what I have:

pi@cruftpi1:~ $ dpkg -S /lib/modules/4.19.75-v7+/modules.builtin
raspberrypi-kernel: /lib/modules/4.19.75-v7+/modules.builtin
3

If your problem isn’t resolved here, open an issue at this repo:

1 Like
4

So, kicking myself for not noticing the version # and tying it back to the kernel. ;-(

I had done an apt update/upgrade 'cause this is still a testing Pi and I don’t worry so much about freezing on a kernel version.

Kernel 4.19.93-v7+ was pushed in that update, and I let it happen.

I did NOT reboot afterwards, so a uname -a would have shown kernel: 4.19.75-v7+

instead, I simply ran sudo satnogs-setup after updating and tried an update…

the rest, as they say, is history. It was running in 4.19.75 context, went looking for lib modules where it expected to find them, and they were gone.

sooooooo, (short answer for the rest who read this)
rebooted, re-ran sudo satnogs-update, hit and everything worked. Client application, meet the idiot who fools with the OS, and end up doing it half-a**'ed!

an interesting condition I suppose. Best advice I can pass onto others is TO ALWAYS REBOOT after you notice a kernel update… 'cause… reasons.

I suppose you could also bounce the Pi after every apt upgrade (if you do it manually), but at that point I suppose there’s something to be said for the following:

“if you’re doing apt changes manually, you’re expected to know what the repercussions are for doing so”

so it was an interesting error, largely my fault, and “mysteriously resolved” like so many things, by a reboot. :wink:

Thx @jebba and @fredy for replying.

Cheers,

-lucky

2 Likes
5

Glad you got it going!

1 Like