the trixei update script stops with cr/lf charracters
An exact error message would be helpful.
well it looks like someone has edited the update script in windows which adds CR/lf at the end of each line in part of the script
I tried the update script again for the third time and this time I did not see the cr/lf’s
but it still ended in failure.
* Command: apt-get -y dist-upgrade
│ - Exit code: 100
│ - DietPi version: v9.17.2 (MichaIng/master) | HW_MODEL: 5 | HW_ARCH: 3 |
│ DISTRO: 7
│ - Error log:
│ Reading package lists…
│ Building dependency tree…
│ Reading state information…
│ You might want to run ‘apt --fix-broken install’ to correct these.
│ The following packages have unmet dependencies:
│ alsa-utils : Depends: libasound2t64 (>= 1.2.14) but it is not installed
│ libarchive13t64 : Depends: libnettle8t64 but it is not installed
│ libatk-bridge2.0-0t64 : Depends: libatk1.0-0t64 (= 2.56.2-1) but it is not
│ installed
│
│ Retry : Re-run the last command that failed ↑
│ DietPi-Config : Edit network, APT/NTP mirror settings etc ▮
│
│
│
│ │apt --fix-broken install
Removing libgnutls30:arm64 (3.7.9-2+deb12u5) …
Selecting previously unselected package libgnutls30t64:arm64.
(Reading database … 71498 files and directories currently installed.)
Preparing to unpack …/libgnutls30t64_3.8.9-3_arm64.deb …
Unpacking libgnutls30t64:arm64 (3.8.9-3) …
Setting up libnettle8t64:arm64 (3.10.1-1) …
Setting up libhogweed6t64:arm64 (3.10.1-1) …
Setting up libp11-kit0:arm64 (0.25.5-3) …
Setting up libunistring5:arm64 (1.3-2) …
Setting up libgnutls30t64:arm64 (3.8.9-3) …
(Reading database … 71527 files and directories currently installed.)
Preparing to unpack …/libc6-dev_2.41-12+rpt1_arm64.deb …
Unpacking libc6-dev:arm64 (2.41-12+rpt1) over (2.36-9+rpt2+deb12u12) …
Preparing to unpack …/libgtk-3-0t64_3.24.49-3_arm64.deb …
Unpacking libgtk-3-0t64:arm64 (3.24.49-3) …
dpkg: error processing archive /var/cache/apt/archives/libgtk-3-0t64_3.24.49-3_a
rm64.deb (–unpack):
trying to overwrite ‘/usr/lib/aarch64-linux-gnu/gtk-3.0/3.0.0/immodules/im-am-e
t.so’, which is also in package libgtk-3-0:arm64 1:3.24.38-2\~deb12u2+rpt7+rpi1
Errors were encountered while processing:
/var/cache/apt/archives/libgtk-3-0t64_3.24.49-3_arm64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@DietPi:\~#
all our scripts are hosted on Github and are not maintained on Windows.
Anyway the issue is not related to any incorrect character
This is your issue now
similar to this one Debian Trixie | Upgrade script support thread · Issue #7644 · MichaIng/DietPi · GitHub
At the time of reporting this issue at the ends of each line of the script it ended in cr/lf which as I said is indicative of the script or part of it being edited in windows
Even when trying to push files with CRLF ending, GitHub (or Git) normalizes them automatically. So when you download the raw script it always has LF ending. There is even this weird behavior that GitHub desktop on Windows gives a warning when changing the line ending in local editor to LF:
This is when I change it from CRLF to LF, and it changes it back. But what finally lands on GitHub always has correct LF ending regardless, even that the warning seems to indicate the opposite.
So if you run into such error again, please show in detail which command you were running/how you downloaded the script, and the exact error message.
Solution for the package overwrite error:
dpkg -P --force-depends gir1.2-gtk-3.0 libgtk-3-0 libgtk-3-common
apt -f install
Then rerun the upgrade script.
1 Like
Hello, I copied the script from Debian Trixie | Upgrade script support thread · Issue #7644 · MichaIng/DietPi · GitHub
bash -c “$(curl -sSf ‘https://raw.githubusercontent.com/MichaIng/DietPi/dev/.meta/dietpi-trixie-upgrade’)”
And then ran it, it got through the script quite a long way, I was watching it, then at some point which I did not take note of I started seeing ^M at the end of each line then it all stopped.
I am sorry I didn’t take note of the point of failure but shortly afterwards with another try it all succeeded.
Hmm, maybe there was an issue with the download. Though in that case bash should have aborted with a syntax error right from the start thanks to the { ... } command grouping, else piping/expanding a download right into a shell wouldn’t be that failsafe. Also you would have seen a curl error then.
The ^M you saw, where/how did that appear exactly? Since the raw content of the script is not printed to the console. Instead, most commands are executed with our G_EXEC wrapper, which prints a message (usually the command itself, indeed) with a leading processing animation, this little yellow dot moving left and right. Once the command succeeded, it prints the same message with a leading [ OK ] on top of the previous processing message. Both makes use of carriage return, the moving dot to overwrite the previous “animation” stage while moving, as well as the OK message to overwrite the processing animation. If the terminal does not support the carriage return, i.e. does not interpret it to move the cursor to the beginning of the “current” line, it would be printed as ^M instead. I could imagine that some otherwise unrelated error or terminal misconfiguration (which can also be cause by other scripts or unintended terminal code sequences) could cause the same.
Which SSH client did you use (if any) or which kind of terminal? Though does not seem a general issue in your case since the next run worked well without any unintended characters.
If there was carriage return characters in the raw script, you would have seen a bash syntax error, and, if I am not mistaken, also this would have aborted the script right at the start, due to mentioned { .. } wrapping, which interprets the whole command sequence/script before starting to execute anything.
Were you able to resolve the problem with the command Micha suggested?
Hi, I have used the suggested remedy, after I found it on the forum, my other pi5 didn’t need it.