POGO-V4-A3-01 + 2017.07 U-Boot Kirkwood + Debian 5.2.9 rootfs

I have searched the forum if someone else has had difficulty to access Pogoplug v4 (POGO-V4-A3-01) via ssh as root. I keep getting connection refused from Debian and I have run out of ideas on how to enable ssh root access. Hence this post.

user@desktop:~$ ssh root@<POGO-V4-A3-01 ip address>
ssh: connect to host <POGO-V4-A3-01 ip address> port 22: Connection refused

I am using the standard rootfs Debian-5.2.9-kirkwood-tld-1-rootfs-bodhi.tar.bz2[link], where everything is from scratch. It clearly states that root password is "root", so it should work to ssh to it as root, like with rootfs Debian-4.12.1-kirkwood-tld-1-rootfs-bodhi.tar.bz2.

I also read in other Debian forums that Debian Buster has disabled the root ssh login and that you have to edit

/etc/sshd/sshd_config

in a certain way so that you can access via ssh, right after a fresh Debian install. But I am sure that ssh would be enabled from start on rootfs Debian-5.2.9-kirkwood-tld-1-rootfs-bodhi.tar.bz2.

I have also seen some users on the forum being able to pipe the Debian boot information on stdout tty to netcat, just like the first part of the boot sequence can be piped to netcat listening server.

I wonder how you can adjust the Debian rootfs to send the stdout messages that usually come on a screen during boot and startup via netcat instead, to a listening netcat server executing command

user@desktop:~$ nc -k -l -u -p 6666

• Are others experiencing a similar issue?
• How did you solve it?
• Why is this happening, does anyone have any ideas?

