Raspberry Pi Buster Raspup

[Brown Mouse]

@Brown Mouse

I am working on getting some rudimentary bluetooth stuff working. That will be in the next release.

With PPM, the find_cat binary is broken. I built a new one and it works and should fix your broken PPM. Pet attached.

Thanks for reports.

Mick

Cheers for the pet which has now fixed the broken PPM.

Been running this on a daily basis on a RPI 3B for 10 hours a day and always with Pmusic radio streamer running and Vivaldi with normally 3 tabs open,which leaves me seeing around 200mb's of 1gb ram spare,according to Htop.

At boot,I'm seeing an under voltage icon and message which isn't causing a problem when running but I think that is attributed to my slightly underpowered although good quality 2.1 amp Samsung power supply and usb cable.

Great work

[Dud]

Thanks 01micko, devx does enable the AppImage to run. I'll let the builder know and suggest he adds a note to help other Raspup users.

Odd thing though: Under Raspbian the AppImage runs much faster, I would have expected it to be about the same speed:
Complex part script on Raspbian renders in 12 minutes, on Raspup the same file takes 30 minutes.

Hold off from the samba problem for a while - I have a Wifi irregularity which might be at the root, I must heave some kit around and do some wired comparisons; I might be pointing you in the wrong direction.

Cheerio,

[Dud]

Hello 01micko, I've narrowed the issue a little - and found another.

All this is on a RPi4B with 4GB ram.

I connected with ethernet to avoid the WiFi problem (below) and tried again to log into samba.

Pnethood can't find any servers on a scan or refresh - when I disabled cifs (a known Pnethood problem) it reported 'smbmount not found'.

Samba shares from Raspup are rock steady - I am able to transfer GB+ sized files when logging in from another machine.

BUT

All this is on a wired connection. WiFi is decidedly flaky..

Raspup using wlan pings the router at anything from 4ms to 30000 ms with 60% - 80% packet loss.
I just ran a new test with the Pi within 2 metres direct line of sight of the router:
The first 24 pings lost 6 packets, the rest all returned together with #1 at 23000ms then each quicker until #24 at 17ms but the next to return, #27, took 5500ms.

Raspbian on the same RPi in the same place loses no packets and pings rarely go over 6ms.

If it might help I could substitute a Pi3 and re-run the tests?

Cheerio,

[Dud]

I replaced the Pi4 4GB with a Pi4 1GB and got essentially the same results
then with a Pi3B and although the WiFi was better it was still poor.

All 3 Pi's on Raspup lost over 50% packets,see typical runs below.

This explains the success only with FTP which is designed to be very fault tolerant.

All 3 Pi's on Raspbian Buster pinged 4-5ms with near 100% returns.
The Pi3B (others not tested) on Raspbian Stretch returned 100% with average times at 1.8ms

The difference between Stretch and Buster is a surprise.

Unrelated but I've seen comments above:
Bootup time for 4GB version 1.48, for 1GB 1.03
I assume something is accessing memory at about 15s/GB.
To check; anyone with a 2GB Pi getting 1.18 bootup times?

Hth, Cheerio,

[01micko]

Hello Dud

Yes there is definitely some networking/wireless problem, although with my 3B+ and my Zero you barely notice it; with browsing, using PPM, ftp, smb and pinging the router the 3 and zero seem 99% rock solid. I can't say the same for the pi 4, however I am posting from it now after connecting from the cli with wpa_cli and do have a very noticeable improvement.

Some stats - warts and all -

Code: Select all

# ifup -a
# wpa_cli -i wlan0 reconfigure
OK
# ifconfig
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:624 (624.0 B)  TX bytes:624 (624.0 B)

wlan0     Link encap:Ethernet  HWaddr DC:A6:32:07:07:D4  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:53 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2204 (2.1 KiB)  TX bytes:592 (592.0 B)

# dhcpcd
script_runreason: /lib/dhcpcd/dhcpcd-run-hooks: WEXITSTATUS 1 ##### this one bothers me
script_runreason: /lib/dhcpcd/dhcpcd-run-hooks: WEXITSTATUS 1
DUID 00:01:00:01:25:2b:c1:cb:dc:a6:32:07:07:d4
wlan0: IAID 32:07:07:d4
wlan0: adding address fe80::4430:dc09:ea08:1fed
ipv6_addaddr1: Operation not supported
eth0: waiting for carrier
wlan0: soliciting a DHCP lease
wlan0: soliciting an IPv6 router
ipv6nd_startrs1: Address family not supported by protocol
wlan0: offered 10.1.1.185 from 10.1.1.1
wlan0: probing address 10.1.1.185/24
wlan0: leased 10.1.1.185 for 86400 seconds
wlan0: adding route to 10.1.1.0/24
wlan0: adding default route via 10.1.1.1
script_runreason: /lib/dhcpcd/dhcpcd-run-hooks: WEXITSTATUS 1
forked to background, child pid 8125
# ifconfig
eth0      Link encap:Ethernet  HWaddr DC:A6:32:07:07:D3  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:624 (624.0 B)  TX bytes:624 (624.0 B)

wlan0     Link encap:Ethernet  HWaddr DC:A6:32:07:07:D4  
          inet addr:10.1.1.185  Bcast:10.1.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:81 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3760 (3.6 KiB)  TX bytes:1835 (1.7 KiB)

# ping 10.1.1.1
PING 10.1.1.1 (10.1.1.1): 56 data bytes
64 bytes from 10.1.1.1: seq=2 ttl=64 time=2.643 ms
64 bytes from 10.1.1.1: seq=3 ttl=64 time=3.214 ms
64 bytes from 10.1.1.1: seq=6 ttl=64 time=8.421 ms
64 bytes from 10.1.1.1: seq=8 ttl=64 time=4.395 ms
64 bytes from 10.1.1.1: seq=9 ttl=64 time=4.565 ms
64 bytes from 10.1.1.1: seq=10 ttl=64 time=3.426 ms
64 bytes from 10.1.1.1: seq=11 ttl=64 time=3.345 ms
64 bytes from 10.1.1.1: seq=12 ttl=64 time=2.696 ms
64 bytes from 10.1.1.1: seq=13 ttl=64 time=2.882 ms
64 bytes from 10.1.1.1: seq=14 ttl=64 time=3.562 ms
64 bytes from 10.1.1.1: seq=15 ttl=64 time=3.491 ms
^C
--- 10.1.1.1 ping statistics ---
16 packets transmitted, 11 packets received, 31% packet loss
round-trip min/avg/max = 2.643/3.876/8.421 ms
# ifconfig wlan0
wlan0     Link encap:Ethernet  HWaddr DC:A6:32:07:07:D4  
          inet addr:10.1.1.185  Bcast:10.1.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:121 errors:0 dropped:0 overruns:0 frame:0
          TX packets:31 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:8195 (8.0 KiB)  TX bytes:4127 (4.0 KiB)

# ping -c10 10.1.1.1
PING 10.1.1.1 (10.1.1.1): 56 data bytes
64 bytes from 10.1.1.1: seq=0 ttl=64 time=5.335 ms
64 bytes from 10.1.1.1: seq=1 ttl=64 time=57.148 ms
64 bytes from 10.1.1.1: seq=2 ttl=64 time=5.940 ms
64 bytes from 10.1.1.1: seq=3 ttl=64 time=7.157 ms
64 bytes from 10.1.1.1: seq=4 ttl=64 time=3.503 ms
64 bytes from 10.1.1.1: seq=5 ttl=64 time=2.103 ms
64 bytes from 10.1.1.1: seq=6 ttl=64 time=2.158 ms
64 bytes from 10.1.1.1: seq=7 ttl=64 time=2.063 ms
64 bytes from 10.1.1.1: seq=8 ttl=64 time=2.339 ms
64 bytes from 10.1.1.1: seq=9 ttl=64 time=2.665 ms

--- 10.1.1.1 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 2.063/9.041/57.148 ms
# ping -c10 10.1.1.254
PING 10.1.1.254 (10.1.1.254): 56 data bytes
64 bytes from 10.1.1.254: seq=0 ttl=64 time=43.126 ms
64 bytes from 10.1.1.254: seq=1 ttl=64 time=9.193 ms
64 bytes from 10.1.1.254: seq=2 ttl=64 time=6.174 ms
64 bytes from 10.1.1.254: seq=3 ttl=64 time=13.204 ms
64 bytes from 10.1.1.254: seq=4 ttl=64 time=12.096 ms
64 bytes from 10.1.1.254: seq=5 ttl=64 time=7.382 ms
64 bytes from 10.1.1.254: seq=6 ttl=64 time=7.307 ms
64 bytes from 10.1.1.254: seq=7 ttl=64 time=6.506 ms
64 bytes from 10.1.1.254: seq=8 ttl=64 time=7.541 ms
64 bytes from 10.1.1.254: seq=9 ttl=64 time=5.739 ms

--- 10.1.1.254 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 5.739/11.826/43.126 ms

Puppy uses busybox ping and as you see it is much more reliable limiting the pings to 10 ( -c10 option) - 100% packets get returned.

I think the big network managers, frisbee and SNS are too complex for the pi so I may write a very simple ncurses version (so it will work in console mode too). Of course it won't have all the features but should reconnect automatically if dhcpcd is running as a service.

Part of the problem too I think is that many of the hook scripts in /lib/dhcpcd/ are systemd agnostic which of course puppy doesn't use. I'll try to find replacements (slackware will be a good place to look).

Cheers!

[Dud]

Hello Micko,

As is Raspup WiFi is sufficiently responsive for *just* long enough that a cursory test looks OK but longer transfers fail.

Your short-burst test and the intermittent, grouped, response to my longer ones makes me wonder:

Is there something else taking up resources and only releasing every few seconds so the Pi's attention is diverted much of the time?
OR
Is one, occasionally used call failing with a timeout that causes the batching?

'though the difference between Raspbian Stretch and Buster suggests there may be something else involved too.

Part of the problem too I think is that many of the hook scripts in /lib/dhcpcd/ are systemd agnostic which of course puppy doesn't use. I'll try to find replacements (slackware will be a good place to look).

That it works at all suggests very few of those calls are going astray - a couple of small patches might be enough.

Thanks for all the good work - the Pi4 is so close to being a viable desktop replacement and a good Puppy might just tip the balance.

Cheerio,

[01micko]

Hello Micko,

As is Raspup WiFi is sufficiently responsive for *just* long enough that a cursory test looks OK but longer transfers fail.

Your short-burst test and the intermittent, grouped, response to my longer ones makes me wonder:

Is there something else taking up resources and only releasing every few seconds so the Pi's attention is diverted much of the time?
OR
Is one, occasionally used call failing with a timeout that causes the batching?

'though the difference between Raspbian Stretch and Buster suggests there may be something else involved too.

Part of the problem too I think is that many of the hook scripts in /lib/dhcpcd/ are systemd agnostic which of course puppy doesn't use. I'll try to find replacements (slackware will be a good place to look).

That it works at all suggests very few of those calls are going astray - a couple of small patches might be enough.

Thanks for all the good work - the Pi4 is so close to being a viable desktop replacement and a good Puppy might just tip the balance.

Cheerio,

We'll see...

My wireless is still up, from the original test.

I've logged into the samba share on my laptop downstairs; it's right near the router but the pi 4 signal has to get around a couple of walls and the floor. I'm currently copying a slackware-live-plasma5 iso image, 4.4 GB, over smb (cli - rox tends to bog down, not just a pi issue there). I prefixed the command with time so I should get a rough idea of the time it takes - bearing in mind that smb is quite a bit slower than ftp.

After that I might download a hefty iso from the internet with wget to see how that fares, but it certainly seems that my connection is more stable using the commandline.

Cheers

------------------

Later ...

Code: Select all

# mount.cifs //10.1.1.222/puppyshare ./sam -o user=root,pass=woofwoof -v
mount.cifs kernel mount options: ip=10.1.1.222,unc=\\10.1.1.222\puppyshare,user=root,pass=********
# pwd
/mnt/mmcblk0p2
# cd sam
# ls ..
lost+found  raspupsave-piZero  sam
# time cp slackware64-live-plasma5-current.iso ../

real	186m52.222s
user	0m0.121s
sys	0m46.115s

Yup, 3 hours for ~4.4GB over smb. For comparison ftp took ~14 mins for a 300MB iso. However, to be fair, my desktop was about the same with the same iso and the same server under the same conditions on my network - wifey watching netflix and grandson playing youtube.

Still no dropouts though (and still running from RAM - about to make a save and use my cli method at boot).

[Dud]

Please can someone with different screens available and a Pi4 confirm this:

All my tests upthread were done at 1920x1080 screen resolution.

Today I tried 1366x768 resolution, and while at that setting retried pinging the router.

...and got an improvement.

It's still very ropy but wlan was easier to get going and didn't drop out. Pings were still slow and intermittent but packet loss was only 35% on 1026 tries.

And I traced a pattern in the pings:

Returns paused for 25 - 30 seconds then most of the delayed pings returned in a burst before pausing again. The fastest pings in each group were under 100ms but the slowest were always around 26000ms

When I went back to the higher resolution performance was as before.

* * *

Hello Micko,

Have you seen:

https://blog.jlu5.com/blog/2018/07/debi ... el-b-plus/

- some of the comments might be useful too.

Hth Cheerio,

[Brown Mouse]

Five days + uptime on a Raspberry PI 3b and no problems for this little gem

[01micko]

Five days + uptime on a Raspberry PI 3b and no problems for this little gem

Code: Select all

# uptime
 12:46:52 up 25 days, 19:31,  0 users,  load average: 0.98, 0.98, 0.62

Well it's been asleep most of the time but I'm posting from it now from a firefox sfs (coming soon in the next raspup iteration)

I've mostly been working on a simple cli based wireless network manager which will also be in the next version.

I haven't yet had time for bluetooth, and don't have any hardware but that may change soon.

[01micko]

Please can someone with different screens available and a Pi4 confirm this:

All my tests upthread were done at 1920x1080 screen resolution.

Today I tried 1366x768 resolution, and while at that setting retried pinging the router.

...and got an improvement.

It's still very ropy but wlan was easier to get going and didn't drop out. Pings were still slow and intermittent but packet loss was only 35% on 1026 tries.

And I traced a pattern in the pings:

Returns paused for 25 - 30 seconds then most of the delayed pings returned in a burst before pausing again. The fastest pings in each group were under 100ms but the slowest were always around 26000ms

When I went back to the higher resolution performance was as before.

* * *

Hello Micko,

Have you seen:

https://blog.jlu5.com/blog/2018/07/debi ... el-b-plus/

- some of the comments might be useful too.

Hth Cheerio,

Hi Dud,

While I didn't test with a high res on with my pi4 I did test pinging with my new CLI network manager (TBA). I'll attach a screeny and a log of pinging the router, bearing in mind the signal from my pi needs to travel between/around a wall and a floor over ~10 metres ATCF (as the crow flies).

The results are somewhat baffling as to why they are so good when I did experience problems before - only 10 packets dropped out of 1024.

Cheers!

[spotted]

Wish list for what ever Raspuppy is next.
Minor gripes only, it is almost usable as Fatdog
opps, not allowed to mention fatdog
Cut and paste in and out of the terminal
Highlight and paste from a web page. I have to highlight the text in a web page then go to glipper and highlight again before I can paste into URL bar, but this dont work double clicking into the terminal.
CPU meter that bobs up and down in real time like in
errr, dont go there
Actually after 13 years of using puppy I am not so sure that cpu meter next to the time is a cpu meter, some times when it gets them lines across it might be a ram meter. Anyhow it shows what was happening yesterday, and needs to be errr self censored
If anyone knows how to take 'system monitor' from Mate desktop and put it into the tray can you do a howto. It can monitor the cpu and the internet speed, separate graph for each in real time.

Anyone found a video downloader for valaldi?
Or a gui for youtube-dl
You2pup dont work for me.
Forget firefox, your never going to fix it, people on the odroid forum that have sent a bug to mozilla say they aint interested in 'arm'

To play videos in full screen
If you have quirky xerus 814 handy
Nick 'Simplevp' and two depends, wmctrl, popup.
Works using ffmpeg, could not toggle it to work using omxplayer or vlc. its simple but it works
'ldd' for vlc says all depends are there but cant get it to run as stand alone either.

[spotted]

Just mucking around with Simplevc from Quirky, good luck trying to toggle vlc and omxplayer to work.

# vlc
VLC media player 2.2.4 Weatherwax (revision 2.2.3-37-g888b7e89)
vlc: unknown option or missing mandatory argument `--dbus'

# omxplayer
/usr/bin/omxplayer.bin: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libavcodec-ffmpeg.so.56: undefined symbol: x264_bit_depth
#

So also tried vlc-gtk as a GUI
# vlc-gtk
BusyBox v1.31.0 (2019-08-05 23:31:11 +08) multi-call binary.

Usage: which [COMMAND]...

Locate a COMMAND
# command: search
command: search
sort: cannot read: /tmp/vlc-gtk-playlist_root1: No such file or director

Anyone been able to trim a SSD connected to a pi 4, boot from micro sd card and throw to the SSD. When doing a 'save' it takes forever, I have 400 MB.sec SSD. A lot of pausing of the HD light while writing. But fstrim just goes nowhere.

hdparm -I /dev/sda2 | grep "TRIM supported"
* Data Set Management TRIM supported (limit 8 blocks)
# fstrim -V /dev/sda2
fstrim from util-linux 2.33.1

# fstrim -V /
fstrim from util-linux 2.33.1

Read up on hdparm, wiper. still have slow SSD HD

This operation could silently destroy your data. Are you sure (y/N)? y
Allocating temporary file (16498541 KB).. WIPER_TMPFILE.7747: Invalid argument
/dev/sda2: this kernel may not support 'fallocate' on a ext4 filesystem, aborting.

[spotted]

See Olle, I said Micko is working on it, errr well, working on working on it.
Not long to wait. Take a break Micko, do it after the holidays, and make it easier on your self, do a minimal.
Rox
firewall
vivaldi
unfortunately full networking plus usb tether so everybody can go online
alsa and mixer
package manager

question apps like cups, console, geany, pmount, vlc, htop, gparted. hardinfo, pfind, could they be obtained from rasbian or have to be compiled specially for raspuppy because Puppy dont have those sudo and systemd jerks.

[spotted]

Heres how a pi 4 stacks up against a odroid n2.
A n2 has 4 A73 cores plus 2 A53 cores. With the A73 cores everything is bigger and better than the A72. Cant get the A73 cores past 1900.
My pi4 is at 2000 and set to performance.
cpu drawing higher is better n2=4458 pi4=4265
fpu raytrace lower n2=3.52 pi4=2.14 winner
fpu fft lower n2=2.47 pi4=5.28
zlib higher n2=.40 pi4=.32
n-queens lower n2=8.94 pi4=8.82 winner
fibronacci lower n2=1.57 pi4=1.73
cryptohash higher n2=317 pi4=473 winner
blowfish lower n2=3.92 pi4=5.14

[Olle]

@ spotted
Fine. I however prefer a devuan based puppy, so I'm following the rasvuan 888 thread.

@ 01 micko
Family first, then work, evetually followed by rasvuan (sixtyfour ,) ) when beowulf is ready to land on.

/Olle

[01micko]

Time to retire the sdcard and re-format... new version soon with a vast amount of improvements.

[lizardidi]

I copied the Raspup Buster files into a 2 GB sdcard, and it booted fine from my pi zero (no wireless version). The first boot took around 5 minutes to working desktop, second boot is much more faster, around 40 to 50 seconds to desktop. Wireless is working perfectly, but i faced some problems:

1. PPM not updating. The PPM launch fine, but I unable to download updates from the PPM, even though my wifi is connected. The wifi is working because when i ran the vivaldi downloader, i can download packages from vivaldi.

2. Stock Midori not working. I tried every site, but it sd "SSL errors". Previously, Midori can run on my Raspberry Pi Zero ( using DietPi )



Anyone facing same problems?

[01micko]

Raspup Buster RC is out.

Get it from the main post.

Happy bug hunting!

[Brown Mouse]

Testing the latest Raspup Buster RC on an RPI 3B.

Firstly,connected to the all new 'wireless network tool bbwireless'.Was running fine but so far after several reboots its wasn't saving the configuration and was having to set it up from the beginning each time,so have now reverted to 'Barry's Simple Network setup' for now and it connects instantly after each boot.I was previously using Frisbee which seems to take much longer.
Will test 'bbwireless' further later.

Currently running Firefox Quantum 60.9.0 ESR with three tabs open and a nice addition.

Installed a couple more apps from the PPM.CPU temperature pet which works fine.
No luck running Hexchat from the PPM.It throws up '(unable to get local issuer certificate.? (20)'.

This version seems to save much faster on shutdown too and along with all the new additions just gets better.

The testing continues.

Well done Mick