You are not logged in.
- Topics: Active | Unanswered
#1626 Re: ARM Builds » [Solved] Devuan and Raspberry Pi 3B+ hardware » 2020-05-22 14:50:39
Hello:
... try sumfin for me ??
Sure, be glad to.
But my guess is that you need this run on a Devuan ascii RPi3b+.
echo 'SUBSYSTEM=="vchiq",GROUP="video",MODE="0660"' > /etc/udev/rules.d/10-vchiq-permissions.rules echo 'SUBSYSTEM=="vcio",GROUP="video",MODE="0660"' >> /etc/udev/rules.d/10-vchiq-permissions.rules echo 'SUBSYSTEM=="vc-mem",GROUP="video",MODE="0660"' >> /etc/udev/rules.d/10-vchiq-permissions.rules
I gave up (for the time being) on Devuan ascii on the RPi.
See the thread and the post (#15) with the 'why' here.
Basically, the roasting software I need to use is 'tailored' to how Raspbian is packaged and not supported in Devuan, only Raspbian.
On top of that, I now have the problem of Raspbian not having a root account ... 8^ð !
To be root y have to sudo su.
pi@grouchopi:~ $ sudo su
root@grouchopi:/home/pi# No password, save having logged in.
And If I generate a root account (as sudo!) it seems to work but there are issues with /tmp not being there.
eg: if I run mc as root.
I'll ask at the RPi forum first and then here.
Maybe someone will help me sanitize this Raspbian thing enough to make it a bit more comfortable to use.
Cheers,
A.
#1627 Re: Installation » Devuan ARM64 depndency issue » 2020-05-21 18:13:07
Hello:
... try ln -s /home/chris /home/pi (replace chris with your id). It probably needs to run as root to update /home.
This 'setting up a user called pi' would be done on a Devuan RPi installation.
ie: which does not come with a predermined sudo enabled userid set up by default.
The only object in setting up a user pi instead of my usual userid groucho is to see if the roasting software will work, as it seems to expect the Raspbian default.
ie: a predetermined userid pi with the corresponding /pi sub-dir in /home.
Which is obviously not present in Devuan (which would seem to be the proper way to do things).
When the software scripts look for the expected /home/pi/.config files and does not find them, everything goes south.
At least, that is what I think is happening.
Thanks for your input.
Cheers,
A.
#1628 Re: Installation » Devuan ARM64 depndency issue » 2020-05-21 11:20:02
Hello:
Try ...
I've decided to give up, at least for the time being.
But not on Devuan, it will always be my Linux distribution.
But I really need to get the roasting software running and see if it is worthwhile to use the RPi for that.
The people at raspberry.org have no support for Devuan and the author of the software I need to run on the RPi has no support for Devuan either.
He built and tested it for Raspbian only.
But to the exteme.
eg:
I burned the latest (minimal Buster Lite) Raspbian image on the 2.0Gb SDCard and got the HDD working.
After a rather long update/upgrade cycle I installed the basics (xserver-xorg, slim, openbox, tint2, lxterminal) and then the roasting software.
Worked as expected.
And what did I find?
Confusingly enough (for me), the Raspbian image comes with a default user, already set up with a login password, sudo membership and all.
But no root access which you have to set up yourself.
By sudoing your way along ... 8^7'
And what name would this default user have?
You guessed it: none other than pi.
Which is why (?) the script could not find /home/pi in my Devuan installation.
There is a significant (?) difference between the installations.
While uname -a with the Devuan image gave this output ...
groucho@rpidevuan:~$ uname -a
Linux rpidevuan 4.16.14-v8+ #1 SMP PREEMPT Tue Jun 5 18:50:10 CEST 2018 aarch64 GNU/Linux
groucho@rpidevuan:~$ ... the Raspbian image gave this one:
pi@grouchopi:~ $ uname -a
Linux grouchopi 4.19.97-v7+ #1294 SMP Thu Jan 30 13:15:58 GMT 2020 armv7l GNU/Linux
pi@grouchopi:~ $ ie: v8+ and aarch64 vis-a-vis v7+ and armv7.
Would this have a bearing in all the issues I have found?
I don't have the necessary know-how to change whatever scripts need to be changed in order for the software to run on Devuan.
So for the time being I'll see how it does on Raspbian.
When I have some more time on my hands, I'll try with a Devuan image again.
Maybe setting up a user named pi will make a difference?
In the meanwhile, any further ideas are welcome.
I've run out.
Cheers,
A.
#1629 Re: Installation » Devuan ARM64 depndency issue » 2020-05-20 19:16:20
Hello:
Just before LIBOVERLAY_SCROLLBAR=0, the space is the delimiter.
Right.
Not really, LD_LIBRARY_PATH just makes the application search the custom locations first.
I see ...
Must be why, after following ralph.ronnquist's suggestion to install zlib1g:armhf, I now have a whole new can of worms on my hands.
Evidently he was right, I did need to install zlib1g:armhf.
Now, when I run the application as root from /usr/share/artisan I don't get the output I got before installing it ...
ie:
root@rpidevuan:/# /usr/share/artisan/artisan
/usr/share/artisan/artisan: error while loading shared libraries:
libz.so.1: cannot open shared object file: No such file or directory
root@rpidevuan:/# ... where the problem was just libz.so.1 not being found.
The output is more populated and there is no mention of libz.so.1:
t@rpidevuan:/home/groucho# /usr/share/artisan/artisan
Traceback (most recent call last):
File "artisan.py", line 68, in <module>
File "/home/pi/.local/lib/python3.5/site-packages/PyInstaller/loader/pyimod03_importers.py", line 631, in exec_module
File "artisanlib/main.py", line 86, in <module>
File "/home/pi/.local/lib/python3.5/site-packages/PyInstaller/loader/pyimod03_importers.py", line 714, in load_module
ImportError: libstdc++.so.6: cannot open shared object file: No such file or directory
[1624] Failed to execute script artisan
root@rpidevuan:/home/groucho# When I saw python3.5 I remembered having seen that the software needed that version of python which came installed in the Raspbian image.
Sure enough, the version in Devuan ascii was 2.7, so I installed 3.5.
But to no avail, the output was exactly the same.
There is no /pi sub-directory in my /home directory.
Nor are any of the other two files listed ie: artisan.py, main.py in the output present in my system.
libstdc++.so.6 is present but not in the LD_LIBRARY_PATH=:
root@rpidevuan:/home/groucho# locate libstdc++.so.6
/usr/lib/aarch64-linux-gnu/libstdc++.so.6
/usr/lib/aarch64-linux-gnu/libstdc++.so.6.0.22
/usr/share/gdb/auto-load/usr/lib/aarch64-linux-gnu/libstdc++.so.6.0.22-gdb.py
root@rpidevuan:/home/groucho# It seems that the developer really meant it: the software was build and tested for Raspian.
On one hand, python3.5 is not listed as a dependency (because Raspbian has it built in) and on the other, Raspbian seems to have some rather unique file locations.
eg: /home/pi/.local/lib/python3.5/site-packages/PyInstaller/loader/pyimod03_importers.py
All that python stuff in the /home directory?
I've been through quite a few distributions, can't recall having seen that before.
So ...
Short of just giving up and using Raspbian on my RPi to run the roasting software, any ideas towards making this work?
Thanks for your input.
A.
#1630 Re: Installation » Devuan ARM64 depndency issue » 2020-05-20 10:27:13
Hello:
... need to install zlib1g:armhf
A compression library from what I have read.
For some reason adding the armfh architecture did not pull it in.
Shouldn't it have been pulled in?
It installed without issue.
What use will it have?
Is there anything else armfh related that should have been pulled in?
Q1:
Would it be correct to assume that the developer sends everything to /dev/null because his Artisan software for RPi is build and tested for
Raspian Stretch, which is Debian and relies on systemd for taking care of the log?
If so, I'd need to be able to generate one.
Q2:
Would this suffice?
root@rpidevuan:/home/groucho# touch /var/log/artisan.log
root@rpidevuan:/home/groucho#then ...
--- snip ---
/usr/share/artisan/artisan "$@" 2>/var/log/artisan.loginstead of:
--- snip ---
/usr/share/artisan/artisan "$@" 2>/dev/nullThanks for your input.
Cheers,
A.
#1631 Re: Installation » Devuan ARM64 depndency issue » 2020-05-20 01:14:37
Hello:
... didn't update your sources immediately after adding the armhf ...
It could very well be, really can't recall.
I've made some advances with some indications from the developer.
Seems that there is no configured log file, everything goes to /dev/null.
But if I run the application as root from /usr/share/artisan I get some output:
root@rpidevuan:/# /usr/share/artisan/artisan
/usr/share/artisan/artisan: error while loading shared libraries:
libz.so.1: cannot open shared object file: No such file or directory
root@rpidevuan:/# The library libz.so.1 that the executable cannot find *is* present in /lib/aarch64-linux-gnu/:
root@rpidevuan:/# locate libz.so.1
/lib/aarch64-linux-gnu/libz.so.1
/lib/aarch64-linux-gnu/libz.so.1.2.8
root@rpidevuan:/# The problem is that the start-up script is telling the application to look for it elsewhere:
root@rpidevuan:/usr/bin# cat artisan
#!/bin/sh
if [ -f /etc/os-release ]; then
grep Raspbian /etc/os-release >/dev/null
# Workaround for issue #187
if [ $? -eq 0 ]; then
unset XDG_CURRENT_DESKTOP
fi
fi
exec /usr/bin/env QT_PLUGIN_PATH=/usr/share/artisan/PyQt5/Qt/plugins
LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/gtk-3.0/modules:/usr/share/a
rtisan:$LD_LIBRARY_PATH LIBOVERLAY_SCROLLBAR=0
GTK2_RC_FILES="$HOME/.gtkrc-2.0" /usr/share/artisan/artisan "$@" 2>/dev/null
root@rpidevuan:/usr/bin# There is no /usr/lib/x86_64-linux-gnu in my system.
But there is a /usr/lib/aarch64-linux-gnu/gtk-3.0.
It is not too clear to me how the path should read and where the library should be.
ie: where does the LD_LIBRARY_PATH= stanza end?
Any suggestions?
Thanks in advance,
A.
#1632 Re: Installation » Devuan ARM64 depndency issue » 2020-05-19 16:53:18
Hello:
Running (yes, again) apt-get check, apt-get update and apt-get upgrade showed everything was (should be) in place.
I now have to check and see if the roasting software works.
I'll post back on that later on.
Well ...
Later on came ...
... and went.
And much to my chagrin, the roasting software wouldn't start. 8 ^⁷
Nothing.
No output.
Unless I have missed something, there are no missing dependencies.
To make things worse, I cannot find anything within the logs in RPi's installation.
How can I debug this if I cannot get any data from the logs?
Thanks in advance,
A.
#1633 Re: Installation » Devuan ARM64 depndency issue » 2020-05-19 15:01:03
Hello:
If so, how to fix it?
I found a post in an Italian site with a clue to this problem, which was related to some other software.
It said that the fix was apt install -f.
Having nothing much to lose ...
root@rpidevuan:/home/groucho# apt-get -f install
Reading package lists... Done
Building dependency tree
Reading state information... Done
Correcting dependencies... Done
The following additional packages will be installed:
gcc-6-base:armhf libc6:armhf libgcc1:armhf
Suggested packages:
glibc-doc:armhf locales:armhf
The following NEW packages will be installed:
gcc-6-base:armhf libc6:armhf libgcc1:armhf
0 upgraded, 3 newly installed, 0 to remove and 1 not upgraded.
1 not fully installed or removed.
Need to get 2559 kB of archives.
After this operation, 8950 kB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://pkgmaster.devuan.org/merged ascii/main armhf gcc-6-base armhf 6.3.0-18+deb9u1 [180 kB]
Get:2 http://pkgmaster.devuan.org/merged ascii/main armhf libgcc1 armhf 1:6.3.0-18+deb9u1 [38.5 kB]
Get:3 http://pkgmaster.devuan.org/merged ascii/main armhf libc6 armhf 2.24-11+deb9u4 [2341 kB]
Fetched 2559 kB in 4s (544 kB/s)
Preconfiguring packages ...
Selecting previously unselected package gcc-6-base:armhf.
(Reading database ... 38598 files and directories currently installed.)
Preparing to unpack .../gcc-6-base_6.3.0-18+deb9u1_armhf.deb ...
Unpacking gcc-6-base:armhf (6.3.0-18+deb9u1) ...
Selecting previously unselected package libgcc1:armhf.
Preparing to unpack .../libgcc1_1%3a6.3.0-18+deb9u1_armhf.deb ...
Unpacking libgcc1:armhf (1:6.3.0-18+deb9u1) ...
Selecting previously unselected package libc6:armhf.
Preparing to unpack .../libc6_2.24-11+deb9u4_armhf.deb ...
Unpacking libc6:armhf (2.24-11+deb9u4) ...
Setting up gcc-6-base:armhf (6.3.0-18+deb9u1) ...
Processing triggers for libc-bin (2.24-11+deb9u4) ...
Setting up libgcc1:armhf (1:6.3.0-18+deb9u1) ...
Setting up libc6:armhf (2.24-11+deb9u4) ...
Setting up artisan:armhf (2.1.2) ...
Processing triggers for libc-bin (2.24-11+deb9u4) ...
root@rpidevuan:/home/groucho#Interesting ...
So then I went about seeing what would happen with lxappearance:
root@rpidevuan:/home/groucho# apt-get install lxappearance
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
gtk2-engines lxde-settings-daemon
The following NEW packages will be installed:
gtk2-engines lxappearance lxde-settings-daemon
0 upgraded, 3 newly installed, 0 to remove and 1 not upgraded.
Need to get 438 kB of archives.
After this operation, 1900 kB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://pkgmaster.devuan.org/merged ascii/main arm64 gtk2-engines arm64 1:2.20.2-3 [342 kB]
Get:2 http://pkgmaster.devuan.org/merged ascii/main arm64 lxappearance arm64 0.6.3-1 [80.4 kB]
Get:3 http://pkgmaster.devuan.org/merged ascii/main arm64 lxde-settings-daemon arm64 0.5.3-2 [15.7 kB]
Fetched 438 kB in 2s (184 kB/s)
Selecting previously unselected package gtk2-engines:arm64.
(Reading database ... 38908 files and directories currently installed.)
Preparing to unpack .../gtk2-engines_1%3a2.20.2-3_arm64.deb ...
Unpacking gtk2-engines:arm64 (1:2.20.2-3) ...
Selecting previously unselected package lxappearance.
Preparing to unpack .../lxappearance_0.6.3-1_arm64.deb ...
Unpacking lxappearance (0.6.3-1) ...
Selecting previously unselected package lxde-settings-daemon.
Preparing to unpack .../lxde-settings-daemon_0.5.3-2_arm64.deb ...
Unpacking lxde-settings-daemon (0.5.3-2) ...
Processing triggers for mime-support (3.60) ...
Setting up gtk2-engines:arm64 (1:2.20.2-3) ...
Setting up lxde-settings-daemon (0.5.3-2) ...
Setting up lxappearance (0.6.3-1) ...
root@rpidevuan:/home/groucho# Also interesting ...
Now the only thing left to see was what would happen with the roasting software installation, which I understood as installed but not configured:
root@rpidevuan:/home/groucho/Downloads# apt install ./artisan-linux-2.1.2_raspbian-stretch.deb
Reading package lists... Done
Building dependency tree
Reading state information... Done
--- empty line added ---
Note, selecting 'artisan:armhf' instead of './artisan-linux-2.1.2_raspbian-stretch.deb' <------------------- what is this about?
artisan:armhf is already the newest version (2.1.2).
--- empty line added ---
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
root@rpidevuan:/home/groucho/Downloads#
It seemed were more upgrades to do:
root@rpidevuan:/home/groucho/Downloads# apt-get update
Hit:1 http://pkgmaster.devuan.org/merged ascii InRelease
Hit:2 http://pkgmaster.devuan.org/merged ascii-updates InRelease
Hit:3 http://pkgmaster.devuan.org/merged ascii-security InRelease
Reading package lists... Done
root@rpidevuan:/home/groucho/Downloads#root@rpidevuan:/home/groucho/Downloads# apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
colord-data
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 1340 kB of archives.
After this operation, 33.8 kB disk space will be freed.
Do you want to continue? [Y/n]
Get:1 http://pkgmaster.devuan.org/merged ascii/main armhf colord-data all 1.3.3-1+devuan1 [1340 kB]
Fetched 1340 kB in 2s (521 kB/s)
(Reading database ... 39018 files and directories currently installed.)
Preparing to unpack .../colord-data_1.3.3-1+devuan1_all.deb ...
Unpacking colord-data (1.3.3-1+devuan1) over (1.2.1-1+devuan1) ...
Setting up colord-data (1.3.3-1+devuan1) ...
root@rpidevuan:/home/groucho/Downloads# Done ...
Running (yes, again) apt-get check, apt-get update and apt-get upgrade showed everything was (should be) in place.
I now have to check and see if the roasting software works.
I'll post back on that later on.
In the meanwhile ...
Could someone with the neccesary know-how explain what happened?
Why did I have to use apt install -f to get this right?
Thanks in advance.
Cheers,
A.
#1634 Re: Installation » Devuan ARM64 depndency issue » 2020-05-19 13:14:50
Hello:
3.
Could it be that the use of an image on my RPi 3B+ makes it non-upgradeable?
ie: certain libraries cannot be installed/upgraded, hence the dependency issue.
While continuing to set up my RPi, I came across the same problem, albeit not linked to the roasting sofware but to a Devuan package:
root@rpidevuan:/home/groucho# apt-get install lxappearance
Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
artisan:armhf : Depends: libc6:armhf (>= 2.17) but it is not going to be installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).
root@rpidevuan:/home/groucho# Rather puzzled by this, I checked on the dependencies for lxappearance:
root@rpidevuan:/home/groucho# apt-cache depends lxappearance
lxappearance
Depends: libatk1.0-0
Depends: libc6 <------------------- here it is
Depends: libcairo2
Depends: libdbus-1-3
Depends: libdbus-glib-1-2
Depends: libfontconfig1
Depends: libfreetype6
Depends: libgdk-pixbuf2.0-0
Depends: libglib2.0-0
Depends: libgtk2.0-0
Depends: libpango-1.0-0
Depends: libpangocairo-1.0-0
Depends: libpangoft2-1.0-0
Depends: libx11-6
Recommends: gtk2-engines
Recommends: lxde-settings-daemon
lxsession
root@rpidevuan:/home/groucho# The package libc6 shows up again as a dependency for lxappearance.
But what I don't understand is artisan:armhf being mentioned again but in this context.
Seeing that the problem is also present when installing a regular Devuan package, I think that its being related to the roasting software can be ruled out.
Could it then be something related to the Devuan image I used?
If so, how to fix it?
Thanks in advance,
A.
#1635 Re: ARM Builds » [Solved] Devuan and Raspberry Pi 3B+ hardware » 2020-05-19 13:03:02
Hello:
"If when running vcgencmd on a raspberry pi you get VCHI initialization failed then you need to add the video group to your user."
Yes, I saw that.
I added my user to video and also to www-data as recommended in some other post I saw, did not work.
But it's not really an issue, just a heads up. =-)
Thanks for your input.
Cheers,
A.
#1636 Re: Installation » Devuan ARM64 depndency issue » 2020-05-19 11:17:32
Hello:
Any ideas?
I posted this issue on the Artisan-user mailing list and got this answer:
I fear I cannot help with this one. Artisan on RPi is build and tested for
Raspian Stretch (next version will add a build for Raspian Buster). You
seem to run Devuan, right? Such a configuration is simply not supported.
Try to run from source...
Independently of the fact that the develper's answer really leaves much to be desired, a couple of questions come to mind:
1.
As far as I know (others may know better), Raspbian Stretch is based on Debian Stretch which in turn is nothing but Devuan ascii without the hindrances that systemd imposes on it.
Is this so or am I missing something here?
2.
If I am not missing something and my reasoning correct, then the dependency problem I am having is not at all related to Devuan (as expected).
ie: there should be no difference between running the roasting software on Raspbian Stretch or on Devuan ascii, there does not seem to be any systemd related problem.
I successfully run an older version of the roasting software on Devuan ascii 32bit/netbook, so what gives?
3.
Could it be that the use of an image on my RPi 3B+ makes it non-upgradeable?
ie: certain libraries cannot be installed/upgraded, hence the dependency issue.
The image of Ritchie Havens opening at Woodstock in 1969 came to mind this morning:
"Sometimes I feel like a motherless child
A long way from my home"
Any idea as to how I can solve this, short of having to use Raspbian on my RPi3B+?
Thanks in advance,
A.
#1637 Re: Installation » Devuan ARM64 depndency issue » 2020-05-18 22:32:46
Hello:
... that should be
# apt install libc6:armhf
I'm afraid that won't work.
root@rpidevuan:/home/groucho# apt install libc6:armhf
Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
libc6:armhf : Depends: libgcc1:armhf but it is not going to be installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).
root@rpidevuan:/home/groucho#... use
# apt install ./artisan-linux-2.1.2_raspbian-stretch.debto pull in the dependencies automatically.
No luck either ...
root@rpidevuan:/home/groucho/Downloads# apt install ./artisan-linux-2.1.2_raspbian-stretch.deb
Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
artisan:armhf : Depends: libc6:armhf (>= 2.17) but it is not installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).
root@rpidevuan:/home/groucho/Downloads# As you can see in both instances the problem of dependecy is the same:
--- snip ---
The following packages have unmet dependencies:
libc6:armhf : Depends: libgcc1:armhf but it is not going to be installed
--- snip ------ snip ---
The following packages have unmet dependencies:
artisan:armhf : Depends: libc6:armhf (>= 2.17) but it is not installed
--- snip ---Not one to give up, I insisted with the new arrival at the apt rebellion ...
root@rpidevuan:/# apt install libgcc1:armhf
Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
artisan:armhf : Depends: libc6:armhf (>= 2.17) but it is not going to be installed
libgcc1:armhf : Depends: gcc-6-base:armhf (= 6.3.0-18+deb9u1) but it is not going to be installed
Depends: libc6:armhf (>= 2.4) but it is not going to be installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).
root@rpidevuan:/# ... but it did not work.
Thanks a lot for your input.
Cheers,
A.
#1638 Installation » Devuan ARM64 depndency issue » 2020-05-18 20:32:01
- Altoid
- Replies: 16
Helloo:
Finally got my VGA/HDMI thingy and went about installing the coffee roaster software.
At first it would not install because of an architecture problem.
Some google and it was solved via dpkg --add-architecture armhf.
Still have to figure out the armhf / ARM64 thing.
So I then it installed properly but when I tried to start it, it would not.
I tried reinstalling the application and got this:
root@rpidevuan:/home/groucho/Downloads# dpkg -i artisan-linux-2.1.2_raspbian-stretch.deb
Selecting previously unselected package artisan:armhf.
(Reading database ... 37452 files and directories currently installed.)
Preparing to unpack artisan-linux-2.1.2_raspbian-stretch.deb ...
Unpacking artisan:armhf (2.1.2) ...
dpkg: dependency problems prevent configuration of artisan:armhf:
artisan:armhf depends on libc6 (>= 2.17).
dpkg: error processing package artisan:armhf (--install):
dependency problems - leaving unconfigured
Processing triggers for mime-support (3.60) ...
Errors were encountered while processing:
artisan:armhf
root@rpidevuan:/home/groucho/Downloads#
I'm guessing that libc6 refers to libc6:arm64, which is present in the system ...
groucho@rpidevuan:~$ uname -a
Linux rpidevuan 4.16.14-v8+ #1 SMP PREEMPT Tue Jun 5 18:50:10 CEST 2018 aarch64 GNU/Linux
groucho@rpidevuan:~$ groucho@rpidevuan:~$ locate libc6
/usr/share/doc/libc6
/usr/share/doc/libc6/BUGS
/usr/share/doc/libc6/NEWS.Debian.gz
/usr/share/doc/libc6/NEWS.gz
/usr/share/doc/libc6/README.Debian.gz
/usr/share/doc/libc6/README.hesiod.gz
/usr/share/doc/libc6/changelog.Debian.gz
/usr/share/doc/libc6/changelog.gz
/usr/share/doc/libc6/copyright
/usr/share/lintian/overrides/libc6
/var/lib/dpkg/info/libc6:arm64.conffiles
/var/lib/dpkg/info/libc6:arm64.list
/var/lib/dpkg/info/libc6:arm64.md5sums
/var/lib/dpkg/info/libc6:arm64.postinst
/var/lib/dpkg/info/libc6:arm64.postrm
/var/lib/dpkg/info/libc6:arm64.preinst
/var/lib/dpkg/info/libc6:arm64.shlibs
/var/lib/dpkg/info/libc6:arm64.symbols
/var/lib/dpkg/info/libc6:arm64.templates
/var/lib/dpkg/info/libc6:arm64.triggers
groucho@rpidevuan:~$ groucho@rpidevuan:~$ cat /usr/share/doc/libc6/copyright
This is the Debian prepackaged version of the GNU C Library version 2.23.
--- snip ---... or to libc6:armhf which is not and I cannot find in the repository:
root@rpidevuan:/home/groucho# apt-get install libc6-armhf
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package libc6-armhf
root@rpidevuan:/home/groucho# The nearest thing I have found is libc6-armhf-cross, but when I try to install it I get this:
root@rpidevuan:/home/groucho# apt-get install libc6-armhf-cross
Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
artisan:armhf : Depends: libc6:armhf (>= 2.17) but it is not installable
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).
root@rpidevuan:/home/groucho# Running apt --fix-broken install gets rid of artisan:armhf but that does not solve the problem, which apparently needs an uninstallable library.
Any ideas?
Thanks in advance,
A.
#1639 Re: ARM Builds » [Solved] Devuan and Raspberry Pi 3B+ hardware » 2020-05-18 01:47:56
Hello:
... uploaded my Devuan-pi4-os64 ...
... is vcgencmd.tar.xz
Great!
... believe will work for you.
Yes.
Indeed it does.
... need to make a deb ...
It would be make installing it more straightforward.
But seeing it is an ARM64 thing, maybe it would be best (?) for it to be in the image/installer.
In the meanwhile, those of us who are tinkering with Devuan/RPi can manage perfectly with tar.
The files get set up in the proper places Devuan-wise so no issues.
It need to be run it as root otherwise you get an error.
eg:
groucho@rpidevuan:~$ /usr/bin/vcgencmd measure_temp
VCHI initialization failed
groucho@rpidevuan:~$ root@rpidevuan:/home/groucho# /usr/bin/vcgencmd measure_temp
temp=35.4'C
root@rpidevuan:/home/groucho# Thank you so much for doing this. =-)
Best,
A.
#1640 Re: ARM Builds » [Solved] Devuan and Raspberry Pi 3B+ hardware » 2020-05-17 10:01:17
Hello:
... loaded in: /etc/modules
Indeed ...
... information for a module via sysfs in /etc/rc.local or other place, if you find appropriate in a daemon.
I'll take your word for it. =-)
I have no idea how all that works.
All I know is that if I need a module, that is one way to load it.
... creating a layer above another layer of complexity, and then mixing in another ...
The thing is that vcgencmd is specific to Broadcom chips but we don't have a *.deb for it.
And all the GPIO stuff that the RPi uses for things much more complex than the one I am implementing does not seem (at least I have not found it) to be anywhere but in Raspbian.
... greatest thing in the universe...
It would seem that ARM64, as far as Linux is concerned, is systemd land.
Exclusively.
Thanks for your input.
Cheers,
A.
#1641 Re: ARM Builds » [Solved] Devuan and Raspberry Pi 3B+ hardware » 2020-05-15 21:59:45
Hello:
You can compile it ...
Yes, I also saw that link in a post at the raspberry pi forums.
But I also read a number of other posts that pointed out that it was not as straightforward as it would seem.
My point would be that, as it seems to be a rather important bit (?) of what is needed to get ARM64 Debian to work smoothly ...
Shouldn't it be in the repository or better yet, part of the image/installation?
And then there's the GPIO stuff that apparently depends on systemd. =^ *'
Thanks for your input.
Cheers,
A.
#1642 Re: Hardware & System Configuration » Raspberry Pi 3B+ and USB HDD shutdown » 2020-05-15 19:52:49
Hello:
... best idea ...
Quite so ...
As you may have read, originally I started powering the HDD from one of the RPi's USB ports.
There was a problem with the SDD not spinning up but it was nothing other than the usual in these cases: the length and gauge of the cable with the micro-USB plug.
I wonder how they say too long / too thin in Chinese? 8^7
So I just got rid of it through some light PS surgery and replaced it with nothing.
The PS has three comfortable USB charging ports on the back and are enough.
Done that, I started powering the RPi with shorter and much better quality power only usb cable (Blackberry phone, I think) from one of the USB ports.
Voltage measurements taken at idle read 5.14V which would seem to be correct.
Pi's cut usb power, long before ...
I also thought as much.
So I switched to powering the HDD from one of the PS's USB ports.
Not being under RPi control, the HDD's shut down timing/scheme would be different.
ie: not as sudden.
Well ...
Turns out that the HDD's shutdown is exactly the same whether the HDD is powered from a USB port on the RPi or a USB port on a separate power supply.
A separate power supply that is not switched off when the RPi is shut down.
Whatever controls this HDD shutdown is within the Devuan image's configuration and evidently does it under the assumption that it is controlling a SD Card and not a HDD.
But I have not been able to figure out what/where it is.
I say this because I have observed that this same HDD does not shut down in the same manner when connected to my Asus 1000HE netbook.
Thanks for your input.
Cheers,
A.
#1643 ARM Builds » [Solved] Devuan and Raspberry Pi 3B+ hardware » 2020-05-14 20:46:48
- Altoid
- Replies: 16
Hello:
Working on my RPi3B+ hardware setup I have come across a few things for which I am still trying to wrap my head around.
Evidently ARM is not x86 and ARM64 is not x86_64.
One of the things that I'm not getting is the configuration of things related to the GPIO pins.
It seems that most if not all the settings for the GPIO pins rely on systemd, which Raspbian uses.
Another thing I have come across is the fact that vcgencmd is not in the image I've installed and cannot be installed from the repository.
And there's probably more I will be finding out about as I make progress with my installation/configuration.
Is there a way of getting around all this or will I end up having to use Raspbian in my RPi3B+?
Thanks in advance,
A.
#1644 Re: Installation » [Solved] Swap partition: swapon error and priority » 2020-05-12 14:36:02
Hello:
... only one swap partition (or swapfile) the priority has no importance.
Yes, I had read about that.
But then I asked myself about the swap priority beng -2 in particular this image (Devuan ascii ARM64) and thought that is was because there was another one somewhere.
ie: a swapfile somewhere in the SD Card, which I do not use save for reading the rootfs.
Then I concluded (as I mention above) that is was due to the use of an SD Card.
... choose the priority if you have more swap partitions (or swapfiles).
I have only one.
... the UUID is right ...
Yes, that's checked.
... change the priority of swap it is the swappiness of the system you should mess with (in /etc/sysctl.conf).
I recall having used that at some time with my workstation which has 8Gb RAM.
... wait until the system is otherwise behaving well.
Quite so ...
I need to get my VGA/HDMI adaptor (stuck somewhere in the mail delivery pipe) and set up the desktop/coffee roasting software.
That will be the test and then I'll be able to adjust swap accordingly.
Have a nice day
You too ... =-)
Thanks for your input.
Cheers,
A.
#1645 Re: Installation » [Solved] Swap partition: swapon error and priority » 2020-05-12 13:16:57
Hello:
... recreate the "swap signature" ...
Unfortunately that didn't work and somewhere along the line the partition's UUID got changed.
The RPi is originally intended to be used with an SD Card, but I share the opinion that SD Cards were not really intended for the type of use an RPi gives it but for use in cameras and such devices large ie: files written once, read many times over and once moved, eventually deleted.
Hence a swap file/partition being set with a priority of -2.
But I have not seen this swap priority setting in any other Linux installs/images.
So I have to conclude that it is being set as the default value somewhere.
Which begs the question: where is it set?
Any ideas?
My guess is that it is in one of the init files (?), I'll have to look around.
In any case, I found a way to permanently set the swap priority here.
This is how:
1. check the swap partition/file exists:
root@rpidevuan:/home/groucho# free
total used free shared buff/cache available
Mem: 887604 36952 794780 1292 55872 835068
Swap: 3145724 0 3145724
root@rpidevuan:/home/groucho# 2. check to see where it is mounted
root@rpidevuan:/home/groucho# blkid
--- snip ---
/dev/sda7: UUID="fd8f0765-c88e-43d1-8b8d-9b734fb6322a" TYPE="swap" PARTUUID="d34db33f-07"
root@rpidevuan:/home/groucho# 3. turn it off
root@rpidevuan:/home/groucho# swapoff /dev/sda74. check that it is off
root@rpidevuan:/home/groucho# swapon -s
root@rpidevuan:/home/groucho# 5. make a backup copy of your /etc/fstab
root@rpidevuan:/home/groucho# cp -p /etc/fstab /etc/fstab.bak
root@rpidevuan:/home/groucho#6. edit /etc/fstab and add pri=X in place of defaults, with X being the desired value and reboot.
7. check the result
root@rpidevuan:/home/groucho# swapon -s
Filename Type Size Used Priority
/dev/sda7 partition 3145724 0 1
root@rpidevuan:/home/groucho#root@rpidevuan:/home/groucho# free
total used free shared buff/cache available
Mem: 887604 37884 793036 1292 56684 834100
Swap: 3145724 0 3145724
root@rpidevuan:/home/groucho# I opted for a value of 1 but I'll have to check and see how it behaves once I finish my installation and get the coffee roasting software working.
Cheers,
A.
#1646 Re: ARM Builds » RPi3A+/3B/3B+/(4B) » 2020-05-09 11:54:44
Hello:
... it goes deep..
... $HOME/.config directory.
Quite so.
As a precautionary measure, I only used the appimage version but it also writes to $HOME/.config.
So, after using it I'd just exit the application and delete the config file it wrote.
I used it last night without any issue and this morning, for unknown reasons, the application would not start.
So I deleted everything etcher related from my system, downloaded the appimage version and tried again.
No dice.
It won't start.
I have not run any system updates/upgrades since the last time I used it, so I really don't think this could be due to some system glitch/incompatibility.
So I'm back to (and will stay with) the well known and trusty dd.
If there's anything I should look into, please advise.
Thanks in advance,
A.
#1647 Re: ARM Builds » ascii installer-ARM64 question » 2020-05-08 10:42:11
Hello:
If you find a very low power harddrive ...
I came across a drive made an PATA model by Transcend.
Could be used with any old USB to 2.5" IDE adaptor.
The specs are these:
2.5" PATA SSD
TS32GPSD330
---
Capacities vary from 32Gb to 128Gb
---
DC +5V 0.3A <-------- This
https://www.transcend-info.com/Embedded/Products/No-836
I don't know if their SATA SSD drives have the same power spec.
https://www.transcend-info.com/Search.aspx?q=sata+2.5
Cheers,
A.
#1648 Re: Hardware & System Configuration » Raspberry Pi 3B+ and USB HDD shutdown » 2020-05-07 18:17:52
Hello:
... use halt -p, that should close files & unmount before ...
Like I mentioned I use sudo shutdown -h now.
If I do sudo halt -p it will have (it has) the same effect I describe in my OP (as far as I know) as they are mostly the same.
ie: shutdown -h = shutdown --halt
... microSDHC card to boot from plus a HDD as / ...
Yes, that is exactly what I am doing.
... has the bootfs on a 2.0Gb SD card and the rest of the system on a 40Gb IDE HDD ...
Thanks a lot for your input.
Cheers,
A.
#1649 Hardware & System Configuration » Raspberry Pi 3B+ and USB HDD shutdown » 2020-05-05 23:03:09
- Altoid
- Replies: 4
Hello:
I'm currently in the process of setting up the hardware for a Raspberry Pi 3B+ that has the bootfs on a 2.0Gb SD card and the rest of the system on a 40Gb IDE HDD on a USB2.0 controller.
Works just fine (for the moment and only on SSH) and won't know how my coffee roasting software will do till I receive a presently stuck-in-the-mail HDMI-VGA adaptor for the 15" LCD screen I will use.
The previous HDD I used went south after a short stint as a RPi HDD and I was wondering if the way the RPi shuts down had anything to do with it.
ie: when I do sudo shutdown -h now, I notice that power to the HDD is cut out within three maybe four seconds but the amber LED on the board keeps flashing for another five to seven seconds.
Now, I would not have noticed this sequence had it not been for the short high pitched screech/whine of the drive coming to a halt.
I used these drives quite a bit to make backups and move image files between MS systems (mostly W98, NT4,W2000) and don't recall (it was long ago) that drive whine on disconnect, but maybe I've just forgotten. (?)
It won't much be of a problem if yet another resucitated HDD gives up the ghost but I'd hate that it were for something that could be avoided.
eg: spin down the drive before cutting off power to the USB port instead of directly cutting off power to the USB port?
I say this because I think the RPi was not designed to work with HDDs and I have the idea that the HDD is being handled like a SD card.
But then I don't think SD cards were designed for HDD duty but to be used in cameras and similar equipment where files are large and usually stay put to be read multiple times once generated, so it would seem that the RPi / SD card match is not a good one either.
Any ideas on how to do this?
Thanks in advance,
A.
#1650 Re: Installation » [Solved] Swap partition: swapon error and priority » 2020-05-05 12:23:34
Hello:
... the etc/fstab file for extra spaces.
Wrote the Devuan ascii *.img files to the SD card and another 40Gb HDD, then made the modifications mentioned in my OP.
You can see the instructions in a video here.
Changed the size of the swap partition, was a bit overboard.
Will try with 3.0Gb and see how it goes when I run the coffee roasting software as 1Gb RAM is rather tight.
groucho@devuan:~$ cat /etc/fstab
# <file system> <mount point> <type> <options> <dump><pass>
# bootfs
# was /dev/mmcblk0p1
UUID=EEA4-304A /boot vfat defaults 0 1
# root on HDD - was /dev/sda2
UUID=589c7999-62be-47ac-8847-32b62fd9fdc9 / ext4 defaults,noatime 0 1
# /var/log on HDD - was /dev/sda5
UUID=80f008d9-7f6e-49d2-8df7-d370a02be5df /var/log ext4 defaults,noatime 0 1
# /home on HDD - was /dev/sda6
UUID=58b362ef-c02d-45c0-8085-dc3996a7d947 /home ext4 defaults,noatime 0 2
# /swap - was /dev/sda7
UUID=5535c86a-ff6f-46d2-a53b-bad0f38d23fc none swap defaults 0 0
## blkid as of 20200505
# 2.0Gb SD card
# /dev/mmcblk0: PTUUID="ac806f8a" PTTYPE="dos"
# /dev/mmcblk0p1: SEC_TYPE="msdos" UUID="EEA4-304A" TYPE="vfat" PARTUUID="ac806f8a-01"
# /dev/mmcblk0p2: UUID="589c7999-62be-47ac-8847-32b62fd9fdc9" TYPE="ext4" PARTUUID="ac806f8a-02"
#
# 40Gb HDD
# /dev/sda1: SEC_TYPE="msdos" UUID="EEA4-304A" TYPE="vfat" PARTUUID="d34db33f-01"
# /dev/sda2: UUID="589c7999-62be-47ac-8847-32b62fd9fdc9" TYPE="ext4" PARTUUID="d34db33f-02"
# /dev/sda5: LABEL="log" UUID="80f008d9-7f6e-49d2-8df7-d370a02be5df" TYPE="ext4" PARTUUID="d34db33f-05"
# /dev/sda6: LABEL="home" UUID="58b362ef-c02d-45c0-8085-dc3996a7d947" TYPE="ext4" PARTUUID="d34db33f-06"
# /dev/sda7: LABEL="swap" UUID="5535c86a-ff6f-46d2-a53b-bad0f38d23fc" TYPE="swap" PARTUUID="d34db33f-07"
groucho@devuan:~$ I have found it to be a good idea to keep a (dated and commented) output of blkid in the /etc/fstab file.
Keeps everything on the same page when needing to edit or check it.
root@devuan:/home/groucho# findmnt --verify --verbose
/boot
[ ] target exists
[ ] UUID=EEA4-304A translated to /dev/sda1
[ ] source /dev/sda1 exists
[ ] FS type is vfat
/
[ ] target exists
[ ] VFS options: noatime
[ ] UUID=589c7999-62be-47ac-8847-32b62fd9fdc9 translated to /dev/sda2
[ ] source /dev/sda2 exists
[ ] FS type is ext4
/var/log
[ ] target exists
[ ] VFS options: noatime
[ ] UUID=80f008d9-7f6e-49d2-8df7-d370a02be5df translated to /dev/sda5
[ ] source /dev/sda5 exists
[ ] FS type is ext4
/home
[ ] target exists
[ ] VFS options: noatime
[ ] UUID=58b362ef-c02d-45c0-8085-dc3996a7d947 translated to /dev/sda6
[ ] source /dev/sda6 exists
[ ] FS type is ext4
none
[ ] UUID=5535c86a-ff6f-46d2-a53b-bad0f38d23fc translated to /dev/sda7
[ ] source /dev/sda7 exists
[ ] FS type is swap
Success, no errors or warnings detected
root@devuan:/home/groucho# The warnings issued by findmnt --verify --verbose were permission related.
Must be run as root or without the --verbose modifier.
Had nothing to do with update-initramfs -u. 8^7
root@devuan:/home/groucho# fdisk -l
--- snip ---
Disk /dev/mmcblk0: 1.9 GiB, 1990197248 bytes, 3887104 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xac806f8a
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 2048 264191 262144 128M c W95 FAT32 (LBA)
/dev/mmcblk0p2 264192 3872767 3608576 1.7G 83 Linux
Disk /dev/sda: 37.3 GiB, 40060403712 bytes, 78242976 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xd34db33f
Device Boot Start End Sectors Size Id Type
/dev/sda1 2048 264191 262144 128M c W95 FAT32 (LBA)
/dev/sda2 264192 14942207 14678016 7G 83 Linux
/dev/sda3 14942208 78241791 63299584 30.2G 5 Extended
/dev/sda5 14944256 17041407 2097152 1G 83 Linux
/dev/sda6 17043456 71948287 54904832 26.2G 83 Linux
/dev/sda7 71950336 78241791 6291456 3G 82 Linux swap / Solaris
root@devuan:/home/groucho# root@devuan:/home/groucho# swapon -s
Filename Type Size Used Priority
/dev/sda7 partition 3145724 0 -2
root@devuan:/home/groucho# root@devuan:/home/groucho# swapon -a
root@devuan:/home/groucho# As for the swapon -a parse error, it remains a mystery.
When confronted by something like that again, maybe the MS way is better.
ie: delete and rewrite the line. 8^°
Now to finish the install and do some housekeeping (host name, user, sudoers.d, etc.)
I have another doubt I must address but will do so in a different thread.
Thanks a lot to everyone who helped out with this.
Cheers,
A.
Board footer
