Hardware: Haicom 206 USB gps dongle, by Prolific Technologies. Worked perfectly under M7 Now: gpsd started at boot the user had dialout ticked in groups (required) gpsctl reports ERROR: no device connectecd. lsusb shows B001: Device 006 (or whatever its device number is), ID 067b:2303 Prolific Technology, Inc PL2303 Serial Port It doesn't help to call gpsctl with the device: gpsctl /dev/ttyUSB0 still fails in the same way. Doesn't help running gpsctl as root. I _think_ this was working earlier in the M8 testing - can't say at what point - its not working with a machine still running cauldron, kernel 5.8.11 and not working on 3 other machines running 5.10.20 This is completely reproducible across 3 different laptops and my main desktop. M7 gpsd either still works or has worked on all of them. Need this to work - for street navigation and particularly for boating, where OpenCPN is our main navigation package.
can you disconnect the gps dongle, reboot to get a "clean boot state" and after the system is booted, plug in the dongle. then grab output of dmesg with: dmesg >dmesg.txt and attach that dmesg.txt to this report
Created attachment 12567 [details] output dmesg in response to comment 1. The gps dongle is seen: 54.914537] usb 1-6: Manufacturer: Prolific Technology Inc. Nothing much else seems to have happened. Tony
Actually my comment above is not doing it justice. Relevant adjacent entries: 54.787800] usb 1-6: new full-speed USB device number 5 using xhci_hcd [ 54.914524] usb 1-6: New USB device found, idVendor=067b, idProduct=2303, bcdDevice= 4.00 [ 54.914531] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 54.914535] usb 1-6: Product: USB-Serial Controller D [ 54.914537] usb 1-6: Manufacturer: Prolific Technology Inc. [ 54.953396] usbcore: registered new interface driver usbserial_generic [ 54.953401] usbserial: USB Serial support registered for generic [ 54.954882] usbcore: registered new interface driver pl2303 [ 54.954890] usbserial: USB Serial support registered for pl2303 [ 54.954906] pl2303 1-6:1.0: pl2303 converter detected [ 54.955550] usb 1-6: pl2303 converter now attached to ttyUSB0 On the face of it, the device should be working. but gpsctl not seeing it same as before. - Its not a defective device - I in fect have 3 of them, all working M7 failing on M8. The device is powered: slowly flashing red light under it. I'll power one up and check light is the same on M7, but expect so. Appreciate the early interest in this issue. Regards, Tony [
thanks, I wanted the dmesg first to see if we get some warnings from kernel side first... Do you get output with: gpsd -ND5 /dev/ttyUSB0
[root@tony-m2 tony]# gpsd -ND5 /dev/ttyUSB0 gpsd:INFO: launching (Version 3.21) gpsd:IO: opening IPv4 socket gpsd:ERROR: can't bind to IPv4 port gpsd, Address already in use gpsd:ERROR: maybe gpsd is already running! gpsd:IO: opening IPv6 socket gpsd:ERROR: can't bind to IPv6 port gpsd, Address already in use gpsd:ERROR: maybe gpsd is already running! gpsd:ERROR: command sockets creation failed, netlib errors -1, -1
ah, please stop the already running gpsd
tried just stopping it - same output.]Unticked it in system services so as not to start at boot, then: [root@tony-m2 tony]# gpsd -ND5 /dev/ttyUSB0 gpsd:INFO: launching (Version 3.21) gpsd:IO: opening IPv4 socket gpsd:ERROR: can't bind to IPv4 port gpsd, Address already in use gpsd:ERROR: maybe gpsd is already running! gpsd:IO: opening IPv6 socket gpsd:ERROR: can't bind to IPv6 port gpsd, Address already in use gpsd:ERROR: maybe gpsd is already running! gpsd:ERROR: command sockets creation failed, netlib errors -1, -1 [root@tony-m2 tony]# ps -ef|grep gpsd root 3537 3225 0 20:26 pts/0 00:00:00 grep --color gpsd i.e essentially the same, although gpsd is not running
(that was after re-boot)
So perhaps the question is what else is binding to the port if gpsd isn't? Is something else preventing it?
please install lsof and check lsof /dev/ttyUSB0 what does it say ?
Not sure how to show any such process: # ls -al /dev/ttyUSB0 crw-rw---- 1 root dialout 188, 0 Apr 4 20:25 /dev/ttyUSB0 [root@tony-m2 tony]# lsof /dev/ttyUSB0 (no output)
comments collision
Have you changed any config on the mga7 systems ? compare the: /etc/sysconfig/gpsd /usr/lib/systemd/system/gpsd*
# ps -ef|grep gpsd nobody 5775 1 0 20:48 ? 00:00:00 /usr/sbin/gpsd root 5968 3225 0 20:50 pts/0 00:00:00 grep --color gpsd cd /proc/5775 [root@tony-m2 5775]# ls arch_status cwd@ maps pagemap stack attr/ environ mem patch_state stat autogroup exe@ mountinfo personality statm auxv fd/ mounts projid_map status cgroup fdinfo/ mountstats root@ syscall clear_refs gid_map net/ sched task/ cmdline io ns/ schedstat timens_offsets comm latency numa_maps sessionid timers coredump_filter limits oom_adj setgroups timerslack_ns cpu_resctrl_groups loginuid oom_score smaps uid_map cpuset map_files/ oom_score_adj smaps_rollup wchan
... and that was after I restarted gpsd (sorry about another commebnt collision) I'll check M7 now
in both M7 and M8 /etc/sysconfig/gpsd are identical, with OPTIOMS="" and USBAUTO="true" (just emailing myself the long output from /usr/lib/systemd/system/gpsd on M7)
Created attachment 12568 [details] m7 /usr/lib/systemd/system/gpsd* attaching /usr/lib/systemd/system/gpsd for each of M7 and M8
Created attachment 12569 [details] M8 /usr/lib/systemd/system/gpsd* M8 /usr/lib/systemd/system/gpsd*
Ha, does it mena anything that diff shows < Environment="GPSD_SOCKET=/var/run/gpsd.sock" --- > Environment="GPSD_SOCKET=/run/gpsd.sock" and < ListenStream=/var/run/gpsd.sock --- > ListenStream=/run/gpsd.sock
Is your userid a member of the dialout group?
CC: (none) => davidwhodgins
Yes, my userid is a member of the dialout group - see my intro. (and even if I'd erred there, wouldn't running gpsctl as root bypass this in terms of root finding the device?? It didn't)
Appreciate the time and attention you've put into this Dave. 10.20pm here in Brisbane, Aust - I'm for the cot...
Just looking at it from the point of view of what might be different. Please provide the output of ls -l /|grep run ls -l /var|grep run grep run /proc/mounts on both systems.
(In reply to Tony Blackwell from comment #19) > Ha, does it mena anything that diff shows > < Environment="GPSD_SOCKET=/var/run/gpsd.sock" > --- > > Environment="GPSD_SOCKET=/run/gpsd.sock" > > and > > < ListenStream=/var/run/gpsd.sock > --- > > ListenStream=/run/gpsd.sock not an issue... we used to have lots of bits pointing at the compat /var/run/ symlink (its symlinked to /run), but for mga8 we have cleaned it all (atleast most of it) to use the real tmpfs mounted on /run
Well, this is in most competent hands, so leaving it with BugSquad. (In reply to Tony Blackwell from comment #9) > So perhaps the question is what else is binding to the port if gpsd isn't? > Is something else preventing it? Re comments 5 & 7; this looks an obvious question. TCP port 2947 apparently. Others will be able to suggest what commands to interrogate this possibility (sorry, I do not know). dmesg shows no sign of either gpsd or that port no.
Source RPM: (none) => gpsd-3.21-2.mga8.src.rpmCC: (none) => lewyssmith
M7: (the working gps system) ls -l/|grep run drwxr-xr-x 39 root root 1260 Apr 5 03:22 run/ M8 # ls -l /|grep run drwxr-xr-x 47 root root 1340 Apr 5 10:10 run/ M7 # ls -l /var|grep run lrwxrwxrwx 1 root root 11 Sep 24 2018 lock -> ../run/lock/ lrwxrwxrwx 1 root root 6 Sep 24 2018 run -> ../run/ M8 # ls -l /var|grep run lrwxrwxrwx 1 root root 11 Jul 31 2020 lock -> ../run/lock/ lrwxrwxrwx 1 root root 6 Jul 31 2020 run -> ../run/ As an aside, given that gpsd uses port 2947 by default: M8 # netstat -lntp|grep 2947 tcp 0 0 127.0.0.1:2947 0.0.0.0:* LISTEN 1/init tcp6 0 0 ::1:2947 :::* LISTEN 1/init (output of same netstat command on M7 is identical)
Perhaps futilely, given something else is apparently blocking gpsd's port, I tried copying M7 gpsd in place of M8's (i.e substituting M8 v 3.21 with M7 3.18.1). It still ran, but with the identical error in the M8 environment. Tony
Assigning to Kernel and Drivers maintainers.
Assignee: bugsquad => kernelCC: (none) => ouaurelien
CC: lewyssmith => (none)
Hmmm, anyone had a chance to look at this? It's critical for me - I'm about to downgrade some installations to M7 just to get it working again, for opencpn boating mapping. Tony
Just updated an M7 laptop installation to latest packages and normal gpsd functionality is preserved in the M7 environment. M8 remains non-functional with the GPS dongle not dete3cdted. Tony
what does: lsof -i:2947 say?
looking at this again because of: https://bugs.mageia.org/show_bug.cgi?id=29322 seems foxtrotgps, viking, marble, merkaartor, navit, plasma-workspace all hooks into gpsd libs, so if any of those activates gps bits, they might/will block gpsd ports if you dont have foxtrotgps, viking, marble, merkaartor, navit running, then maybe there is somewhere in plasma settings to disable usage of gps by default.
I just bought a gps usb-connected dongle and, also not achieving functionality in MGA8. I can see it in lsusb when connected. Bus 003 Device 009: ID 1546:01a7 U-Blox AG [u-blox 7] Different from what is reported here, I find the device to be ttyACM1. Maybe something of this, starting with dongle connected, is useful: $ ll /dev/ttyACM* crw-rw---- 1 root dialout 166, 0 Aug 6 05:36 /dev/ttyACM0 crw-rw---- 1 root dialout 166, 1 Aug 6 05:36 /dev/ttyACM1 $ sudo journalctl -f -- Logs begin at Wed 2021-05-26 17:11:53 PDT. -- Aug 06 08:09:38 x570i kernel: ll header: 00000000: ff ff ff ff ff ff d4 5d 64 51 25 e0 08 00 ... *disconnect dongle around here, somewhere* ... Aug 06 08:10:38 x570i kernel: IPv4: martian source 192.168.1.255 from 192.168.1.217, on dev wlp3s0 Aug 06 08:10:38 x570i kernel: ll header: 00000000: ff ff ff ff ff ff d4 5d 64 51 25 e0 08 00 Aug 06 08:11:33 x570i kernel: usb 3-2: USB disconnect, device number 3 Aug 06 08:11:33 x570i systemd[1]: Stopping Manage ttyACM1 for GPS daemon... Aug 06 08:11:33 x570i sh[691211]: /bin/sh: line 1: /usr/local/sbin/gpsdctl: No such file or directory Aug 06 08:11:33 x570i systemd[1]: gpsdctl@ttyACM1.service: Succeeded. Aug 06 08:11:33 x570i systemd[1]: Stopped Manage ttyACM1 for GPS daemon. Aug 06 08:11:33 x570i kernel: IPv4: martian source 255.255.255.255 from 192.168.1.217, on dev wlp3s0 Aug 06 08:11:33 x570i kernel: ll header: 00000000: ff ff ff ff ff ff d4 5d 64 51 25 e0 08 00 Aug 06 08:11:38 x570i kernel: IPv4: martian source 255.255.255.255 from 192.168.1.217, on dev wlp3s0 Aug 06 08:11:38 x570i kernel: IPv4: martian source 192.168.1.255 from 192.168.1.217, on dev wlp3s0 Aug 06 08:11:38 x570i kernel: ll header: 00000000: ff ff ff ff ff ff d4 5d 64 51 25 e0 08 00 Aug 06 08:11:38 x570i kernel: ll header: 00000000: ff ff ff ff ff ff d4 5d 64 51 25 e0 08 00 ^C $ ll /dev/ttyACM* crw-rw---- 1 root dialout 166, 0 Aug 6 05:36 /dev/ttyACM0 $ sudo journalctl -f -- Logs begin at Wed 2021-05-26 17:11:53 PDT. -- Aug 06 08:11:38 x570i kernel: ll header: 00000000: ff ff ff ff ff ff d4 5d 64 51 25 e0 08 00 Aug 06 08:11:38 x570i kernel: ll header: 00000000: ff ff ff ff ff ff d4 5d 64 51 25 e0 08 00 ... *plug dongle around here* ... Aug 06 08:12:38 x570i kernel: ll header: 00000000: ff ff ff ff ff ff d4 5d 64 51 25 e0 08 00 Aug 06 08:12:54 x570i kernel: usb 3-2: new full-speed USB device number 9 using xhci_hcd Aug 06 08:12:54 x570i kernel: usb 3-2: New USB device found, idVendor=1546, idProduct=01a7, bcdDevice= 1.00 Aug 06 08:12:54 x570i kernel: usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Aug 06 08:12:54 x570i kernel: usb 3-2: Product: u-blox 7 - GPS/GNSS Receiver Aug 06 08:12:54 x570i kernel: usb 3-2: Manufacturer: u-blox AG - www.u-blox.com Aug 06 08:12:54 x570i kernel: cdc_acm 3-2:1.0: ttyACM1: USB ACM device Aug 06 08:12:55 x570i systemd[1]: Starting Manage ttyACM1 for GPS daemon... Aug 06 08:12:55 x570i sh[691944]: /bin/sh: line 1: /usr/local/sbin/gpsdctl: No such file or directory Aug 06 08:12:55 x570i systemd[1]: Finished Manage ttyACM1 for GPS daemon. Aug 06 08:12:55 x570i kernel: IPv4: martian source 255.255.255.255 from 192.168.1.217, on dev wlp3s0 Aug 06 08:12:55 x570i kernel: ll header: 00000000: ff ff ff ff ff ff d4 5d 64 51 25 e0 08 00 ^C $ gpsctl gpsctl:ERROR: no devices connected. $ ll /dev/ttyACM* crw-rw---- 1 root dialout 166, 0 Aug 6 05:36 /dev/ttyACM0 crw-rw---- 1 root dialout 166, 1 Aug 6 08:12 /dev/ttyACM1 $ groups rolf root lp wheel usb dialout vboxsf vboxusers kvm scanner I *guess* this is valid syntax: $ ps aux | grep -E 'foxtrotgps|viking|marble|merkaartor|navit' rolf 700153 0.0 0.0 19876 764 pts/1 S+ 08:32 0:00 grep --color -E foxtrotgps|viking|marble|merkaartor|navit Thanks.
CC: (none) => rolfpedersen
(In reply to Rolf Pedersen from comment #33) > Aug 06 08:12:55 x570i sh[691944]: /bin/sh: line 1: /usr/local/sbin/gpsdctl: > No such file or directory ok, this looks fishy.. if this is called by our package then there is a bug, as it should not search for /usr/local... /me goes digging...
Hi, I have foxtrotgps installed but not running at the same time (navigating per sea and navigating per land tend to be mutually exclusive and requiring different conveyances :-) ) Normally Mageia (7) handles switching from one to the other immediately, assuming that you exit one before starting the other. I'm using xfce, not plasma. xfce has provided uneventful use of opencpn and foxtrotgps until the advent of this issue with M8. I've had to downgrade some systems to M7 to use gpsd... OT, note https://lwn.net/Articles/865044/#Comments (subscriber only for a week) Quoting from the publically available lwn blurb: "GPS satellites also provide highly accurate time information that GPSD can extract for use by Network Time Protocol (NTP) servers. A bug in the GPSD code will cause time to go backward in October, though, which may well cause some havoc if affected NTP servers do not get an update before then." This affects versions of GPSD 3.20 - 3.22 which is all of the releases since last day of 2019. Version 3.23 expected on August 4th fixes it. (our current version is 3.21) This gpsd bug affects NTP servers which un-patched will from 24th October 2021 report the date as March 2002 but seems unlikely to be related to this current M8 bug.
red face - should have read Thomas's link before my OT comment - I see already in hand...
Created attachment 12893 [details] xgps shows some functionality (In reply to Thomas Backlund from comment #34) > (In reply to Rolf Pedersen from comment #33) > > > Aug 06 08:12:55 x570i sh[691944]: /bin/sh: line 1: /usr/local/sbin/gpsdctl: > > No such file or directory > > > ok, this looks fishy.. if this is called by our package then there is a bug, > as it should not search for /usr/local... > > /me goes digging... [rolf@x570i ~]$ sudo ln -s /usr/sbin/gpsdctl /usr/local/sbin/gpsdctl *reboot* [rolf@x570i ~]$ gpsctl /dev/ttyACM1 identified as a NMEA0183 at 9600 baud. Simply making the link and running gpsctl returned gpsctl:ERROR: no devices connected. After reboot, the device is discovered. Although I don't know how to interpret xgps display, the attachment shows activity where before it gave no response.
yeah, gpsd 3.21 in mageia 8 is broken due to hardcoded /usr/local in various places. It will be fixed with the 3.23 update that I'm working on
Depends on: (none) => 29322
Thankyou. Much obliged.
gpsd 3.23 is now in Mga8 Core Updates Testing the whole update is being tracked in bug 29322
@Tony, does the 3.23 in testing work for you ?
Not seeing it yet (using Princeton USA mirror)
http://mirror.math.princeton.edu/pub/mageia/distrib/8/x86_64/media/core/updates_testing/gpsd-3.23-1.mga8.x86_64.rpm http://mirror.math.princeton.edu/pub/mageia/distrib/8/x86_64/media/core/updates_testing/gpsd-clients-3.23-1.mga8.x86_64.rpm http://mirror.math.princeton.edu/pub/mageia/distrib/8/x86_64/media/core/updates_testing/lib64gpsd-devel-3.23-1.mga8.x86_64.rpm http://mirror.math.princeton.edu/pub/mageia/distrib/8/x86_64/media/core/updates_testing/lib64gpsd29-3.23-1.mga8.x86_64.rpm http://mirror.math.princeton.edu/pub/mageia/distrib/8/x86_64/media/core/updates_testing/lib64gpsdpacket29-3.23-1.mga8.x86_64.rpm are all there currently.
I missed some of the rpm packages ... $ urpmf --sourcerpm --media "Core Updates Testing" gpsd gpsd:gpsd-3.23-1.mga8.src.rpm lib64gpsdpacket29:gpsd-3.23-1.mga8.src.rpm lib64Qgpsmm29:gpsd-3.23-1.mga8.src.rpm lib64gpsd29:gpsd-3.23-1.mga8.src.rpm lib64gpsd-devel:gpsd-3.23-1.mga8.src.rpm gpsd-clients:gpsd-3.23-1.mga8.src.rpm python3-gpsd:gpsd-3.23-1.mga8.src.rpm $ urpmf --sourcerpm --media "Core 32bit Updates Testing" gpsd gpsd-clients:gpsd-3.23-1.mga8.src.rpm libgpsd29:gpsd-3.23-1.mga8.src.rpm libQgpsmm29:gpsd-3.23-1.mga8.src.rpm libgpsd-devel:gpsd-3.23-1.mga8.src.rpm libgpsdpacket29:gpsd-3.23-1.mga8.src.rpm python3-gpsd:gpsd-3.23-1.mga8.src.rpm gpsd:gpsd-3.23-1.mga8.src.rpm
Hmm, I seem to need some basic hand-holding here. 1. Why, with Core Updates Testing enabled in MCC, do I not see any of these files, despite urpmf listing them all as per Comment 44 2. attempting: # urpmi --media "Core Updates Testing" gpsd-3.23-1.mga8.x86_64 returns No package named gpsd-3.23-1.mga8.x86_64 Is there a urpmi command that will get gpsd 3.23 with all dependencies from within M8?
try to update media first. urpmi.update "Core Updates Testing"
Qualified success - we're partly/substantially there: I installed everything re gpsd ver 3.23. gpsctl initially reported an error: timeout waiting for port (never seen this before - usually it just finds it).. When called as gpsctl /dev/ttyUSB0 however it found the device, and FoxtrotGPS finds its output and uses it normally. openCPN however has problems I've never seen. it opens a tiny popup window asking for a yes/no response to starting in Safe Mode - but regardless of option chosen, its full window blinks immediately out of existence. I deleted .opencpn directory and rebooted - didn't help. When called from command line, I get: $ opencpn ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side ALSA lib pcm_route.c:877:(find_matching_chmap) Found no matching channel map ALSA lib pcm_oss.c:377:(_snd_pcm_oss_open) Unknown field port ALSA lib pcm_oss.c:377:(_snd_pcm_oss_open) Unknown field port ALSA lib pcm_usb_stream.c:486:(_snd_pcm_usb_stream_open) Invalid type for card ALSA lib pcm_usb_stream.c:486:(_snd_pcm_usb_stream_open) Invalid type for card Cannot connect to server socket err = No such file or directory Cannot connect to server request channel jack server is not running or cannot be started JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock At this point it asks the Start in Safe Mode question. Following my response, I then get: (opencpn:5730): Gdk-ERROR **: 20:15:30.666: The program 'opencpn' received an X Window System error. This probably reflects a bug in the program. The error was 'BadDrawable (invalid Pixmap or Window parameter)'. (Details: serial 13235 error_code 9 request_code 155 (unknown) minor_code 4) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the GDK_SYNCHRONIZE environment variable to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Trace/breakpoint trap (core dumped) [tony@tony-m2 ~]$ So openCPN not functional yet. Can someone see their way through this? Truly appreciate the work being put into this. With thanks, Tony
@Tony, can you reboot and try again as it seems to fix some issues. Also, are you using opencpn from release, or the update that is currently in testing ?
Created attachment 12899 [details] gtk errors in opencpn 5.2.4 release 2.2.mga8
OK, installed opencpn5.2.4 release 2.2.mga8 from Testing. Within opencpn configured Charts and configured the GPS dongle in Connections. Now problem essentially fixed, although a lot of gtk errors show up in command line if called from there. I'd appreciate any thoughts on fixing these, but essentially the bug report is resolved otherwise. Much obliged.
There is one remaining wrinkle worth fixing while this issue is current. Neither opencpn or foxtrotgps seem to find the gps data stream on initial boot, but if gpsctl is called from the command line, the instant gpsctl finds the gps device, then foxtrotgps or opencpn, open at the time, suddenly gets data input from the device. This wasn't prior behaviour. Any ideas?
is the gpsd service enabled ?
Yes, gpsd start on boot is enabled and it is running. I found that same curious behaviour, (needing to manually run gpsctl before gpsd would make the data available) on a little la[ptop with the same M8 gpsd issues.
(In reply to Thomas Backlund from comment #52) > is the gpsd service enabled ? I experienced gpsd enabled but not running after boot for two boots. The message from systemctl status on those occasions looked like this, at the beginning: # systemctl status gpsd ● gpsd.service - GPS (Global Positioning System) Daemon Loaded: loaded (/usr/lib/systemd/system/gpsd.service; enabled; vendor preset: disabled) ...but not running Either 'systemctl status gpsd` or dmesg or journalctl reported a *timeout* error. Using systemctl status at those times showed enabled, not running, vendor preset disabled. I'm sure I had enabled it with systemctl previously and theorize the upgrade to testing packages reset a switch. My recollection is that I re-enabled the service one more time, 687 sudo systemctl status gpsd 688 sudo systemctl enable gpsd 698 sudo systemctl status gpsd 848 sudo systemctl restart gpsd From then on, gpsd.service has started at boot without intervention.
Please disconnect the device, reboot, then open a terminal and, as root run udevadm monitor Copy/paste or attach the output depending on the volume.
Also, run gpsctl while udevadm is running, but keep track of what output is from before running it and what is from after.
(In reply to Dave Hodgins from comment #56) > Also, run gpsctl while udevadm is running, but keep track of what output > is from before running it and what is from after. After cold boot, device unplugged: [root@x570i rolf]# udevadm monitor monitor will print the received events for: UDEV - the event which udev sends out after rule processing KERNEL - the kernel uevent *device is plugged here* KERNEL[140.522958] add /devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:08.0/0000:05:00.1/usb1/1-3 (usb) KERNEL[140.580868] add /devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:08.0/0000:05:00.1/usb1/1-3/1-3:1.0 (usb) KERNEL[140.584056] add /devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:08.0/0000:05:00.1/usb1/1-3/1-3:1.0/tty/ttyACM1 (tty) KERNEL[140.584116] bind /devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:08.0/0000:05:00.1/usb1/1-3/1-3:1.0 (usb) KERNEL[140.584159] add /devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:08.0/0000:05:00.1/usb1/1-3/1-3:1.1 (usb) KERNEL[140.584198] bind /devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:08.0/0000:05:00.1/usb1/1-3/1-3:1.1 (usb) KERNEL[140.584243] bind /devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:08.0/0000:05:00.1/usb1/1-3 (usb) UDEV [141.146671] add /devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:08.0/0000:05:00.1/usb1/1-3 (usb) UDEV [141.151726] add /devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:08.0/0000:05:00.1/usb1/1-3/1-3:1.1 (usb) UDEV [141.151775] add /devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:08.0/0000:05:00.1/usb1/1-3/1-3:1.0 (usb) UDEV [141.153563] bind /devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:08.0/0000:05:00.1/usb1/1-3/1-3:1.1 (usb) UDEV [141.154048] add /devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:08.0/0000:05:00.1/usb1/1-3/1-3:1.0/tty/ttyACM1 (tty) UDEV [141.156331] bind /devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:08.0/0000:05:00.1/usb1/1-3/1-3:1.0 (usb) UDEV [141.165119] bind /devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:08.0/0000:05:00.1/usb1/1-3 (usb) *messages stop, then, in another konsole window*: [rolf@x570i ~]$ gpsctl /dev/ttyACM1 identified as a NMEA0183 at 9600 baud. [rolf@x570i ~]$ *in root window, further messages*: KERNEL[183.638832] change /devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:08.0/0000:05:00.3/usb3/3-1/3-1.2/3-1.2:1.2/0003:046D:C52B.0005/0003:046D:4051.0009/power_supply/hidpp_battery_0 (power_supply) UDEV [183.682669] change /devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:08.0/0000:05:00.3/usb3/3-1/3-1.2/3-1.2:1.2/0003:046D:C52B.0005/0003:046D:4051.0009/power_supply/hidpp_battery_0 (power_supply) *unchanged until now*
Does it have a battery that might be low?
No, I am using a desktop itx pc. Seems we are seeing a logitech unifying receiver that connects mouse and keyboard to this machine and others on the LAN via a USB Sharing Switch. [rolf@x570i ~]$ lsusb | grep -i 046D Bus 003 Device 006: ID 046d:c52b Logitech, Inc. Unifying Receiver The dongle has no power but from the usb connection, if that's the question.
Install strace if it hasn't already been installed. Reboot and connect the device Run "strace -f s 128 -ostrace.txt gpsctl then attach the strace.txt file That should help indicate what upsctl is doing that is triggering the device to start working.
As I say in Comment #54, ...From then on, gpsd.service has started at boot without intervention. IOW, my installation is not requiring gpsctl for the device to be initiated since the indicated steps I executed.
Ah. Sorry, I missed that comment. Thanks for the update.
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2021-0411.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED