LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM
User Name
Password
Slackware - ARM This forum is for the discussion of Slackware ARM.

Notices


Reply
  Search this Thread
Old 05-20-2020, 08:56 AM   #1
business_kid
LQ Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware & Android
Posts: 11,550

Rep: Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335
Wifi missing on Sarpi (32bit) with RazPi 4


Freshly installed Sarpi 32bit here. It's sitting up and booting. I did remove the initrd.gz, and the few lines at the end of /boot/config.txt that tell things to load an initrd.

wlan0 doesn't seem to be detected by the kernel AT ALL. I see no messages during boot, ifconfig shows me 'lo' & 'eth0', but no wlan0.

lspci shows me only 2 lines (PCI Bridge & usb-3.0 hub), lsusb has 4

ID 1d6b:0003 - a usb-3.0 root hub
1908:0226 - a GEMBIRD :-o??
046d:c534 - A Logitech Unifying Hub, a keyboard/mouse thing which works
1d6b:0002 - a usb-2.0 root hub

I don't see ethernet or wifi during bootup, but the eth0 at least shows up. Raspbian configures itself automagically with networkmanager, but has no more info. I'm trying to set up dhcp/wpa_supplicant with init scripts, so I don't need X to get wifi. I'm not exactly a novice with networking.
 
Old 05-20-2020, 02:20 PM   #2
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware [ARM]
Posts: 347

Rep: Reputation: 180Reputation: 180
Quote:
Originally Posted by business_kid View Post
Freshly installed Sarpi 32bit here. It's sitting up and booting. I did remove the initrd.gz, and the few lines at the end of /boot/config.txt that tell things to load an initrd.

wlan0 doesn't seem to be detected by the kernel AT ALL. I see no messages during boot, ifconfig shows me 'lo' & 'eth0', but no wlan0.

lspci shows me only 2 lines (PCI Bridge & usb-3.0 hub), lsusb has 4

ID 1d6b:0003 - a usb-3.0 root hub
1908:0226 - a GEMBIRD :-o??
046d:c534 - A Logitech Unifying Hub, a keyboard/mouse thing which works
1d6b:0002 - a usb-2.0 root hub

I don't see ethernet or wifi during bootup, but the eth0 at least shows up. Raspbian configures itself automagically with networkmanager, but has no more info. I'm trying to set up dhcp/wpa_supplicant with init scripts, so I don't need X to get wifi. I'm not exactly a novice with networking.
As previously stated; you haven't installed SARPi - you have installed SLACKWARE ARM. Nobody ever installs SARPi - because it's ONLY an installer for Slackware ARM! It's impossible to install, or run, the "SARPi" operating system as there's no such thing.

