You are not logged in.
Hi,
this morning I installed Devuan Beowul 3.0 on the SSD of my Raspberry Pi 4 -- man, what happy I am haveing found a distro
without systemd! Oh, yeah!
One little problem:
What works:
Connect the Raspi via ethernet cable with my Fritz!Box
Boot the Raspi
nmap shows two ip-addresses related to the Raspi, on both sshd is running and useable.
What does not work:
Disconnect the Raspi from the Fritz!Box
Boot the Raspi
nmap shows the ip-address related to wlan0...but all ports are closed - no sshd deamon is running.
I searched the internet and as far as I can tell...this kind of problem isn't new and I am not alone.
But the solutions, which sound reasonable, didn't work for me
These were:
Add
ifdown eth0
/etc/init.d/ssh restart
to rc.local
Add
IPQoS cs0 cs0
at the end of sshd_config
I /think/ (read: I don't know for shure) that sshd is started while the wlan-connection is not fully established and a
retry is not possible or enabled...
Unfortunately I have no idea how to circumvent this ... if it is the case at all...
How can I fix this?
Cheers!
mcc
Offline
Wow, this all sounds so wrong.
ifup/down works with interfaces that are configured in /etc/network/interfaces
ssh starts and stops according to the links in /etc/rc?.d which are defined in the init script, /etc/init.d/ssh. It does not care about ip addresses or interfaces. Check your system logs to see if you can figure out why ssh is not running.
If you're going to always use wireless on this device with the same local network, you could set up a static ip in /etc/network/interfaces. If you have any network management software installed (n-m, wicd, connman, etc.) you should remove it so it doesn't fight with your static config.
Offline
Hi,
thanks for your reply
Wow, this all sounds so wrong.
...it is nearly identical to what is offered via the download repo for ARM64 Devuan Beowulf 3.00
(regarding to the problem I reported).
ssh starts and stops according to the links in /etc/rc?.d which are defined in the init script, /etc/init.d/ssh
yepp...is known.
Check your system logs to see if you can figure out why ssh is not running.
...guess what I tried to figure out and what I grepped through....
I am using a Fritz!Box 7490, with which I assigned a "static" IP address to a certain MAC/interface (that is: Wifi in this case) combo.
Everything is working fine....if the ethernet cable is plugged in. "Wlan only" works, but sshd does not start. I can ping/nmap the
according IP-addr. but there is no port opened by sshd (check with nmap via my Linux PC).
If the downloadable image (see above) came with no network management software installed...then there is none installed.
If there is a default network management software installed by default, I would suggest to remove it from the image, if
the result is what I experience at the moment.
As said, the problem described can be found threads back in 2016 (and earlier?)...but no solution suggested has worked for me so far.
Additional effect:
If I plug the network cable into my Raspi and boot it I get two different IP addr to login
one via cable, one via wlan0.
When logged into both on two different terminals and do a ifdown eth0 on the one connected via cable it kills the other one
instantanously (not only sshd is killed but the according IP addr. also vanishes.
May be this will offer a clue...?
Cheers
mcc
Offline
I've never played with arm images, so I guess that's why this problem seems so foreign to me. Please say exactly which iso or image you used. If you'd like, I could move this thread to the arm section of the forum where it might get more attention (from someone who knows more about arm than I do).
When I suggested setting up static ip for the pi, I meant in /etc/network/interfaces. Setting it up on an external device won't do anything to bring up the interface, it will only allow it to have an address when it asks for one. Is there anything other than the loopback entry in the interfaces file?
dpkg -l |egrep "network-manager|connman|wicd|ceni"
will tell if one of those is installed.
Offline
Hi,
thanks a lot for your help, fsmithred!
dpkg -l |egrep "network-manager|connman|wicd|ceni"
does not result in anything.
The image I downloaded:
Raspberry_Pi_Devuan_beowulf_arm64_ext4_root_password_is_root.img.xz
which I installed via my Gentoo PC with this command
root> xzcat Raspberry_Pi_Devuan_beowulf_arm64_ext4_root_password_is_root.img.xz > /dev/sdb
(/dev/sdb is the device of the SSD, which I normally attach to my Raspberry 4.
It had booted without any problems (at that moment it was connected via cable with my Fritz!Box) and instantly shows
an open port for sshd (visible via nmap on my PC).
I installed some "convenience stuff" (htop, neovim and other stuff I am used to use) but nothing related to the problem I posted.
Then I tried to setup wlan0...which also seems to work instantly...until I removed the RJ45 plug from my Raspi....
/etc/network/interfaces.d/wlan0 (a file)
defines the SSID and PSK for my AP...configurations I found under /etc/wpa_supplicant/wpa_supplicant.conf at distributions other than
the Devuan image I am using here.
/etc/network/interfaces
has this contents:
source-directory /etc/network/interfaces.d
auto eth0
iface eth0 inet dhcp
If you can move this thread somewhere else, where it is better placed, I would be the last one, who contradicts...
Only question: Will be there a link...so I can find it faster than with "linear search"
Thanks for all you help!
Cheers
mcc
Offline
I can imagine at least one scenario where the reported behaviour would be a natural consequence: namely when there are 2 different IP networks over a single Ethernet (broadcast) network
the one IP network that includes your Fritz!Box as well as the eth0 interface of Pi4, and
another IP network for the wlan0 interface of Pi4, visible to Fritz!Box via the wireless router's routing.
the router bridges the networks into a single Ethernet broadcast network
That setup could explain the observations that an ssh connection targeting the wlan0 interface IP requires the eth0 cable in place, as well as that wlan0 appears for nmap from Fritz!Box but without services if the cable is disconnected.
The issue concerns the return traffic: i.e., the network packets that should go back from sshd to the Fritz!Box IP.
I'm then postulating that your wlan0 configuration does not have any route management, and that therefore Pi4 does not know how to send packets to the Fritz!Box IP unless the eth0 cable is connected.
The eth0 configuration as shown results in both a "network route" for the network of eth0 and (most likely) a "default route" as well through eth0. The wlan0 configuration (not shown) at a guess only resluts in a "network route" for the wlan0 network. Thus, without the cable, the Pi4 does not know where to send IP packets other than those of the wlan0 network.
If that's not your scenarion the issue would probably still be the routing and the way the routing table is manipulated when a cable is disconnected (and connected).
The solution would be to ensure that the routing table is managed appropriately for the 4 different setups: (with or without) * (eth0 or wlan0)
Online
When a service starts listening on 0.0.0.0, it will listen on available ips,at that time,
If something come up after that, it will not listen on it.. and for the service to listen on then, a reload of the service is required..
This usually happens when you start a network service, and later plug-in a Ethernet cable,
In this case, you will need to reload the network service so that it can listen on the new ip address that you connected later..
Since probably you are listening on 0.0.0.0, this could be the case, in your case you are listening on 127.0.0.1 only( because wlan0 doesn't come up yet.. by some reason..).
You should configure wlan on /etc/network/interfaces
Also test it!
connect a serial adapter, login via serial( without any Ethernet cable connected.. only wireless! )
Ensure that ssh is listening on 0.0.0.0..
Take some time until wlan0 comes up for sure.., and then issue:
nc -nzv -w 1 wlan0.ip 22
nc -nzv -w 1 127.0.0.1 22
If you get sshd open on wlan0.ip,
This means that when sshd cames up, you already had wlan0 configured, and so, you don't have this problem I am speaking of..
And probably you have problems related with what fsmithred, ralph.ronnquist, told above..
If only 127.0.0.1:22 is open, then sshd started before you had wlan0 fully up..
Best Regards,
tux
Offline
A quick "question in between"...
I searched the internet for informations, how to attach an USB-Serial-Adapter to a Raspberry Pi 4B.
I this...mainly confusion (at least for a non-native speaker):
https://www.raspberrypi.org/documentati … on/uart.md
Primary UART/firsy UART are different is PL011 is Bluetooth and not wireless - at least for the
Raspberry 3...but only on the Pin header... WHAT?
Then raspi-config is often mentioned....on Devuan there is no raspi-config.
Furthermore:
/boot/config.txt is to be modified...
My /boot looks like this:
beowulf-arm64-20201017:/root>ls -l /boot
total 100107
-rw-r--r-- 1 root root 245879 Sep 26 19:31 config-5.8.0-0.bpo.2-arm64
-rw-r--r-- 1 root root 248519 Dec 31 16:19 config-5.9.0-0.bpo.5-arm64
drwxr-xr-x 2 root root 2560 Jan 1 1970 firmware
-rw-r--r-- 1 root root 28332431 Oct 16 17:26 initrd.img-5.8.0-0.bpo.2-arm64
-rw-r--r-- 1 root root 28841876 Jan 27 11:06 initrd.img-5.9.0-0.bpo.5-arm64
-rw-r--r-- 1 root root 83 Sep 26 19:31 System.map-5.8.0-0.bpo.2-arm64
-rw-r--r-- 1 root root 83 Dec 31 16:19 System.map-5.9.0-0.bpo.5-arm64
-rw-r--r-- 1 root root 22159216 Sep 26 19:31 vmlinuz-5.8.0-0.bpo.2-arm64
-rw-r--r-- 1 root root 22656880 Dec 31 16:19 vmlinuz-5.9.0-0.bpo.5-arm64
and /boot/firmware :
beowulf-arm64-20201017:/root>ls -l /boot/firmware
total 121407
-rwxr-xr-x 1 root root 23435 Jan 27 11:06 bcm2711-rpi-4-b.dtb
-rwxr-xr-x 1 root root 13990 Jan 27 11:06 bcm2837-rpi-3-a-plus.dtb
-rwxr-xr-x 1 root root 14250 Jan 27 11:06 bcm2837-rpi-3-b.dtb
-rwxr-xr-x 1 root root 14622 Jan 27 11:06 bcm2837-rpi-3-b-plus.dtb
-rwxr-xr-x 1 root root 13624 Jan 27 11:06 bcm2837-rpi-cm3-io3.dtb
-rwxr-xr-x 1 root root 52480 Oct 16 17:21 bootcode.bin
-rwxr-xr-x 1 root root 110 Jan 27 11:06 cmdline.txt
-rwxr-xr-x 1 root root 286 Jan 27 11:06 config.txt
-rwxr-xr-x 1 root root 3146 Oct 16 17:21 fixup4cd.dat
-rwxr-xr-x 1 root root 5405 Oct 16 17:21 fixup4.dat
-rwxr-xr-x 1 root root 8417 Oct 16 17:21 fixup4db.dat
-rwxr-xr-x 1 root root 8419 Oct 16 17:21 fixup4x.dat
-rwxr-xr-x 1 root root 2663 Oct 16 17:21 fixup_cd.dat
-rwxr-xr-x 1 root root 6746 Oct 16 17:21 fixup.dat
-rwxr-xr-x 1 root root 9820 Oct 16 17:21 fixup_db.dat
-rwxr-xr-x 1 root root 9818 Oct 16 17:21 fixup_x.dat
-rwxr-xr-x 1 root root 28332431 Oct 16 17:26 initrd.img-5.8.0-0.bpo.2-arm64
-rwxr-xr-x 1 root root 28841876 Jan 27 11:06 initrd.img-5.9.0-0.bpo.5-arm64
-rwxr-xr-x 1 root root 816124 Oct 16 17:21 start4cd.elf
-rwxr-xr-x 1 root root 3774532 Oct 16 17:21 start4db.elf
-rwxr-xr-x 1 root root 2272992 Oct 16 17:21 start4.elf
-rwxr-xr-x 1 root root 3031652 Oct 16 17:21 start4x.elf
-rwxr-xr-x 1 root root 694052 Oct 16 17:21 start_cd.elf
-rwxr-xr-x 1 root root 4861512 Oct 16 17:21 start_db.elf
-rwxr-xr-x 1 root root 2884708 Oct 16 17:21 start.elf
-rwxr-xr-x 1 root root 3799144 Oct 16 17:21 start_x.elf
-rwxr-xr-x 1 root root 22159216 Oct 16 17:26 vmlinuz-5.8.0-0.bpo.2-arm64
-rwxr-xr-x 1 root root 22656880 Jan 27 11:06 vmlinuz-5.9.0-0.bpo.5-arm64
there are a much lesser files found under /boot/* with Devuan as with Raspbian OS
(which has partly outdated software and uses systemd/pulseaudio...one reason, why I am here... )
Next:
Jan 28 05:32:11 beowulf-arm64-20201017 kernel: [ 0.000000] [Firmware Bug]: Kernel image misaligned at boot, please fix your bootloader!
Jan 28 05:32:11 beowulf-arm64-20201017 kernel: [ 0.000000] Reserved memory: created CMA memory pool at 0x0000000037000000, size 64 MiB
Jan 28 05:32:11 beowulf-arm64-20201017 kernel: [ 0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
taken from /var/log/syslog...my Raspberry Pi 4B has the latest stable bootloader (flashed via Raspbian OS).
I can't find a tool to update/change the bootloader with Devuan...
Ok, ... I don't want to hijack my own thread...but it seems, that essential parts of the installation are missing somehow.
Did I miss to install something, which fixes the above issues?
I found this while trying to setup UART0...
Cheers!
mcc
Offline
hello mcc,
For what I see Primary UART is the one to be used by linux
Enable the uart in RaspberryPI config.txt
enable_uart=1
it should appear( after raspberrypi boots up.. ) as /dev/ttyAMA0
Put a login tty on RaspberryPi in /etc/initab
T0:23:respawn:/sbin/agetty -L ttyAMA0 115200 vt100
Now shutdown your Rpi, and remove Power Supply from it..
UART GPIO Pins:
6 - GND
8 - TX
10 - RX
How to Connect to serial adapter to RaspberryPI uart:
Is very important to connect the pins in a correct way..
You should only connect Ground, TX,RX..
How to connect:
The Board has:
1)GND
2)TX
3)RX
The usb-serial adapter has( at least):
1)GND
2)TX
3)RX
So you connect:
1) Insert usb adapter in your PC computer
2) connect the pins, from rpi with serial adapter
The ground from adapter with ground from the board
The TX from adapter with RX from the board
The RX from adapter with TX from the board
3) Use a serial adapter application like 'picocom', for example, or other and start it, and issue in the PC:
find the usb /dev/serial.device in the pc
ls -ltr /dev/*USB*
Now use the serial device you found in dmesg..
picocom /dev/serial.device -b 115200
4) Only then, you apply power to the SBC board
After this you should see the output in the serial console output in your pc, and later a login tty
Last edited by tuxd3v (2021-01-28 20:38:59)
Best Regards,
tux
Offline
Not to brag or anything like this, but I do have some images available over here - https://github.com/pyavitz/rpi-img-buil … tag/images
Pretty sure all this business works.
Offline
Hi c0rnelius,
no,no,no...everything is fine and really welcome....the reason: my Serial-USB adaptor died this morning (or more exactly: It
was already dead).
So I am very happy, that you provide all these images...and how up-to-date they are !
Updateing the system installed just sudo ... that's it!
NICE, REALLY NICE!
NOW the weekend can come! ( <<< hopefully that's not too much of germ-english wording...
Thanks, Sir! -- you saved my next three days...at least!
Cheers!
mcc
Offline
Hi,
I came across one thing, which makes me wondering...:
This page
https://www.devuan.org/os/documentation … owulf.html
says:
deb http://deb.devuan.org/merged beowulf main
deb http://deb.devuan.org/merged beowulf-updates main
deb http://deb.devuan.org/merged beowulf-security main
#deb http://deb.devuan.org/merged beowulf-backports main
should be entered when updateing/upgradeing to Beowulf from another Devuan system.
That is: The "final target" is Devuan Beowulf.
The image offered by c0rnelius, which already "is the target" (sorry for struggling with words here) is in
its sources.list:
deb ]http://deb.devuan.org/merged beowulf main contrib non-free
deb http://deb.devuan.org/merged beowulf-updates main contrib non-free
deb http://deb.devuan.org/merged beowulf-security main contrib non-free
deb http://deb.devuan.org/merged beowulf-backports main contrib non-free
which is somehow different for the my naked eye.
Do I need to change anything (one reason for changeing away from Raspberian was the somehow
outdated software of it)?
Cheers!
mcc
Last edited by mcc (2021-01-29 15:19:40)
Offline
Hi,
One little problem:
What works:
Connect the Raspi via ethernet cable with my Fritz!Box
Boot the Raspi
nmap shows two ip-addresses related to the Raspi, on both sshd is running and useable.What does not work:
Disconnect the Raspi from the Fritz!Box
Boot the Raspi
nmap shows the ip-address related to wlan0...but all ports are closed - no sshd deamon is running.I searched the internet and as far as I can tell...this kind of problem isn't new and I am not alone.
.....How can I fix this?
err.. i just will jump to response that wlan0 does not reply to nothing until from that target you reply to that client... yeah very rare but is since Debian 8 so is not problem of Devuan..
i mean.. i have two connections.. eth0 and wlan0.. started ssh and deactivate the eth0 .. does not care order .. just i only have wlan0
if i try to access from another client using ping it not reponds ..
but if i send ping to cleint from raaspi .. using wlan0, to client.. now the client can connect and use any of the services of the host remote!
Offline
If you have a routing problem try sudo route -n on the pi *and* on your other system both when the ethernet cable is plugged in and when it's not. If you can't work out how to fix it after reading the man page for route then post all the output here.
I'm not an expert but I have managed to fix a few routing problems. Although mostly by guesswork.
Chris
Offline