It seems that after apt upgrade command, some things have changed. TCP port 2222 is showing up as open all of a sudden (I didn't change anything), but standard port for ssh [port 22] which worked before is closed and probably causes the refusal.

PORT         STATE       SERVICE
80/tcp       open        http
2222/tcp     open        EtherNet/IP-1

The question is if ssh is running, on which port and what the "new" ssh command is to login to the Pogoplug v4. It could be that ciphering has changed somehow, that the keys need to be regenerated for the users before reboot.

Tried to also create a new user "dummy" in case "root" is not allowed anymore to ssh into Debian Buster.

user@desktop:~$ ssh -p 2222 dummy@<POGO-V4-A3-01 ip address>
dummy@<POGO-V4-A3-01 ip address>'s password: 
Permission denied, please try again.
user@desktop:~$ ssh -p 2222 root@<POGO-V4-A3-01 ip address>
root@<POGO-V4-A3-01 ip address>'s password: 
Permission denied, please try again.

Correct password is constantly rejected.

Some forums suggest there has been an update in OpenSSH that somehow breaks things that used to work before. This post is quite similar to what I see is happening.

I tried to start with rootfs Debian-4.12.1-kirkwood-tld-1-rootfs-bodhi.tar.bz2 and upgrade it to Debian Buster step by step, and the same behavior is observed. I tried to connect with Putty as well instead of with OpenSSH client. Same refusal of connection.

I am using an Ubuntu 20.04 desktop to connect from with latest upgrade.



Edited 5 time(s). Last edit at 05/27/2020 02:07PM by chaos.

chaos,

> I keep getting connection refused
> from Debian and I have run out of ideas on how to
> enable ssh root access. Hence this post.

> I am using the standard rootfs
> Debian-5.2.9-kirkwood-tld-1-rootfs-bodhi.tar.bz2[link],
> where everything is from scratch. It clearly
> states that root password is "root", so it should
> work to ssh to it as root, like with rootfs
> Debian-4.12.1-kirkwood-tld-1-rootfs-bodhi.tar.bz2.

Yes. Debian-5.2.9-kirkwood-tld-1-rootfs-bodhi.tar.bz2 should work without changing anything (the OpenSSH issue is not applicable to this rootfs).

Most of the time when you see SSH refused connection is that the box has booted past the point where SSH has started running. But the Debian has not finished the init boot sequence. For example, if /etc/rc.local is stuck. Or some errors that made the boot process stuck, eg. the rootfs is being fixed by fsck.

So the first thing to do is to take it to the Ubuntu box and do

e2fsck /dev/sdb1   # if the rootf drive was assigned as /dev/sdb1 by Ubuntu

If you see errors, then most likely that was the reason.

Other possible reason: when you untar the basic rootfs Debian-5.2.9-kirkwood-tld-1-rootfs-bodhi.tar.bz2, you were not root user.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 05/27/2020 05:35PM by bodhi.

I did not see this

Quote

I tried to start with rootfs Debian-4.12.1-kirkwood-tld-1-rootfs-bodhi.tar.bz2 and upgrade it to Debian Buster step by step, and the same behavior is observed. I tried to connect with Putty as well instead of with OpenSSH client. Same refusal of connection.

In this case, when you upgrade, you should take the default answer when ask if you want to replace the config files for SSH. Meaning do you want to use the existing configs, not the update ones.

So from Stretch to Buster:

apt-get dist-upgrade

And answer that you want to keep the current configs for each time you are asked to choose.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 05/27/2020 05:37PM by bodhi.

I tried all of the above.

I also made very sure I was root (learned that the hard way a while ago).

I did, once again, try to update the working 4.12.1 rootfs from scratch to latest version on Debian Stretch.

Now, the ssh login problem begins once Debian is updated with

apt-get update && apt-get upgrade

even on Debian Stretch. I don't even have to upgrade to Debian 10 to see the ssh authentication error.

The question is what may cause this ssl authentication error.

I also added another user to test if it is just the root or any user who has problems.

I did try all the ciphering, KexAlgorithms and hmac versions that should do the trick. Even edited the

/etc/ssh/sshd_config

according to this guide. But no success.

I am puzzled about what in the upgrade, all by itself, closes the ssh port 22 and instead a port on 2222 appears when you run nmap on the <POGO-V4-A3-01 ip address>.

user@desktop:~$  nmap <POGO-V4-A3-01 ip address>
Starting Nmap 7.80
Nmap scan report for <POGO-V4-A3-01 ip address>
Host is up.
PORT     STATE SERVICE
111/tcp  open  rpcbind
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
2222/tcp open  EtherNetIP-1

Rootfs 4.12.1 shows this:

user@desktop:~$  nmap <POGO-V4-A3-01 ip address>
Starting Nmap 7.80
Nmap scan report for <POGO-V4-A3-01 ip address>
Host is up.
PORT     STATE SERVICE
22/tcp  open  ssh
111/tcp open  rpcbind

I have tried other kernels as well, (4.17 and 4.20) and the same ssh authentication error occurs there.

Is it possible to create a netcat connection from a booting Debian tty so that I can see what is happening on the POGO v4, although currently ssh connection is not allowed by Debian 10?

Could it be that it is the openssh client on Ubuntu 20.04 that is not able to communicate with the ssh server on the POGO v4 and decide on a ciphering? But that doesn't answer why the port 22 is closed. It shouldn't close after a Debian Stretch upgrade.



Edited 3 time(s). Last edit at 06/01/2020 10:32AM by chaos.

chaos,

Quote

Is it possible to create a netcat connection from a booting Debian tty so that I can see what is happening on the POGO v4, although currently ssh connection is not allowed by Debian 10?

Unfortunately this did not work when I tried. I did not try very hard. But I think the serial tty interfered and I don't want to turn it off. Serial console is too important.

Possibilities:

- root user: you took care of that.
- sshd config
- rootfs corrupted: you took care of that.

SO try again, after the upgrade, copy and post your sshd config here. Or you can mount the rootfs on Ubuntu, and post the current one on the rootfs.

BTW, this problem can be solved quite easily with serial console connected.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

After hours of investigation this issue, it seems absolutely clear that there has been significant changes/updates to openssh-server, ssh-keygen and openssh-client that basically require a complete uninstall of those packages "apt-get --purge remove openssh-server openssh-client", "apt autoremove" and "apt clean" the system. Then one need to reinstall openssh-server "apt-get install openssh-server", add some heavy duty new keys that are now required, edit the /etc/ssh/sshd_config which has been completely renewed in the process to suit the needs. To keep ssh on port 22, one has to force the port to 22. It will default to 2222 otherwise.

Another issue related to this is the need of a linux swap file. Sometimes, during the upgrades, there is not enough space to perform the upgrade. Adding 128MB of linux swap file solves the problem. It has also been useful to set up a cron service to check every minute it there is little free memory and free up as much memory as possible regularly.

I will update this post with a working solution upgrade from 4.12.1 rootfs all the way to latest Debian Buster with kernel 5.6.5 once I get it working. In my case, I can only start with rootfs 4.12.1 which allows ssh login as root. rootfs 5.2.9 won't allow me to ssh to the server as root.

I suspect that a new rootfs is needed that contains the updated openssh-server with all the heavy duty keys that are now needed. That is probably why rootfs 5.2.9 doesn't work for me from scratch on a new usb-stick. The keys that are on rootfs 5.2.9 are probably no longer allowed. Since some security upgrading takes place in the background, you have no control over what the system does all by itself, but the result may be that you won't be able (like in my case) to login through ssh. rootfs 4.12.1 doesn't seem to have that issue from scratch, but as soon as you do apt-get update && apt-get upgrade and forget to fix the openssh-server issue, you won't be allowed to ssh in as root again. Indeed a good trap. Some forums suggest that it is not the first time an openssh-server upgrade totally breaks a system since you can't login anymore. Therefore, it could be wise to have an eye open on openssh-server upgrades and not reboot until one is super sure it works as intended. Otherwise... one has to start from 4.12.1 again.

The new openssh-server does indeed block root ssh login by default and by default it seems to use port 2222 if not forced to port 22. RSA keys may no longer be allowed alltogether since they are easily hacked nowadays, but it seems RSA keys are allowed if made with flag 4096. These keys seem to work (not tested all yet) according to the url below:

ssh-keygen -t rsa -b 4096
ssh-keygen -t dsa
ssh-keygen -t ecdsa -b 521
ssh-keygen -t ed25519

See https://www.ssh.com/ssh/keygen/

Working solution

Some of these steps are totally unnecessary if everything works. But in case they don't it's wise to have a backup plan or two. I completely understand if someone says that some things make no sense, I can edit this instruction how I did it on my equipment.

Add a Linux swap partition to your system of 128 MB. A swap partition is sometimes needed when the server runs out of memory, for instance when updating intramfs. One way to remedy it is to leave 128MB at the end of your USB-stick and make this into a Linux Swap partition.

See https://devconnected.com/how-to-add-swap-space-on-debian-10-buster/

It is useful to setup a cron service that every minute cleans the memory as much as possible so that the installation processes have enough space.

See https://unix.stackexchange.com/questions/206353/cron-job-to-execute-command-on-low-memory

You can use a little script clean-memory to free up some memory.

cat <<EOF > /usr/local/bin/clean-memory
#!/bin/bash
echo "before cleaning"
free -m
sync
# su
echo 3 > /proc/sys/vm/drop_caches
echo "after cleaning"
free -m
EOF

chmod +x /usr/local/bin/clean-memory

Example:

root@debian:~# clean-memory
before cleaning
              total        used        free      shared  buff/cache   available
Mem:            114          19           9           1          85          88
Swap:           127           5         122
...

Add a sudo user ‘fixer’ as backup plan in case things fail.

apt-get install sudo members
useradd fixer
usermod -aG sudo fixer
id fixer

Test your user ‘fixer’:

su fixer
whoami
sudo whoami

It is usefull (as a backup plan) to add vsftp (simple ftp-server) monitored by xinetd. That way you can fix /etc/ssh/sshd_config file in case things don’t work.

See https://linuxconfig.org/how-to-setup-and-use-ftp-server-in-ubuntu-linux

apt-get install vsftpd xinetd

Create a file /etc/xinetd.d/vsftpd

cat <<EOF > /etc/xinetd.d/vsftpd
service ftp
{
        disable                 = no
        socket_type             = stream
        wait                    = no
        user                    = root
        server                  = /usr/sbin/vsftpd
        per_source              = 5
        instances               = 200
        no_access               = 10.1.1.10
        banner_fail             = /etc/vsftpd.busy
        log_on_success          += PID HOST DURATION
        log_on_failure          += HOST
}
EOF

Edit /etc/vsftpd.conf:

nano /etc/vsftpd.conf

Edit the FTP server's configuration file /etc/vsftpd.conf and change the following lines:

listen=YES
listen_ipv6=YES

to

listen=NO
listen_ipv6=NO

Save (Ctrl + O) and exit (Ctrl + X) from nano.

Restart vsftpd via xinetd.
inetd:

service vsftpd stop
service xinetd restart

systemd (I am not able to test this, but it should be something like this):

systemctl stop vsftpd.service
systemctl stop xinetd.service
systemctl start xinetd.service

To confirm that your FTP server started normally test and open port 21 with the netstat command:

netstat -ant | grep 21

Make this server be able to login as root (as a backup plan if things go bad) to fix files if needed. You can always remove vsftp or change these settings later when everything is up and running.

See https://serverfault.com/questions/34678/how-to-configure-vsftpd-to-allow-root-logins

DISCLAIMER: Enabling root login for FTP is a Very Bad Idea for many, many reasons. But in this case, what other options do we have if we don't have a serial cable ...

Edit your /etc/vsftpd.conf file, and add the following line:

userlist_deny=YES

Edit /etc/ftpusers and comment out "root".

nano /etc/ftpusers
...
#root
...

Comment out the line with root on it by placing a # at the start. Save the file, and reloading the server is not even necessary.

Edit /etc/vsftpd.user_list if you plan to use that setup.

See https://wiki.archlinux.org/index.php/Very_Secure_FTP_Daemon#Limiting_user_login

Quote

It's possible to prevent users from logging into the FTP server by adding two lines to /etc/vsftpd.conf:
userlist_enable=YES
userlist_file=/etc/vsftpd.user_list
userlist_file now specifies the file which lists users that are not able to login.
If you only want to allow certain users to login, add the line:
userlist_deny=NO
The file specified by userlist_file will now contain users that are able to login.

Now we are prepared for disasters and can try to fix the openssh-server authentication error.

Completely remove openssh-server and openssh-client.

apt-get --purge remove openssh-server openssh-client
apt autoremove
apt clean

Install openssh-server again.

apt-get install openssh-server

This will create all the keys needed.

Add some extra keys:

ssh-keygen -t rsa -b 4096
ssh-keygen -t dsa
ssh-keygen -t ecdsa -b 521
ssh-keygen -t ed25519

Edit the /etc/ssh/sshd_config file:
Find the location of the “Port 22” line and change it to:

# It is advisable to move away from port 22 and use other port,
# port 2222 or whatever is free, for instance port 331.
# to avoid brute force attack.
# openssh-server will choose port 2222 automatically if you don't uncomment 
# this port setting.
Port 22

Find the location of the line containing “PermitRootLogin” and change that line to this:

# To allow root login, uncomment the line PermitRootLogin and 
# set the value to yes:
PermitRootLogin yes
#PermitRootLogin prohibit-password

Restart openssh-server.
initd:

service ssh restart

systemd:

systemctl restart sshd.service

TEST IT THOROUGHLY so that it works! Otherwise, you will be locked out and have to start all over again.

Upgrade kernel to 5.6.5

cd /boot
cp -a uInitrd uInitrd-4.12.1
cp -a uImage uImage-4.12.1

See https://forum.doozan.com/read.php?2,12096

When kernel is updated:

cd /boot
cp -a uInitrd uInitrd-5.6.5
cp -a uImage uImage-5.6.5

Upgrade to Debian Buster (Debian 10)

Change stretch repo to buster repo

sed -i 's/stretch/buster/g' /etc/apt/sources.list
apt update && apt full-upgrade
apt autoremove
apt clean

You will get some errors:

Errors were encountered while processing:
 busybox-syslogd
E: Sub-process /usr/bin/dpkg returned an error code (1)

Just free up memory and run apt-get dist-upgrade two more times.

apt-get dist-upgrade

Setting up busybox-syslogd (1:1.30.1-4) ...
[....] Restarting busybox' syslogd implementation: syslogdStarting /sbin/syslogd
...
23962 (syslogd)
. ok 
[....] Restarting busybox' klogd implementation: klogdNo klogd found running; no
ne killed.
Starting /sbin/klogd...
24005 (klogd)
 failed! 
invoke-rc.d: initscript busybox-klogd, action "restart" failed.
dpkg: error processing package busybox-syslogd (--configure):
 installed busybox-syslogd package post-installation script subprocess returned 
error exit status 1
Errors were encountered while processing:
 busybox-syslogd
E: Sub-process /usr/bin/dpkg returned an error code (1)

apt-get dist-upgrade

Setting up busybox-syslogd (1:1.30.1-4) ...
[....] Restarting busybox' syslogd implementation: syslogdStarting /sbin/syslogd...
24066 (syslogd)
. ok  
[....] Restarting busybox' klogd implementation: klogdStopped klogd (pid 24005).
Starting /sbin/klogd...
24109 (klogd)
. ok

cd /boot
mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs-5.6.5-kirkwood-tld-1 -d initrd.img-5.6.5-kirkwood-tld-1 uInitrd

Restart openssh-server.
initd:

service ssh restart

systemd:

systemctl restart sshd.service

This is for safety and may not be needed. Better safe than sorry...

Completely remove openssh-server and openssh-client.

apt-get --purge remove openssh-server openssh-client
apt autoremove
apt-get autoclean
apt clean

Install openssh-server again.

apt-get install openssh-server
Setting up openssh-client (1:7.9p1-10+deb10u2) ...
Setting up openssh-sftp-server (1:7.9p1-10+deb10u2) ...
Setting up openssh-server (1:7.9p1-10+deb10u2) ...
...

This will create all the keys needed.
Add some extra keys:

ssh-keygen -t rsa -b 4096
ssh-keygen -t dsa
ssh-keygen -t ecdsa -b 521
ssh-keygen -t ed25519

Edit the /etc/ssh/sshd_config file:

nano /etc/ssh/sshd_config

Find the location of the “Port 22” line and change it to:

# It is advisable to move away from port 22 and use other port,
# port 2222 or whatever is free, for instance port 331.
# to avoid brute force attack.
# openssh-server will choose port 2222 automatically if you don't uncomment 
# this port setting.
Port 22

Find the location of the line containing “PermitRootLogin” and change that line to this:

# To allow root login, uncomment the line PermitRootLogin and 
# set the value to yes:
PermitRootLogin yes
#PermitRootLogin prohibit-password

Restart openssh-server.
initd:

service ssh restart

systemd:

systemctl restart sshd.service

cd /boot
mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs-5.6.5-kirkwood-tld-1 -d initrd.img-5.6.5-kirkwood-tld-1 uInitrd

cp -a uInitrd uInitrd-5.6.5
cp -a uImage uImage-5.6.5
sync
sync
sync
sync

TEST IT THOROUGHLY so that it works! Otherwise, you will be locked out and have to start all over again.
Try to ssh into the server.

ssh root@<POGO-V4-A3-01 ip address>
ssh fixer@<POGO-V4-A3-01 ip address>
ftp <POGO-V4-A3-01 ip address>
name: root or fixer
ssh root@<POGO-V4-A3-01 ip address> -p <the port you have setup>
ssh root@<POGO-V4-A3-01 ip address> -p 2222 # (default if you forgot to force it)

If you dare… reboot:

shutdown -r now

Wait about 1-2 minutes and run nmap

nmap <POGO-V4-A3-01 ip address>
nmap <POGO-V4-A3-01 ip address> -p 21-8000

Try to ssh into the server.

ssh root@<POGO-V4-A3-01 ip address>
ssh fixer@<POGO-V4-A3-01 ip address>
ftp <POGO-V4-A3-01 ip address>
name: root or fixer
ssh root@<POGO-V4-A3-01 ip address> -p <the port you have setup>
ssh root@<POGO-V4-A3-01 ip address> -p 2222 # (default if you forgot to force it)

It should now work as expected.
No more authentication errors.

root@debian:~# uname -r            
5.6.5-kirkwood-tld-1

root@debian:~# uname -a
Linux debian 5.6.5-kirkwood-tld-1 #1.0 PREEMPT Fri Apr 17 19:27:48 PDT 2020 armv5tel GNU/Linux

root@debian:~# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/";
SUPPORT_URL="https://www.debian.org/support";
BUG_REPORT_URL="https://bugs.debian.org/";

Edited 5 time(s). Last edit at 03/22/2022 03:20PM by chaos.

Quote

rootfs 5.2.9 won't allow me to ssh to the server as root.

That does not make sense to me at all.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Well, what can I say... I also assumed that it would just be ok to run rootfs 5.2.9 and at least be able to ssh into the POGO v4. But ... it doesn't ... probably because openssh-server has done some major changes which require the keys to be done again from scratch. There are several threads about this error (some of them dating 7 years back so it's not first time this happens) on the internet and the easiest solution to this unreasonable authentication error

Permission denied, please try again.

is to completely uninstall and reinstall openssh-server and openssh-client. After that, it suddenly works. Nobody understands why... but it works. Upgrading openssh-server creates the authentication error, so the only way to go is to uninstall and reinstall and add heavy duty keys just like I wrote. I ran this several times and it seems that RSA 2048 is still allowed, but openssh says they are thinking about dropping RSA altogether at a near point in future because it is easily hacked. 4096 seems to be better than 2048. For now 2048 RSA keys are generated when openssh-server is installed.

ssh-keygen -t rsa -b 4096

overwrites the 2048 key it seems...

I am not an ssh-pro but after several days of reading about it, I kind of got to the conclusion and tested it. It worked. That is why I propose to make a new rootfs for 5.6.5 where openssh-server is updated and the keys are

ssh-keygen -t rsa -b 4096
ssh-keygen -t dsa
ssh-keygen -t ecdsa -b 521
ssh-keygen -t ed25519

Then the rootfs would work from scratch I assume. Debian-based systems tend to run security updates all by themselves in the background, which could potentially disable to ssh-login in rootfs 5.2.9 right at boot. It is easily reproducible by installing 4.12.1 (or even 5.2.9 if you can ssh into it) and just run

apt-get update && apt-get upgrade
shutdown -r now

and you can't ssh as root anymore. Port 22 is gone. Port 2222 is up, but it doesn't accept root password (root) although it is correctly spelled.

chaos,

Thanks for spending the time to chase this problem.

> doesn't ... probably because openssh-server has
> done some major changes which require the keys to
> be done again from scratch. There are several
> threads about this error (some of them dating 7
> years back so it's not first time this happens) on
> the internet and the easiest solution to this
> unreasonable authentication error
>

> Permission denied, please try again.
>

> is to completely uninstall and reinstall
> openssh-server and openssh-client. After that, it
> suddenly works. Nobody understands why... but it
> works.

Let me do some test. And then tell you what I think happen.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

In the mean time, could you list this on your Ubuntu box;

uname -a
cat /etc/debian_version 
dpkg -l | grep -i ssh

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

chaos,

OK. I would like you to do this test.

1. Create the 5.2.9 rootfs gain. Mount it on Ubuntu while being root. Assuming it is mounted at media/sdb1.

2. Remove the keys

cd /media/sdb1/etc/ssh
rm ssh_host_*

3. Modify /media/sdb1/etc/rc.local (put it right after the comment below) to add the key generation command:

# By default this script does nothing.

# generate SSH key on 1st boot
ssh-keygen -A

and

sync

Now take the USB rootfs to the Pogo, power up.

4. Login from Ubuntu using ssh root@pogo_IP_address. You might need to clear the old keys on Ubuntu /root/.ssh/known_hosts.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Please note, that since I have reinstalled openssh-server and upgraded everything to latest Debian 10 Buster, I can't output the old values before I succeeded to upgrade it. Here comes the values that the current update Debian 10 system outputs.

I have also been very disobedient when it comes to not obeying your rule to use just one ext3 partition on the usb-stick. I tried formating the primary partition as ext4 first just to try if it boots, but it didn't boot, so I reverted to using ext3.

I added a second partition at the end of the usb-stick size 128MB which carries a Linux Swap partition on it (fdisk...type 82). This 128MB swap partition is then mounted via /etc/fstab. It seems it is not uncommon that it's needed at upgrades and install of new packages. Intramfs wont upgrade if you don't have a swap partition sometimes.

root@debian:~# uname -a
Linux debian 5.6.5-kirkwood-tld-1 #1.0 PREEMPT Fri Apr 17 19:27:48 PDT 2020 armv5tel GNU/Linux
root@debian:~# cat /etc/debian_version 
10.4
root@debian:~# dpkg -l | grep -i ssh
ii  openssh-blacklist                 0.4.1+nmu1                    all          list of default blacklisted OpenSSH RSA and DSA keys
ii  openssh-client                    1:7.9p1-10+deb10u2            armel        secure shell (SSH) client, for secure access to remote machines
ii  openssh-server                    1:7.9p1-10+deb10u2            armel        secure shell (SSH) server, for secure access from remote machines
ii  openssh-sftp-server               1:7.9p1-10+deb10u2            armel        secure shell (SSH) sftp server module, for SFTP access from remote machines

I will backup the working rootfs that I have before I try using your rootfs 5.2.9 as you last wrote. I don't want to destroy this system that I actually got working after so many hours. Will be back with an edited post once I managed to back it up.



Edited 1 time(s). Last edit at 06/03/2020 07:59AM by chaos.

I now tested the rootfs 5.2.9 with the keys removed and edited rc.local to generate new keys.

Now it works using rootfs 5.2.9 from scratch, like rootfs 4.12.1.

Seems the issue with rootfs 5.2.9 was that the authentication keys were wrong somehow.

I can also notice that openssh may have been upgraded since then, from
1:7.9p1-10
to
1:7.9p1-10+deb10u2

Still, it could be useful to create a whole new rootfs 5.6.5 once we know what the issue is.

I would also like to point out the probem with systemd not having enough space on tmpfs, so that it can't restart. Maybe there is a fix that could be incorporated in a new rootfs 5.6.5.

Sometimes, when you upgrade, you see a lot of perl warnings about locales not being set up properly. I have tried to solve it myself, it is not easy, but I am not sure how to solve locale warnings in a good way. Maybe setting up english US locale from scratch would make things nicer and easier from start and remove those warnings.

I would at least appreciate a thread about how to fix the perl locale warning in a good way. Maybe you could write a simple guide on how to fix it? What to put where in which files so that it disappears?

root@debian:~# uname -a
Linux debian 5.2.9-kirkwood-tld-1 #1 PREEMPT Sat Aug 17 15:00:56 PDT 2019 armv5tel GNU/Linux
root@debian:~# cat /etc/debian_version 
10.0
root@debian:~# dpkg -l | grep -i ssh
ii  openssh-blacklist                0.4.1+nmu1                    all          list of default blacklisted OpenSSH RSA and DSA keys
ii  openssh-client                   1:7.9p1-10                    armel        secure shell (SSH) client, for secure access to remote machines
ii  openssh-server                   1:7.9p1-10                    armel        secure shell (SSH) server, for secure access from remote machines
ii  openssh-sftp-server              1:7.9p1-10                    armel        secure shell (SSH) sftp server module, for SFTP access from remote machines

For your locale issue have you tried running the below command?

dpkg-reconfigure locales

chaos,

> I now tested the rootfs 5.2.9 with the keys
> removed and edited rc.local to generate new keys.
>
> Now it works using rootfs 5.2.9 from scratch, like
> rootfs 4.12.1.

That told me there is something peculiar in your Ubuntu system.

In the new post you also have some glitches with ssh:

https://forum.doozan.com/read.php?2,34313,104084#msg-104084

So I asked above to see your Ubuntu system info. I can use my Linux Mint laptop to see if I can repeat what you seeing:

Quote

In the mean time, could you list this on your Ubuntu box;

uname -a
cat /etc/debian_version
dpkg -l | grep -i ssh

Food for thought: whenever I create a new rootfs, I always ssh in as a last step in my testing. In this case, the ssh session was from a Debian Buster system. So the SSH client used in this testing step was quite up-to-date.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I've been following this thread because I seem to remember I had this same connection refused problem on a Dell M300 or a Pogo E02 within the past year but I cannot remember how I solved it. I have not found any posts from me on this issue on this forum. If I indeed had the problem, the solution wasn't anything as complex as chaos did. At the most, it would have been build a new USB.

I have 2 kirkwood boxes running 5.2.9 and 5.5.1 kernels, both with the 5.2.9 filesystem. The Dell running 5.2.9 does not have the updated ssh files, it was last updated in October, 2019 based on the dpkg log. The E02 running 5.5.1 has the deb10u2 update and it was updated in February, 2020. Both of these systems were fresh builds using Bodhi's file systems and kernel upgrades as needed at the time of build, not upgrades from an earlier Debian. I have just used the standard ssh-keygen on my Mac to setup the ssh connection and whatever you do in Putty or WinSCP on a Windows box. If I find any notes about my issue, I'll post back.



Edited 3 time(s). Last edit at 06/03/2020 05:59PM by mikeh49.

Mike,

I suspect that something in the host box (Ubuntu) that was causing this problem. Removing the keys on the Pogo and let it be regerated in 1st boot will get around it.

This is something I planned to do (as a precaution) in the new rootfs, but did not see the urgency so I forgot in the 5.2.9 rootfs. I will revise the 5.2.9. instruction to add this note as an optional step.

I guess you might have logged in with serial and regenerated the keys as noted in the installation.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 06/03/2020 10:59PM by bodhi.

Could be serial; if it was the M300, I had serial connected all the time. Regenerating the keys from serial seems kind of familiar.

I'll try to answer all questions from the above posts here.

First... Every new Ubuntu release is quite buggy at first. Ubuntu 20.04 has so far not shown any bugs to me, except for this openssh authentication issue with original rootfs 5.2.9 and an upgraded rootfs 4.12.1. I did suspect that the Ubuntu 20.04 could be the culprit, but the linux forums on internet all pointed to the history of openssh development, breaking things that work at an upgrade and causing reinstallation of servers already from year 2013-2014. The orthodox method advocated to solve this was to completely remove openssh, clean the system and reinstall it. That is why I put a vsftp server on it which allowed me to ftp as root (otherwise not allowed) to be absolutely sure that I still had a link to the POGO v4.

Here is the data from Ubuntu 20.04 (complete new install, latest upgrade as of yesterday):

user@ubuntu20-04:~$ uname -a
Linux ubuntu20-04 5.4.0-31-generic #35-Ubuntu SMP Thu May 7 20:20:34 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
user@ubuntu20-04:~$ cat /etc/debian_version
bullseye/sid
user@ubuntu20-04:~$ dpkg -l | grep -i ssh
ii  libssh-4:amd64                             0.9.3-2ubuntu2                      amd64        tiny C SSH library (OpenSSL flavor)
ii  libssh-4:i386                              0.9.3-2ubuntu2                      i386         tiny C SSH library (OpenSSL flavor)
ii  libssh-gcrypt-4:amd64                      0.9.3-2ubuntu2                      amd64        tiny C SSH library (gcrypt flavor)
ii  openssh-client                             1:8.2p1-4                           amd64        secure shell (SSH) client, for secure access to remote machines
ii  putty                                      0.73-2                              amd64        Telnet/SSH client for X
ii  putty-tools                                0.73-2                              amd64        command-line tools for SSH, SCP, and SFTP
ii  python3-paramiko                           2.6.0-2                             all          Make ssh v2 connections (Python 3)

As you see, I also did a try with Putty and I had the same issue with password being rejected by Debian rootfs 5.2.9.

I now notice that Ubuntu 20.04 has a newer openssh-client than Debian 10 on the POGO v4, which has 1:7.9p1-10+deb10u2. Since Ubuntu is based on Debian, I didn't suspect that Ubuntu could be more up-to-date than Debian, rather the other way around.

I do have the POGO Pro box as well, which runs kernel 4.14.180 now, latest Debian 10. I never had any openssh authentication error there. Same version of Debian as POGO v4, but a different kernel. This made me try the kernels 4.17 and 4.20 to see if the issue was bound to kernel 5.x.x. But, as I said, issue started with an upgrade of rootfs 4.12.1, so the kernel was probably not the culprit I thought.

I also had the idea to test Ubuntu Mint, Ubuntu Budgie, Android and Debian 10 to see if the issue was with Ubuntu 20.04, but since the reinstall of openssh solved the issue, I didn't do the test.

OpenSSH 8.3 was released May 27, 2020. Since my first post is on May 27... it is a coincidence that made me suspect, again, openssh development. Then I read that openSSH plans to drop RSA keys altogether. I tried the 4096 key over 2048, but that wasn't the underlaying issue, it was that a complete reinstall with cleaning was needed. Some posts on other forums said that would be the quickest solution, but it would not reveal the true cause about why openssh would fail on old keys. Now I suspect that openssh keymaking has changed, making old keys no longer work. A reinstall of openssh does create new keys, so I should have come to the conclusion that keys needed to be regenerated somehow on the rootfs 5.2.9. I din't know that you could hack rc.local to accomplish that re-generation on rootfs 5.2.9 boot.

The locale issue

There are numerous guides how to set it up, all with errors so that it doesn't work properly. This is my investigation on all the pit holes you may encounter in all these guides. Better to have one proper guide on this that works.

Starting with this guide.

root@debian:~# dpkg-reconfigure locales
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = (unset),
	LC_ALL = (unset),
	LC_ADDRESS = "sv_SE.UTF-8",
	LC_NAME = "sv_SE.UTF-8",
	LC_MONETARY = "sv_SE.UTF-8",
	LC_PAPER = "sv_SE.UTF-8",
	LC_IDENTIFICATION = "sv_SE.UTF-8",
	LC_TELEPHONE = "sv_SE.UTF-8",
	LC_MEASUREMENT = "sv_SE.UTF-8",
	LC_TIME = "sv_SE.UTF-8",
	LC_NUMERIC = "sv_SE.UTF-8",
	LANG = "C"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_ALL to default locale: No such file or directory
dpkg-query: package 'locales' is not installed and no information is available
Use dpkg --info (= dpkg-deb --info) to examine archive files.
/usr/sbin/dpkg-reconfigure: locales is not installed
root@debian:~# locale
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=C
LANGUAGE=
LC_CTYPE="C"
LC_NUMERIC=sv_SE.UTF-8
LC_TIME=sv_SE.UTF-8
LC_COLLATE="C"
LC_MONETARY=sv_SE.UTF-8
LC_MESSAGES="C"
LC_PAPER=sv_SE.UTF-8
LC_NAME=sv_SE.UTF-8
LC_ADDRESS=sv_SE.UTF-8
LC_TELEPHONE=sv_SE.UTF-8
LC_MEASUREMENT=sv_SE.UTF-8
LC_IDENTIFICATION=sv_SE.UTF-8
LC_ALL=
root@debian:~# locale -a
C
C.UTF-8
POSIX
root@debian:~# locale-gen "en_US.UTF-8"
-bash: locale-gen: command not found
root@debian:~# apt-get install locales
root@debian:~# locale-gen "en_US.UTF-8"
Generating locales (this might take a while)...
Generation complete.
root@debian:~# dpkg-reconfigure locales
... a window comes up after a while ...
... I chose [*] "en_US.UTF-8 UTF-8" with space key or mouse click.
... OK ...
... Default locale for the system environment ...
│ Many packages in Debian use locales to display text in the correct         │
│ language for the user. You can choose a default locale for the system      │
│ from the generated locales.                                                │
│                                                                            │
│ This will select the default language for the entire system. If this       │
│ system is a multi-user system where not all users are able to speak the    │
│ default language, they will experience difficulties.                       │
│                                                                            │
│ Default locale for the system environment:                                 │
│ ┌────────────────────────────────────────────────────────────────────────┐ │
│ │                             None                                       │ │
│ │                             C.UTF-8                                    │ │
│ │                             en_US.UTF-8                                │ │
│ └────────────────────────────────────────────────────────────────────────┘ │
├────────────────────────────────────────────────────────────────────────────┤
│                       <  OK  >            <Cancel> 
... I chose "en_US.UTF-8" ...
root@debian:~# cat /etc/environment
root@debian:~# locale
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=C
LANGUAGE=
LC_CTYPE="C"
LC_NUMERIC=sv_SE.UTF-8
LC_TIME=sv_SE.UTF-8
LC_COLLATE="C"
LC_MONETARY=sv_SE.UTF-8
LC_MESSAGES="C"
LC_PAPER=sv_SE.UTF-8
LC_NAME=sv_SE.UTF-8
LC_ADDRESS=sv_SE.UTF-8
LC_TELEPHONE=sv_SE.UTF-8
LC_MEASUREMENT=sv_SE.UTF-8
LC_IDENTIFICATION=sv_SE.UTF-8
LC_ALL=
root@debian:~# sh -c "echo 'LC_ALL=en_US.UTF-8\nLANG=en_US.UTF-8' >> /etc/environment"
root@debian:~# cat /etc/environment
LC_ALL=en_US.UTF-8
LANG=en_US.UTF-8

Still locale problem.

I follow this guide.

# Export env vars
root@debian:~# echo "export LC_ALL=en_US.UTF-8" >> ~/.bashrc
root@debian:~# echo "export LANG=en_US.UTF-8" >> ~/.bashrc
root@debian:~# echo "export LANGUAGE=en_US.UTF-8" >> ~/.bashrc
root@debian:~# source ~/.bashrc
-bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8): No such file or directory
root@debian:~# locale
LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=en_US.UTF-8
root@debian:~# locale -a
C
C.UTF-8
en_US.utf8
POSIX

Seems we have a mismatch here. Missing " and .utf8.

LC_ALL="en_US.UTF-8"

en_US.UTF-8 versus en_US.utf8

Editing ~/.bashrc to fix this by adding the apostrophes.
Editing /etc/environment to fix this by adding the apostrophes.

root@debian:~# dpkg-reconfigure locales
... Just hitting OK ...
... Selecting en_US.UTF-8 ...
Generating locales (this might take a while)...
  en_US.UTF-8... done
Generation complete.
root@debian:~# cat /etc/default/locale 
LANG=en_US.UTF-8
root@debian:~# # Generate the perl locale warning...
root@debian:~# perl -e exit
... no more locale errors ...
root@debian:~# source ~/.bashrc
-bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)

Editing ~/.bashrc to fix this. Commenting out all three lines
# LC_ALL...
# LANG...
# LANGUAGE...

root@debian:~# shutdown -r now && sleep 1 && exit
... Rebooting ...
... ssh login ...
root@debian:~# perl -e exit
root@debian:~# locale
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=en_US.UTF-8

Still not completely set up. LANGUAGE is empty.
Following this guide now.
This guide suggest to not use /etc/environment as the other solutions did, and instead put all the variables into /etc/default/locale

root@debian:~# rm /etc/environment
root@debian:~# cat /etc/default/locale
LANG="en_US.UTF-8"
root@debian:~# sh -c "echo 'LANGUAGE=\"en_US.UTF-8\"' >> /etc/default/locale"
root@debian:~# sh -c "echo 'LC_ALL=\"en_US.UTF-8\"' >> /etc/default/locale"
root@debian:~# cat /etc/default/locale 
LANG="en_US.UTF-8"
LANGUAGE="en_US.UTF-8"
LC_ALL="en_US.UTF-8"
root@debian:~# shutdown -r now && sleep 1 && exit

The system reboots.

root@debian:~# locale
LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=en_US.UTF-8
root@debian:~# perl -e exit
... no error messages ...

The red indicates where no apostrophes are " ... " used. The others lines all have apostrophes.

I hope I have answered all questions. Sorry for not sending the Ubuntu data earlier, I misread it and instead sent the data for the POGO v4. Lack of coffee I assume. My fault. Thank you for repeating the request, I honestly just missed it.

• May I ask, should I rather use a Linux Mint when dealing with the POGO, is that what you all are using?

Some extra nonsense (if you care...)

I am writing this very explicitly so that you can see how I tried to isolate the problems I encountered. I am sure there are better ways for more experienced linux people who do it "right" first time.

I have been using linux for some time but I am still a newbie when it comes to compiling a kernel and hunting bugs.

I chose Ubuntu 20.04 as base system over Debian and Mint due to that it is a bit more user friendly than Debian when you are a newbie, it's easier for other newbies to use it, although I must admit that Ubuntu Budgie 20.04 is one of the best systems for total newbies. I do use most Debian-based distros nowadays... even Lubuntu and Xubuntu. I guess this is the story for all, you start somewhere and end up learning all the distros after a few years. POGO Pro and POGO v4 are my first linux servers so to say without graphical user interface. I had the idea to use one as a web-server and the other as a database and learn to setup Wordpress, Woocommerce, blogs ... as training.