Code:
root@torq:~# ifconfig -a
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.144  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::dea6:32ff:fe67:c42b  prefixlen 64  scopeid 0x20<link>
        ether dc:a6:32:67:c4:2b  txqueuelen 1000  (Ethernet)
        RX packets 105  bytes 10866 (10.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 91  bytes 12267 (11.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether dc:a6:32:67:c4:2c  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
Raspberry Pi 4 wireless guide: https://www.linuxquestions.org/quest...ons-4175666921

Last edited by Exaga; 05-20-2020 at 02:25 PM.
 
Old 05-21-2020, 10:08 AM   #3
business_kid
LQ Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware & Android
Posts: 11,550

Original Poster
Rep: Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335
Thx for the reply.
I appreciate you might want this called called Slackware Arm.
The one diagnostic line I took out of your reply was this:
Code:
Raspberry Pi 4 wireless guide: https://www.linuxquestions.org/quest...ons-4175666921
Wifi on Slackware has always involved a bit of 'bending it straight' for me, with config files, but once there, it's dead reliable. That gave me a starting point.
As for firmware, I noted that the wifi appeared to come and go, but the solution appeared to be to update. Looking at the firmware, however, it seemed to change little.
Code:
bash-5.0$ ls -lh  lib/firmware/brcm/brcmfmac43455-*
-rw-r--r-- 1 root root 2.5K Apr 25 18:40 lib/firmware/brcm/brcmfmac43455-sdio.MINIX-NEO Z83-4.txt
-rw-r--r-- 1 root root 477K Apr 25 18:40 lib/firmware/brcm/brcmfmac43455-sdio.bin
-rw-r--r-- 1 root root 1.9K Apr 25 18:40 lib/firmware/brcm/brcmfmac43455-sdio.raspberrypi,3-model-b-plus.txt
-rw-r--r-- 1 root root 1.9K Apr 25 18:40 lib/firmware/brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt
The one binary (brcmfmac43455-sdio.bin) seemingly capable of running things had the same md5 and size @477K.

When I checked with Raspbian (which had wifi out of the box, dead reliable & no complaints), they had a different setup.
Code:
bash-5.0$ ls -lh  lib/firmware/brcm/brcmfmac43455-*
-rw-r--r-- 1 root root 587K May 21 11:37 lib/firmware/brcm/brcmfmac43455-sdio.bin
-rw-r--r-- 1 root root  14K May 21 11:37 lib/firmware/brcm/brcmfmac43455-sdio.clm_blob
-rw-r--r-- 1 root root 2.1K May 21 11:37 lib/firmware/brcm/brcmfmac43455-sdio.txt
Now, knowing my luck, the wifi on the RazPi 4B might not be the brcmfmac43455, but no doubt you'll steer me straight on that. But the brcmfmac43455-sdio.bin file on Raspbian is over 100k bigger, and a second binary blob seems to be there. Why the difference exists would be interesting My x86_64 kernel (5.4.30) has your arrangement

Now that solves puzzles for me. One of the best kept secrets seemed to be what the identity of the wifi chip was. It's no longer a chip, of course, it's an IP core occupying some corner of the silicon wafer, but it still has compatibility with an IC design, and hardware features & specs. I'm very glad it isn't any of the bcm43xx family which I've duelled with previously in days gone by.

Then a little detective work informed me I had a 5.4.22 kernel in the boot image, and only 5.4.36 modules, which aren't going to work together any time soon. But I have things to prepare for, so this is going to have to wait until I have time. I'll try and run down the alternatives on the firmware. I have Arch here somewhere I'll get to look at also. I'll get to the bottomofit and post again for the record.
 
Old 05-21-2020, 04:46 PM   #4
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware [ARM]
Posts: 347

Rep: Reputation: 180Reputation: 180
I don't use the onboard wireless on the Raspberry Pi 3 or 4. If and when I do use wireless it's via a USB adapter with a chip that's supported by Slackware. The only reason I bothered to spend time and effort getting the wireless working was because a Slacker using a Raspberry Pi alerted me that the onboard wireless had stopped working on the latest SARPi updates. Whenever that was I don't recall.

[EDIT] example of the sort of USB wireless adapter I'd use: https://sarpi.fatdog.eu/index.php?p=wireless-nic

Often you can borrow drivers from other distributions in order to get things working on Slackware ARM. In the case of the onboard wireless, mralk3 posted this little gem for the RPi3 that is very relevant to the RPi4 - https://www.linuxquestions.org/quest...7/#post5840054

I'm not very keen or willing to include things in SARPi which aren't already present in Slackware ARM proper. The RPi not being an officially supported device has some grey areas in that respect - the onboard wireless being one of them. One needs to look beyond established parameters when working outside of the box.

Last edited by Exaga; 05-21-2020 at 04:48 PM. Reason: something
 
2 members found this post helpful.
Old 05-22-2020, 04:36 AM   #5
business_kid
LQ Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware & Android
Posts: 11,550

Original Poster
Rep: Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335
Thanks for the link.

Being a hardware guy, who raised his kids by fixing other people's problems (Mainly Industrial Electronics), a certain dogged determination sets in when pursuing things that should work but don't. I get it that Slackware Arm is not of the standard of an official release. But I have 2 sets of firmware, possibly a third in Arch, I still have to line up

Boot Kernel Version = Firmware version = kernel modules version

which is pretty elementary in getting things right. I know Firmware is pretty promiscuous as regards kernel versions, but significant changes to the module may result in a different sharing of tasks between module & kernel. The Raspbian kernel is 4.x.x and slaxckware is on 5.x.x, and probably patched. I've gathered also that the file ordering on /boot may be important, but it's not easy to discover what the correct ordering is, or to switch things around. I've actually achieved nothing since I last posted, as I was attending a meeting last night.

From my maintenance days, I know you're not beaten until you run out of ideas. I'm not out of ideas. I wanted to install a system that worked, but that isn't there. If I bend it straight and make it work, I'll share it. If you bought a good usb wifi with 802.11 b,g, & n support and using firmware/modules already present which sits up and works without hacking, I'd appreciate knowing what it is. I'll post again when ideas are low, or when wifi is up.

Also, the usb has 2×USB2.0 & 2×USB-3.0 ports, and if you know which is which, I'd like to know. I have an Amazon keyboard/mouse setup in one, and I'd like to make sure it's usb-2.0.

Last edited by business_kid; 05-22-2020 at 04:37 AM.
 
Old 05-22-2020, 12:55 PM   #6
business_kid
LQ Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware & Android
Posts: 11,550

Original Poster
Rep: Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335
Right. With Slackware-Arm-current(32 bit only), I updated to
  • kernel_sarpi4-5.4.40-armv7l-1_slackcurrent_13May20_sp1.txz
  • kernel-modules-sarpi4-5.4.40-armv7l-1_slackcurrent_13May20_sp1.txz
  • sarpi4-boot-firmware-armv7l-1_slackcurrent_13May20_sp1.txz
That was all 5.4.40 stuff, but lacked headers or firmware. So I downloaded the 5.4.40 kernel source, copied & unzipped the config, and from the RazPi 4, I ran
make headers_install
make firmware_install
I did use a $DESTDIR option to package them, but it was ignored.
After I rebooted, after making sure MY kernel was actually 5.4.40.
Wifi worked with little trouble. My usual fix on /etc/wpa_supplicant.conf using wpa_passphrase, and then one line
Code:
wpa_supplicant -Dnl80211 -iwlan0 -c/etc/wpa_supplicant.conf && dhcpcd wlan0
brought things to life.

For posterity, despite the firmware install, I'm still on Raspbian firmware
Quote:
bash-5.0$ ls -lh lib/firmware/brcm/brcmfmac43455-*
-rw-r--r-- 1 root root 587K Apr 18 2019 lib/firmware/brcm/brcmfmac43455-sdio.bin
-rw-r--r-- 1 root root 14K Apr 18 2019 lib/firmware/brcm/brcmfmac43455-sdio.clm_blob
-rw-r--r-- 1 root root 2.1K Apr 18 2019 lib/firmware/brcm/brcmfmac43455-sdio.txt
This arrangement works without issue - today. All the Raspbian version numbers are followed by a '+' so my guess in there's some patching going on. I favoured these, with 2 binaries and the bigger file size on brcmfmac43455-sdio.bin.
The standard kernel arrangement is
Quote:
bash-5.0$ ls -lh /lib/firmware/brcm/brcmfmac43455-*
-rw-r--r-- 1 root root 2.5K Mar 20 18:30 /lib/firmware/brcm/brcmfmac43455-sdio.MINIX-NEO Z83-4.txt
-rw-r--r-- 1 root root 477K Mar 20 18:30 /lib/firmware/brcm/brcmfmac43455-sdio.bin
-rw-r--r-- 1 root root 1.9K Mar 20 18:30 /lib/firmware/brcm/brcmfmac43455-sdio.raspberrypi,3-model-b-plus.txt
-rw-r--r-- 1 root root 1.9K Mar 20 18:30 /lib/firmware/brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt
That offers 2 unnecessary text files and only one smaller binary blob.
I'll fart about with the firmware and try to break it, but I haven't even added a single luser to this install or started X yet, so I'm not going to put the cart before the horse. But I want to retain a wifi connection without a battle. It's a basic minimum for me.
 
Old 05-25-2020, 08:49 AM   #7
business_kid
LQ Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware & Android
Posts: 11,550

Original Poster
Rep: Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335
I've made some experiments on wifi, and I'll report them here.

The Raspbian/Noobs/Debian distro has little issue with wifi - it just works. Slackware Arm does have issues with wifi unreliability, I am informed. I know enough about firmware to ignore text files. Anyone writing firmware is not going to include all the palaver of text interpretation, Unicode, etc. Noobs/Raspbian/Debian has
Code:
bash-5.0$ ls -lh lib/firmware/brcm/brcmfmac43455-*
-rw-r--r-- 1 root root 587K Apr 18  2019 lib/firmware/brcm/brcmfmac43455-sdio.bin
-rw-r--r-- 1 root root  14K Apr 18  2019 lib/firmware/brcm/brcmfmac43455-sdio.clm_blob
-rw-r--r-- 1 root root 2.1K Apr 18  2019 lib/firmware/brcm/brcmfmac43455-sdio.txt
Whereas the standard kernel gives
Code:
bash-5.0$ ls -lh lib/firmware/brcm/brcmfmac43455-*
-rw-r--r-- 1 root root 2.5K Apr 25 18:40 lib/firmware/brcm/brcmfmac43455-sdio.MINIX-NEO Z83-4.txt
-rw-r--r-- 1 root root 477K Apr 25 18:40 lib/firmware/brcm/brcmfmac43455-sdio.bin
-rw-r--r-- 1 root root 1.9K Apr 25 18:40 lib/firmware/brcm/brcmfmac43455-sdio.raspberrypi,3-model-b-plus.txt
-rw-r--r-- 1 root root 1.9K Apr 25 18:40 lib/firmware/brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt
which is just one binary @477K, and three fairly useless text files. So taking the file 'brcmfmac43455-sdio.bin' in some form to be necessary, the text files as unnecessary, I set about experimenting.
  • I started with the Noobs pairing of brcmfmac43455-sdio.bin @587K, & brcmfmac43455-sdio.clm_blob @14K, which AFAICT are reliable. and it seemed to give good debug output. Wifi worked.
  • Removing the blob file brcmfmac43455-sdio.clm_blob @14K killed the wifi, but restoring it restored wifi. Therefore, it is necessary with the 587K brcmfmac43455-sdio.bin
  • Using the kernel file brcmfmac43455-sdio.bin @477k didn't kill wifi.
  • Removing the blob file with the kernel brcmfmac43455-sdio.bin @477K didn't kill it either, although this combination is apparently unreliable, as evidenced by the fact that some here have invested in usb wifi. This combination was highly under suspicion when I couldn't initially get wifi going.

I am led to the conclusion that the (probably patched) Debian/Noobs/Raspbian wifi firmware including the blob file is the safest way to go for reliable wifi. Maintainers who agree with me may make changes based on this information, but I'm not going to agitate for any.
 
Old 05-26-2020, 02:37 PM   #8
mralk3
Senior Member
 
Registered: May 2015
Location: Utah, USA
Distribution: Slackware, OpenBSD, Linux From Scratch
Posts: 1,413

Rep: Reputation: 782Reputation: 782Reputation: 782Reputation: 782Reputation: 782Reputation: 782Reputation: 782
I've been using the stock Slackware ARM kernel headers, even with newer versions of Sarpi kernel packages. In general, it's best to leave the kernel headers alone, even after a kernel update. Also, running Raspbian on my pi4, I had many issues with wifi. Wifi problems are not specific to sarpi project distributed modules or firmware packages. They exist in Raspbian too. You may have used firmware for the pi4 from the Debian guys that was working. There are not any "Sarpi" developed firmware and other packages sources. Exaga only packages what the Debian guys put out, so if you have problems with wifi, report it upstream as well.
 
Old 05-27-2020, 04:02 AM   #9
business_kid
LQ Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware & Android
Posts: 11,550

Original Poster
Rep: Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335
I don't think I reported messing with headers. I reported updating them, but I agree, they can be left as a rule. I reported on firmware issues. As there is general acceptance that Slackware Arm wifi is unreliable, I am using Noobs/Raspbian/Debian firmware. That's my choice. But I wanted the latest firmware, and putting updating the headers gave me a fixed timeline for everything.

Both the RazPi with it's challenges and the nature of posting here are new experiences for me. There seems to be more focus on procedure here, and less of the 'your distro, your way' that exists in the Official X86 forum. I am definitely attempting 'my distro, my way.' In the X86 forum, people would weigh in with suggestions even if they thought I was crazy.I certainly did when I could.

To my knowledge Slackware Arm puts out what the kernel supplies as firmware. This has been unchanged over many versions, but Debian have apparently modified it as I reported. You can check that by exploding a few packages if you don't believe what I wrote. That's why I wrote it. Unlike many others, I have not yet had wifi failures. But I had to choose, and reported what I chose. This isn't actually my first RPi. I had an RPi 0(?) some time back. Maybe an RPi 1 - I just don't remember.

As an ex-hardware guy, I know the chip market. Broadcomm sales policy is to make agreements with manufacturers to use Broadcomm chips in exchange for discounts & tech support. Raspbian no doubt have deals with Debian, and with Broadcomm. Of the Linux distros out there, only Debian have access to tech support from Broadcomm (Through Raspbian). They may have had to sign confidentiality agreements; hardware companies are incredibly paranoid that way. Broadcomm are no friends of Linux, and the B43xx stuff had to be reverse engineered back in the day.
 
Old 05-27-2020, 02:49 PM   #10
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware [ARM]
Posts: 347

Rep: Reputation: 180Reputation: 180
Quote:
Originally Posted by business_kid View Post
As there is general acceptance that Slackware Arm wifi is unreliable, I am using Noobs/Raspbian/Debian firmware.
I've not noted any instability or unreliability with Slackware ARM "wifi". The culprit (if there is one) on the Raspberry Pi 3/4 would be the Cypress wireless shizzle. This is just one reason why I prefer to use a plug-in USB adapter if/when I have to use a wireless Internet connection. Otherwise I stick with a trusty Ethernet cable.

Whatever works is usually best. If it works as expected it's all good.
 
Old 05-28-2020, 03:08 AM   #11
business_kid
LQ Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware & Android
Posts: 11,550

Original Poster
Rep: Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335
Quote:
Originally Posted by Exega
The culprit (if there is one) on the Raspberry Pi 3/4 would be the Cypress wireless shizzle.
Really? Enlighten me, please. I'd love data. The part number is enough. I find hardware spec totally unavailable for the RazPi 4.Broadcomm think they can do wifi, but I didn't know Cypress did.

I've had a stroke, snd 2 fractured hips led to 2 replacements. The 2nd had some super-difficult-to-dislocate socket which restricted movement, so reaching the ground is a huge deal for me. For that reason, wifi is pretty essential for me also.

I was somehow convinced that wifi on the RazPi 4 was an IP core for the BCM43455, in some corner of the 2711 APU. The WiFi specs are excellent: 2.4Ghz & 5Ghz ranges (the 2,4 Ghz range is only 12 channels and quite crowded). Also 802.11 b,g, & n (the fast one). I find it necessary occasionally to do a wifi scan, and switch channel to the least occupied one. The thing is, after so long out of the game, Cypress would have to put considerable effort into R & D to enter a new market area to compete against developed technologies of companies like Qualcomm, Realtek, Intel & Broadcomm. There is also the issue of having to circumvent existing hardware patents. Even there, I still think Intel is playing catch-up like they're doing with their sucky graphics.
 
Old 06-02-2020, 06:10 PM   #12
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware [ARM]
Posts: 347

Rep: Reputation: 180Reputation: 180
Quote:
Originally Posted by business_kid View Post
Really? Enlighten me, please. I'd love data.
https://www.latlmes.com/tech/raspber...hipset-fails-1
 
1 members found this post helpful.
Old 06-03-2020, 05:01 AM   #13
business_kid
LQ Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware & Android
Posts: 11,550

Original Poster
Rep: Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335
Quote:
Originally Posted by Exaga View Post
From here, that link resolves to an autoplaying Rick Astley video . LA Times have obviously changed their content. Nevertheless, I got some interesting links. The RazPi 3 has the CYW43455 wifi chip, and apparently has a problem with
doing full duplex, and is vulnerable to the KrOOK(?) bug. I would agree it was a poor choice. The search hits on Cypress or CYW43455 seem to be lacking with the RazPi 4. Was it just a RazPi 3 problem.

Full duplex is a big one, because you have to stop a download to say "OK, I got that - carry on." Worst of all, of course, if the CYW43455 doesn't know that. I'm inclined to ignore security bugs, because I'm below the radar for hackers really. About the worst they can do is hose the system, which I usually have backed up. If they download my disk, they'll get nothing.
 
Old 06-09-2020, 02:26 PM   #14
business_kid
LQ Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware & Android
Posts: 11,550

Original Poster
Rep: Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335Reputation: 1335
/Much Later

I'm going to leave this for the moment. I want to take the time to thank you (Mozes, Exega & the team)for your prolific work in bringing Slackware to Arm. This, I presume is rewarded solely by the output. It's a worthwhile cause and an interesting challenge that I unfortunately cannot get involved in, as my health does not permit it.

Despite many ups and downs here, your OS installed like a regular Slackware OS. On X86_64, Slackware will probably change a bit next release, if Alien Bob's repo is anything to go by. I think mine is a different and minority use case to Slackware Arm and the folks you're mainly catering for, so I've reluctantly made a break from Slackware, and undertaken duelling the demons of systemd & NetworkManager with a debian based 32 & 64 bit os. They're on different sdcards and from different re-badgers, but if I need outside software I can stick it on 32bit, the rest of the time I'll use 64 bits.

So folks can stop leaving quiet jabs or flames because I won't be around. I do need retraining occasionally, but I'm sure I'll get it elsewhere.

Last edited by business_kid; 06-09-2020 at 02:28 PM.
 
Old 06-09-2020, 05:08 PM   #15
TheTKS
Member
 
Registered: Sep 2017
Location: The deep south... of Canada
Distribution: Slackware, Xubuntu, OpenBSD, elementary, Puppy, TinyCore
Posts: 131

Rep: Reputation: Disabled
business_kid, it sounds like you’ve had an interesting ride.

About wifi on RPi 4 with SlackwareARM -current, there was a short time (two SlackwareARM and Sarpi kernel updates, during which also there was a bunch of my messing around) when it could see the router wifi but couldn’t connect to the internet via wifi whereas wired it could connect to the internet, but I never did sort out why - after a 3rd update and a bunch more of my messing around, the “problem” went away (in quotes because I use wired almost always.)

Mostly I’ve used my RPi for everyday desktop stuff and for weekend playing with my Arduino Uno (I adapted the 14.2 Slackbuild for ARM -current.) For that SlackwareARM with Sarpi packages has worked great.

I hope your health picks up, and if SlackwareARM isn’t working for your use case, that you find what you need elsewhere.

TKS
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Fedora 32 out now. how on a RazPi 4? business_kid Fedora - Installation 12 05-02-2020 08:17 AM
[SOLVED] SARPi install, missing boot partition DBLouis Slackware - ARM 10 03-05-2018 01:21 PM
SARPi website new URL - sarpi.co.uk Exaga Slackware - ARM 4 01-28-2018 06:36 PM
Installing VMWare Workstation 7.x (32bit) on Mint 14 (32bit) 8trak Linux - Newbie 4 01-24-2013 08:35 PM
Fedora 13 32bit and then Linux Mint 32bit and then Ubuntu 10.04 32bit ciao303 Linux - Newbie 3 08-09-2010 11:03 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM

All times are GMT -5. The time now is 01:40 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration