You are not logged in.
Yeah the support sucks (as usual by using an AI assistant instead of an official E-Mail address).
Nevermind, the initial problem ist solved via sdcard proxy
Found a workaround via sdcard.
Sadly the TomTomGo wants to be smart and re-routes the track, if it doesn't knows the roads.
So the question ist, how do I find out if the 45,- update of the map will actually know all the tracks in the wood I want to use?
I have this old TomTom Navigation device, which has quite outdated maps.
Those seem to be only updatable with a WindowsPC.
I don't mid the old maps, as I found hints that it should be possible to just upload tracks. For that the device "should" be able to be recognized as a mass storage device.
But it seems to be missing something and I don't get it.
tail -f /var/log/syslog
2026-09-02T11:23:47.601753+02:00 eline kernel: usb 3-6: USB disconnect, device number 41
2026-09-02T11:23:47.601769+02:00 eline kernel: rndis_host 3-6:1.0 usb0: unregister 'rndis_host' usb-0000:00:14.0-6, RNDIS device
2026-09-02T11:23:57.445942+02:00 eline kernel: usb 3-6: new high-speed USB device number 42 using xhci_hcd
2026-09-02T11:23:57.585774+02:00 eline kernel: usb 3-6: New USB device found, idVendor=1390, idProduct=5a01, bcdDevice= 3.10
2026-09-02T11:23:57.585797+02:00 eline kernel: usb 3-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
2026-09-02T11:23:57.585816+02:00 eline kernel: usb 3-6: Product: TomTom GO Essential
2026-09-02T11:23:57.585896+02:00 eline kernel: usb 3-6: Manufacturer: TomTom
2026-09-02T11:23:57.585940+02:00 eline kernel: usb 3-6: SerialNumber: ZN7398I04757
2026-09-02T11:23:57.589818+02:00 eline kernel: rndis_host 3-6:1.0 usb0: register 'rndis_host' at usb-0000:00:14.0-6, RNDIS device, 1e:2e:42:82:a6:94
2026-09-02T11:23:57.591950+02:00 eline mtp-probe: checking bus 3, device 42: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-6"
2026-09-02T11:23:57.592531+02:00 eline mtp-probe: bus: 3, device: 42 was not an MTP device
2026-09-02T11:23:57.610810+02:00 eline mtp-probe: checking bus 3, device 42: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-6"
2026-09-02T11:23:57.611203+02:00 eline mtp-probe: bus: 3, device: 42 was not an MTP deviceI fail to figure out what is missing.
lsusb gives me:
Bus 003 Device 042: ID 1390:5a01 TOMTOM B.V. TomTom GO Essentialbut nothing appears in lsblk.
Thank you very much. Sorry I didn't get that myself (bad time at the moment).
I am pretty sure it worked before the last update of my system, which changed inkscape from 1.2 to 1.4 (as far as I see it. or it was the upgrade from daedalus to excalibur).
BTW shouldn't that be a dependency (as the extension manager seems to be an essential part of inkscape)?
I try to open a dxf file in inkscape but get errors.
running devuan excalibur
Same when trying to open the extension manager itself:
Trying to self-update the package... Failed to update!
Please delete the package manually! (see location below)
Please report this error
------------------------
Report URL: https://gitlab.com/inkscape/extras/extension-manager/-/issues
Location: /usr/share/inkscape/extensions/inkman/inkman/inkman
inkscape-extension-manager: 1.0
Not done
Traceback (most recent call last):
File "/usr/share/inkscape/extensions/inkman/inkman/manage_extensions.py", line 61, in recovery_run
run(args)
~~~^^^^^^
File "/usr/share/inkscape/extensions/inkman/inkman/manage_extensions.py", line 34, in run
from inkman.targets import TARGETS
File "/usr/share/inkscape/extensions/inkman/inkman/inkman/targets.py", line 5, in <module>
from .target import ExtensionsTarget, BasicTarget
File "/usr/share/inkscape/extensions/inkman/inkman/inkman/target.py", line 28, in <module>
from inkex.command import call
File "/usr/share/inkscape/extensions/inkex/__init__.py", line 11, in <module>
from .extensions import *
File "/usr/share/inkscape/extensions/inkex/extensions.py", line 34, in <module>
from .elements import (
...<10 lines>...
)
File "/usr/share/inkscape/extensions/inkex/elements/__init__.py", line 10, in <module>
from ._base import ShapeElement, BaseElement
File "/usr/share/inkscape/extensions/inkex/elements/_base.py", line 40, in <module>
from ..styles import Style, Classes, StyleValue
File "/usr/share/inkscape/extensions/inkex/styles.py", line 31, in <module>
import tinycss2
ModuleNotFoundError: No module named 'tinycss2'OK, should know that, I guess.
I just installed okular with:
apt-get install okularAs I didn't noticed that is a KDE program, I just got a whole bunch of extra packages.
And a Openbox sub-menu flowded with 11 entries of okular.
So to remove okular with all packages that came with it:
apt-get purge okularOr do I need an extra flag to get rid of the packages that came as a dependency of okular?
Did you actually run that sed command?
I did and the file I tested did not show any change before and after the sed command.
BUT then I marked that one in my vi and pasted it with the middle mouse button into the vi on another machine (remote terminal), assuming it would be "the same", which apparently is a wrong assumption, since with that move you get the mentioned spaces in the blank lines. That is most likely the reason why the file on my machine has a different file size than the one I pasted here.
Lesson learnt and again appoligies to mess this up.
host deb.devuan.org
That perhaps works easier as my long way around. Hope I remember the next time I need that knowledge
Not the case here. Both versions have the same size.
I insert blank lines with the "o" command of vi, followed by [ESC], so no characters in those lines.
Still think something might be amiss with my nameserver, see my post #23
(replacing the deb.devuan.org with single mirror, which gave me a good result with traceroute, works fine)
Darn! you were right. I am notoriously copy and pasting with left/middle mouse button.
Turns our, if you open the working file in one vi, mark it there and drop that into another open vi, it will add the mentioned (by ralph.ronnquist) spaces in blank lines.
Sorry for being an annoyance.
Did a bit of experimenting.
I just did a:
traceroute deb.devuan.orgseveral times, which gave me quite different results from
"nework not reachable" to
ending with the (default) 30 hops, with no reached server
and some quick responses, from which I picked the fastest one with the fewest hops.
then I searched this:
https://pkgmaster.devuan.org/mirror_list.txt
with the domain name of that reply.
I exchanged the found mirror with the "deb.devuan.org" in devuan.sources.
Now I get hits on all suits without any fail so far.
Maybe something in my WAN setup is blocking things (or my ISP does)
$ ls -l /etc/apt/sources.list*
-rw-r--r-- 1 root root 1104 Nov 12 2023 /etc/apt/sources.list_daedalus
/etc/apt/sources.list.d:
total 4
-rw-r--r-- 1 root root 1603 Nov 7 21:21 devuan.sourcesI have somewhat erratic behaviour on both
deb.devuan.org and
de.deb.devuan.org
I just started the notebook, which I change to excalibur just a few days prior to the release.
So the new style devuan.sources there worked flawlessly in that process.
I did not change anything with that sources and now an apt-get update gives me
E: The repository '<any-of-the-non-secure-excalibur-repos> Release' no longer has a release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.(sorry for not c&p this, it's only om tty0 of the other machine)
So still no idea how to fix this reliable.
EDIT: similar errors of other debian derivates mostly suggest missing/faulty repos.
Is there a way to find which actual repo I hit with:
(at any given run on it)
http://deb.devuan.org/merged
http://de.deb.devuan.org/merged(of course only one of those are used in any attempt)
EDIT2 (after a bit of digging):
$ curl -Is http://deb.devuan.org/merged | head -1
HTTP/1.1 301 Moved Permanently
$ curl -Is http://de.deb.devuan.org/merged | head -1
HTTP/1.1 301 Moved PermanentlyAs I understand it, that should be "200"
But then: why does it get the security updates and not the others?
Next PC, same problem.
This time I removed sources.list and sources.list~
And placed the new style devuan.sources in /etc/apt/sources.de/
Again only getting hits on security updates.
So the working solution from before seems to be coincidence not causality.
So I'm kind of back to square one.
(additionally the newest daedalus kernel seems to miss activating the USB subsystem on my chromebox. I have to start the old kernel to have a keyboard)
OK, maybe there is something strange.
As I disabled the daedalus sources, it looked like this:
root@kamin:~# ls -l /etc/apt/ |grep sources
-rw-r--r-- 1 root root 0 Mar 9 2024 sources.list~
drwxr-xr-x 2 root root 4096 Nov 5 19:30 sources.list.d
-rw-r--r-- 1 root root 1358 Jul 7 2024 sources.list_daedalusI just checked it again on a hunch:
root@kamin:~# ls -l /etc/apt/ |grep sources
-rw-r--r-- 1 root root 0 Nov 5 14:10 sources.list
-rw-r--r-- 1 root root 0 Mar 9 2024 sources.list~
drwxr-xr-x 2 root root 4096 Nov 5 19:30 sources.list.d
-rw-r--r-- 1 root root 1358 Jul 7 2024 sources.list_daedalusDo I have a gap of knowledge here?
Where does the empty sources.list come from? Is that something generated from the sources.list~?
Anyways, deleting the two empty files, gives me:
root@kamin:~# ls -l /etc/apt/ |grep sources
drwxr-xr-x 2 root root 4096 Nov 5 19:30 sources.list.d
-rw-r--r-- 1 root root 1358 Jul 7 2024 sources.list_daedalusAnd now I'm getting hits on all repos/suits. Just bugs me, that I don't get the whole picture here..
I only have a faint idea of this mechanism, so:
Could the current situation cause some erratic behaviour, like amirror "not fount" and one minute later it does?
Or: not all suits included in the sources to be found?
(the detailed problem is fund here: https://dev1galaxy.org/viewtopic.php?pid=59135#p59135)
No.
But that wouldn't explain why it showed the same behaviour with the old style of the sources file.
PC was off over night, I now checked the devuan.sources file and I deleted and re-insert the blank lines.
Then I get a working update.
For testing I changed back to the short variant with all suites in one line (only excalibur-security in a separat stanza):
apt-get update, again, give me only security.
changing back to the previous working one, I still get only the security updates.
very un-deterministic
EDIT: quite often I get this behaviour (there was about 5sec between the error and the next execution of the command:
root@kamin:~# apt-get update
Ign:1 http://de.deb.devuan.org/merged excalibur-security InRelease
Err:2 http://de.deb.devuan.org/merged excalibur-security Release
404 Not Found [IP: 147.229.176.19 80]
Reading package lists... Done
E: The repository 'http://de.deb.devuan.org/merged excalibur-security Release' no longer has a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
root@kamin:~# apt-get update
Hit:1 http://de.deb.devuan.org/merged excalibur-security InRelease
Reading package lists... DoneEDIT2: reboot or halt -p do not change the situation, still only a hit on security packages.
As http://de.deb.devuan.org/ should be e repo pool: might there be some repos not up to date?
try a symbolic link of the /boot/firmware to the /boot/broadcom.Well, I totally overlooked that method since my brain got stuck with "you can't have new dir at the same level as the mountpoint" stupid me. The link will work anyways of course.
Problem now is, that the main purpose of that raspi was watching netflix, which apparently is not possible (al least in a painless enough way) on arm architecture.
just to be sure: is that the point where you have to remove the install medium (guess that is to be done in VM/VirtualBox, too.)
As for the upgrade from daedalus, it is a mixed bag for me so far:
https://dev1galaxy.org/viewtopic.php?id=7525
As for the file: I would too, say those are clean text files.
BTW: it's the other was around with me: I do not get anĺong with nano (might be it is, that I'm used to vi since my first encounters with *nix systems in 1997, Solaris and IRIX in that case).
Seems I have to try the split version of the sources file on the new machine for reasons that might stay mysterious...
UPDATE:
splitting the file was in vain:
# Devuan 6 excalibur
## The new style method of using repositories to install software.
## This /etc/apt/sources.list.d/devuan.sources is new style and location file
## The /etc/apt/old.style.sources.list contains the same as this.
## https://linuxconfig.org/ubuntus-repository-configuration-ubuntu-sources-have-moved-to-etc-apt-sources-list-d-ubuntu-sources
## Normal excalibur sources
Types: deb
URIs: http://de.deb.devuan.org/merged
Suites: excalibur
Components: main non-free contrib non-free-firmware
Enabled: yes
Signed-By: /usr/share/keyrings/devuan-archive-keyring.gpg
Architectures: amd64
## backports excalibur sources
Types: deb
URIs: http://de.deb.devuan.org/merged
Suites: excalibur-backports
Components: main non-free contrib non-free-firmware
Enabled: yes
Signed-By: /usr/share/keyrings/devuan-archive-keyring.gpg
Architectures: amd64
## proposed-updates excalibur sources
Types: deb
URIs: http://de.deb.devuan.org/merged
Suites: excalibur-proposed-updates
Components: main non-free contrib non-free-firmware
Enabled: yes
Signed-By: /usr/share/keyrings/devuan-archive-keyring.gpg
Architectures: amd64
## updates excalibur sources
Types: deb
URIs: http://de.deb.devuan.org/merged
Suites: excalibur-updates
Components: main non-free contrib non-free-firmware
Enabled: yes
Signed-By: /usr/share/keyrings/devuan-archive-keyring.gpg
Architectures: amd64
## excalibur security sources
Types: deb
URIs: http://de.deb.devuan.org/merged
Suites: excalibur-security
Components: main non-free contrib non-free-firmware
Enabled: yes
Signed-By: /usr/share/keyrings/devuan-archive-keyring.gpgstill:
root@kamin:/etc/apt/sources.list.d# apt-get update
Hit:1 http://de.deb.devuan.org/merged excalibur-security InRelease
Reading package lists... Donesomething strange in the /etc/apt dir:
(kamin is the new pc, eline the old)
root@kamin:/etc/apt# ls -l
total 36
drwxr-xr-x 2 root root 4096 Mar 9 2024 apt.conf.d
drwxr-xr-x 2 root root 4096 May 28 2023 auth.conf.d
drwxr-xr-x 2 root root 4096 May 28 2023 keyrings
-rw-r--r-- 1 root root 150 Mar 9 2024 listchanges.conf
drwxr-xr-x 2 root root 4096 Mar 28 2021 listchanges.conf.d
drwxr-xr-x 2 root root 4096 May 28 2023 preferences.d
-rw-r--r-- 1 root root 0 Mar 9 2024 sources.list~
drwxr-xr-x 2 root root 4096 Nov 4 18:30 sources.list.d
-rw-r--r-- 1 root root 1358 Jul 7 2024 sources.list_daedalus
drwxr-xr-x 2 root root 4096 Nov 4 12:54 trusted.gpg.d
root@eline:/etc/apt# ls -l
total 36
drwxr-xr-x 2 root root 4096 Nov 1 10:33 apt.conf.d
drwxr-xr-x 2 root root 4096 May 28 2023 auth.conf.d
drwxr-xr-x 2 root root 4096 May 28 2023 keyrings
-rw-r--r-- 1 root root 147 Nov 1 10:27 listchanges.conf
drwxr-xr-x 2 root root 4096 Mar 28 2021 listchanges.conf.d
drwxr-xr-x 2 root root 4096 May 28 2023 preferences.d
-rw-r--r-- 1 root root 0 Oct 17 21:12 sources.list~
drwxr-xr-x 2 root root 4096 Nov 1 10:14 sources.list.d
-rw-r--r-- 1 root root 1209 Oct 26 16:04 sources.list_daedlus
drwxr-xr-x 2 root root 4096 Nov 1 10:27 trusted.gpg.dI'm a bit confused about the timestamps of some dirs
So both of the above work? (from post #9)
can you open it with vim to see if there any hidden CR/LF symbols?
EDIT:
My devuan.sources (generated by hand not with "apt mordernize-sources") is from a PC I did upgrade prior to the excalibur release (just a few days)
-on that machine, I get all sources with the "all suites in one line"
using the same file now on another machine gives the "only secure" result.
you mean like:
## Normal excalibur sources
Types: deb
URIs: http://deb.devuan.org/merged
Suites: excalibur
Components: main non-free contrib non-free-firmware
Enabled: yes
Signed-By: /usr/share/keyrings/devuan-archive-keyring.gpg
Architectures: amd64
## excalibur-backports sources
Types: deb
URIs: http://deb.devuan.org/merged
Suites: excalibur-backports
Components: main non-free contrib non-free-firmware
Enabled: yes
Signed-By: /usr/share/keyrings/devuan-archive-keyring.gpg
Architectures: amd64
[..]wouldn't that defeat the elegance of the new format a bit?
for testing I changed the URI to
apt-get update http://de.deb.devuan.org/merged
Get:1 http://de.deb.devuan.org/merged excalibur-security InRelease [37.9 kB]
Get:2 http://de.deb.devuan.org/merged excalibur-security/main amd64 Packages [69.8 kB]
Get:3 http://de.deb.devuan.org/merged excalibur-security/main Translation-en [47.3 kB]
Get:4 http://de.deb.devuan.org/merged excalibur-security/non-free-firmware amd64 Packages [548 B]
Get:5 http://de.deb.devuan.org/merged excalibur-security/non-free-firmware Translation-en [306 B]
Fetched 156 kB in 4s (40.9 kB/s)
Reading package lists... DoneStill only security, but more hits?
the devuan.sources is a copy of the one I used with a successful update on the other machine.
apt shows the same behaviour:
# apt update
Hit:1 http://deb.devuan.org/merged excalibur-security InRelease
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
22 packages can be upgraded. Run 'apt list --upgradable' to see them.maybe a problem with http://deb.devuan.org/ ?
renamed, which I meant by "disabled the daedalus sources"
Already did it that way with another machine.
Could it be, I need some cleanup from switchen the sources back and forth?
Strange thing is: Why does it get the security packages but not the normal packes from the same devuan.sources?