I did have a USB-TTL serial cable back in 2016 for some weeks to troubleshoot a dead Netgear router where the IP-ports only worked on occasion. Wasn't able to fix it nor understanding what makes an RJ45 IP-port die other than "planned obsolescence...", and since that time I didn't invest in a new serial cable which had proper linux drivers and would work with one of the distros like Ubuntu. The cheap USB-to-TTL serial cable kit that is easily available in some countries like China for something like 2-3USD I couldn't find at my location, just expensive 30USD solutions that ran drivers on platforms like Windows. That might have changed over the years, today maybe there are cheap cables everywhere if you know where to look for it. If you have an idea about what to get as of year 2020 that is cheap and works on linux distro like Ubuntu with open source USB-TTL drivers, please say something. I know you may have those things, but I don't know what exactly you have and what seems to work long-term.

I also wonder how you deal with the tear and wear on the USB-sticks, how you make them last longer.

• Don't USB-sticks fail after some time for you?
• POGO v4 has a visible SATA-port under the "hood", maybe it is wise to set POGO v4 up to boot from a durable SATA-disk, instead of a USB-stick? Would that be better long term?
• Or connect a USB-harddisk to the top USB-port instead of a USB-stick?

So many options and thoughts ... sometimes it would be easier for POGO-newbies like me to get the "do it this way from start and you'll save yourself a lot of hassle later on" kind of direction. I ask all this because now POGO v4 is running the latest kernel and latest Debian, which makes it a fully fledged server in my honest opinion. It wasn't like that some years ago.

Maybe even the POGO Pro with Wifi will get to this point soon, with kernel 5.6.5 and latest Debian. It would be awesome to get that one up to the latest kernel as well. I am not yet good at compiling my own kernel for POGO Pro with Wifi today, don't know how to patch things for the POGO Pro processor yet, and I don't have a serial cable to troubleshoot things with, so I kindly wait until "someone" :-) (guess who...) manages to create a new kernel 5.6.5 on POGO Pro, after the latest kernel 4.14.180 on that box. Thank you in advance.

I wrote this so that you have more clue about how little I know of hacking the POGOs but willing to learn. I appreciate when you all write out the little details that experienced linux people know, but newbies like myself don't know. Like the locale mess I try to show above as well as the trouble of rebooting systemd on a too small tempfs. Ubuntu has been a reliable work horse so far, it's my first time I run into an issue where Ubuntu is ahead of Debian with updates on critical things like openssh-server.



Edited 5 time(s). Last edit at 06/04/2020 08:28AM by chaos.

chaos,

Quite a long post :) so I'll go through the items one by one in separate posts.

Quote

I now notice that Ubuntu 20.04 has a newer openssh-client than Debian 10 on the POGO v4, which has 1:7.9p1-10+deb10u2. Since Ubuntu is based on Debian, I didn't suspect that Ubuntu could be more up-to-date than Debian, rather the other way around.

Actually it is normal for Ubuntu to be a little bit "newer". Note that the repo in your system is bullseye/sid. Debian 10 is buster (stable). This makes Ubuntu more like Arch Linux. Which is living on the edge with the latest stuff, but very often you will have something broken.

As I mentioned, I did the testing using Debian buster box. So the SSH keys are not supposed to cause problem. And the kernel version has little to do with SSH, it is the distribution version (Debian 9 vs 10) that could be different.

So I would not trust the Ubuntu box to behave correctly in some aspect, unless it is an LTS version (then it is a stable version).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Quote

OpenSSH 8.3 was released May 27, 2020. Since my first post is on May 27... it is a coincidence that made me suspect, again, openssh development. Then I read that openSSH plans to drop RSA keys altogether.

This has not happened yet.

Quote

I tried the 4096 key over 2048, but that wasn't the underlaying issue, it was that a complete reinstall with cleaning was needed. Some posts on other forums said that would be the quickest solution, but it would not reveal the true cause about why openssh would fail on old keys. Now I suspect that openssh keymaking has changed, making old keys no longer work. A reinstall of openssh does create new keys, so I should have come to the conclusion that keys needed to be regenerated somehow on the rootfs 5.2.9

Again, the keys should not be the problem. A newer version of OpenSSH client could be. And that should be a bug. Simply because it is unreasonable to cause obsoletion to million installations already exist out there. If RSA keys are obsolete for security reason, then it will ignore the keys and warn users to not use the RSA keys.

Quote

A reinstall of openssh does create new keys, so I should have come to the conclusion that keys needed to be regenerated somehow on the rootfs 5.2.9. I din't know that you could hack rc.local to accomplish that re-generation on rootfs 5.2.9 boot.

Reinstalling is bruce forcing the issue to get around a bug, IMO.

It is normal to add something to rc.local when you don't want to touch the kernel initrd (this key generation step really belongs to one of the init scripts). Because you know it will not make much different when it is run, as long as it runs before the end of boot process, rc.local is more flexible.

systemd target is an equivalence of something like this in init scripts.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Quote

May I ask, should I rather use a Linux Mint when dealing with the POGO, is that what you all are using?


I chose Ubuntu 20.04 as base system over Debian and Mint due to that it is a bit more user friendly than Debian when you are a newbie, it's easier for other newbies to use it, although I must admit that Ubuntu Budgie 20.04 is one of the best systems for total newbies. I do use most Debian-based distros nowadays... even Lubuntu and Xubuntu. I guess this is the story for all, you start somewhere and end up learning all the distros after a few years. POGO Pro and POGO v4 are my first linux servers so to say without graphical user interface. I had the idea to use one as a web-server and the other as a database and learn to setup Wordpress, Woocommerce, blogs ... as training.

I use Linux Mint on laptop. It is mainly because I like the good job Clem and the Mint team always done. And the aesthetic aspect (Cinamon desktop makes Windows and Mac users, i.e. relatives and friends, feel at home). Mint is based on Ubuntu LST so that makes it attractive because it is very stable. I enjoy living on the edge on the servers I can administer, but I like to treat a laptop like a phone or tablet.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Quote

I also wonder how you deal with the tear and wear on the USB-sticks, how you make them last longer.

Don't USB-sticks fail after some time for you?
POGO v4 has a visible SATA-port under the "hood", maybe it is wise to set POGO v4 up to boot from a durable SATA-disk, instead of a USB-stick? Would that be better long term?
Or connect a USB-harddisk to the top USB-port instead of a USB-stick?

Forum Wiki thread:

Quote
https://forum.doozan.com/read.php?2,23630

Flash drives issues

How to prolong the life of your rootfs USB thumb drive

But of course, HDD rootfs is much better to have.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 06/04/2020 07:51PM by bodhi.

Quote

I did have a USB-TTL serial cable back in 2016 for some weeks to troubleshoot a dead Netgear router where the IP-ports only worked on occasion. Wasn't able to fix it nor understanding what makes an RJ45 IP-port die other than "planned obsolescence...", and since that time I didn't invest in a new serial cable which had proper linux drivers and would work with one of the distros like Ubuntu. The cheap USB-to-TTL serial cable kit that is easily available in some countries like China for something like 2-3USD I couldn't find at my location, just expensive 30USD solutions that ran drivers on platforms like Windows. That might have changed over the years, today maybe there are cheap cables everywhere if you know where to look for it. If you have an idea about what to get as of year 2020 that is cheap and works on linux distro like Ubuntu with open source USB-TTL drivers, please say something. I know you may have those things, but I don't know what exactly you have and what seems to work long-term.

See the Wiki thread

Quote
https://forum.doozan.com/read.php?2,23630

Unbricking with Serial Console & JTAG console

Serial Port connector - what are people using to make it work

The CP2xx and PL3xxx serial module converter can be bought from China for 2 to 3 USD. They are quite reliable. I have 2 in use, the CP2xx is what I use everyday. It has been several years.

If you want to get it right away without waiting for 2 to 3 weeks, then Amazon also have them for about 10 USD.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Some versions of the PL2303 chip used in these devices are not supported in Win10. The CP chip is better supported and might be better, but is usually more expensive. My PL2303 device works fine in Mac, Linux and Win7, but definitely not in Win10. There is no driver. Check here for info, dirivers, etc for the PL2303:
PL2303 mfgr site

You can try to find old versions of driver for PL2303 and use the old driver in Windows 10.

I have a fake Nokia ca-42 cable, after I applied the old driver ( Windows 7) in windows 10, the cable works great again in Windows 10.

----------

The best part of CP chip is: It might support higher speed, such as 1,500,000bps, which is requred in Rock64 serial connection



Edited 1 time(s). Last edit at 06/05/2020 03:00PM by daviddyer.

OK, I'll try the older driver again. I think that is what I tried already, and it sort of worked but was not reliable, locked up or blue screened or something. In looking into this for my post I saw several youtubes about using the older drivers. /thread drift