LinuxQuestions.org
Share your knowledge at the LQ Wiki.
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 01-02-2021, 07:49 AM   #16
TheTKS
Member
 
Registered: Sep 2017
Location: The deep south... of Canada
Distribution: Slackware, Xubuntu, OpenBSD, elementary, Raspberry Pi OS, Puppy, TinyCore
Posts: 251

Rep: Reputation: 152Reputation: 152

Thanks for the added background. I still have to get through this whole thread, so looking forward to some good reading this weekend, but I'll address a couple of points that jumped out at me on a quick lookover.

Quote:
Originally Posted by Exaga View Post
[EDIT]
There's no need to run the mkinitrd unless you intend to create an initial RAM disk image. Is that an x86 thing?
It is an x86(_64) thing if you switch from the default huge kernel to the generic kernel, as I've done on my x86_64 Slackware 14.2 and Slackware -current installations. Upgrading kernel packages using the steps I do (while new and previous kernels are still installed), after each kernel upgrade, you must create an initrd by first running the script
Code:
# /usr/share/mkinitrd/mkinitrd_command_generator.sh
then running the command it generates, manually substituting in the new kernel version number (since the command script picks up the version number of the previous, still installed kernel.)

I took most of this from about half way down this page, which I still find a handy reference (even though some things are out of date) https://docs.slackware.com/slackware:beginners_guide

Quote:
Originally Posted by Exaga View Post
Then if all goes well (which it usually does) I'll then reboot the system and hopefully it will be successful and use the new versions.
That's a key condition for me. I have had kernel packages install incorrectly a couple of times. I have installed a wrong kernel package. Upgrading kernels step-by-step this way, although more time consuming than a batch run, prompts me to look at the output each time I run installpkg or upgradepkg. I'm more likely to catch and fix an error before I go on to break more things. I would rather do that, certainly on my main (14.2 on x86_64; less critical on my arm and trial x86_64 -currents) than to puzzle out and fix later what went wrong, even if occurrence is rare. I accept the tradeoff of not going through those occasional "learning experiences" :-).

TKS
 
1 members found this post helpful.
Old 01-02-2021, 09:11 AM   #17
pchristy
Member
 
Registered: Oct 2012
Location: South Devon, UK
Distribution: Slackware
Posts: 702

Rep: Reputation: Disabled
Quote:
Originally Posted by Exaga View Post
OK. One thing you may not be aware of is that the Raspberry Pi's '/boot' partition _MUST_ be FAT32 - if you're using the proprietary Raspberry Pi boot-firmware.
Yes, I'd already picked up on that, but wasn't aware why! Thanks for the explanation!

I have no problems with the way you are going about things, so please don't think I'm being critical! I'm not! But I DO want to run 64-bit, and at the moment, the only option for that is slarm64. I did have problems with the slarm64 boot process, which I was never completely able to resolve on the Pi 400, despite sndwvs excellent efforts. Your description gives me some indication why!

Thanks also for the links both here and in the other (related) thread. The information is out there, but you need to know where to look! I now have a few pointers!

Cheers,

--
Pete
 
1 members found this post helpful.
Old 01-02-2021, 09:27 AM   #18
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware [ARM]
Posts: 689

Original Poster
Rep: Reputation: 414Reputation: 414Reputation: 414Reputation: 414Reputation: 414
Quote:
Originally Posted by TheTKS View Post
Upgrading kernel packages using the steps I do (while new and previous kernels are still installed), after each kernel upgrade, you must create an initrd by first running the script
I hear you. It's such a long time since I've done anything like that. Seem to have a faint recollection of doing this in times gone by.

Quote:
Originally Posted by TheTKS View Post
I took most of this from about half way down this page, which I still find a handy reference (even though some things are out of date) https://docs.slackware.com/slackware:beginners_guide
SlackDocs is veritably ÜBER AWESOME! <3

Quote:
Originally Posted by TheTKS View Post
That's a key condition for me. I have had kernel packages install incorrectly a couple of times. I have installed a wrong kernel package. Upgrading kernels step-by-step this way, although more time consuming than a batch run, prompts me to look at the output each time I run installpkg or upgradepkg. I'm more likely to catch and fix an error before I go on to break more things. I would rather do that, certainly on my main (14.2 on x86_64; less critical on my arm and trial x86_64 -currents) than to puzzle out and fix later what went wrong, even if occurrence is rare. I accept the tradeoff of not going through those occasional "learning experiences" :-).
When I mess things up on Slackware it's a big, big problem that I try hard to avoid. When I mess things up on Slackware ARM it's a few mins re-writing the image and copying over whichever files I need. Sometimes with the latter I'll re-install from scratch, just to have a fresh start and the chance to revise my methods. HAHA!

[EDIT] Just uploaded the new batch by the way... https://sarpi.fatdog.eu/index.php?p=downloads

Last edited by Exaga; 01-02-2021 at 09:31 AM. Reason: edit
 
1 members found this post helpful.
Old 01-02-2021, 10:05 AM   #19
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware [ARM]
Posts: 689

Original Poster
Rep: Reputation: 414Reputation: 414Reputation: 414Reputation: 414Reputation: 414
Quote:
Originally Posted by pchristy View Post
Thanks also for the links both here and in the other (related) thread. The information is out there, but you need to know where to look! I now have a few pointers!
No problem. Asking is always the best policy with Slackware ARM. In this LQ forum we don't have any 'one-upmanship' or competitions between users to project themselves as the most learned gurus, or each user offering a 'better' solution than the last. Unless someone actually does, and then it's usually addressed and dealt with very graciously.

I don't think you're being critical at all. You're doing what you like/want to do, and that's admirable. SARPi has [had] its critics and objectors. As long as the Slackware Team guys are OK with how I do things, that's all that matters. I try to make it as good at it can possibly be and then, at least, I know it's on the right trajectory.
 
2 members found this post helpful.
Old 01-03-2021, 12:21 PM   #20
TheTKS
Member
 
Registered: Sep 2017
Location: The deep south... of Canada
Distribution: Slackware, Xubuntu, OpenBSD, elementary, Raspberry Pi OS, Puppy, TinyCore
Posts: 251

Rep: Reputation: 152Reputation: 152
Quote:
Originally Posted by Exaga View Post
I did notice some weird hanging when upgrading and rebooting - but only for the first time - on the RPi3 and RPi4 - but not on the RPi (1) and RPi2. After powering off-on and getting past the first reboot it seems to operate within established parameters very well indeed.

The hang was something to do with the bootloader because it didn't even attempt to load the kernel. If it's a boot-firmware issue that caused it then I'm sure the RPi guys will be aware and on top of it. I'll be keeping an eye on any similar incidents when I build the next SARPi batch.
Quote:
Originally Posted by Exaga View Post
[EDIT] Just uploaded the new batch by the way... https://sarpi.fatdog.eu/index.php?p=downloads
Just upgraded to 5.10.4 on RPi4, but unlike my smooth 5.10.2 upgrade and like your 5.10.2 upgrade, I got a hang - it stopped at "Rebooting". Power off-on [edit: for the first reboot only] and with several flawless reboots after, I can confirm that, like for you, it only hung at first reboot after upgrade.

This time my upgrade path was this:
Code:
# installpkg sarpi4-kernel-source-5.10.4-armv7l-1_slackcurrent_02Jan21_sp1.txz kernel-modules-sarpi4-5.10.4-armv7l-1_slackcurrent_02Jan21_sp1.txz kernel_sarpi4-5.10.4-armv7l-1_slackcurrent_02Jan21_sp1.txz
# upgradepkg kernel-headers-sarpi4-5.10.4-armv7l-1_slackcurrent_02Jan21_sp1.txz
# installpkg sarpi4-boot-firmware-armv7l-1_slackcurrent_02Jan21_sp1.txz sarpi4-hacks-4.0-armv7l-1_slackcurrent_02Jan21_sp1.txz
# removepkg sarpi4-boot-firmware-armv7l-1_slackcurrent_25Dec20_sp1 sarpi4-hacks-4.0-armv7l-1_slackcurrent_25Dec20_sp1
(then first reboot with hang, power off-on, subsequent reboots ok.)

Reviewing a difference in installed kernel and sarpi packages on my RPi between these two upgrades: I still had a couple of SlackwareARM packages before the upgrade to 5.10.2. I replaced those with Sarpi packages before the 5.10.4 upgrade. Could the cause of the first-reboot hang be there, or is it more likely to originate in the boot-firmware or elsewhere?

- Before upgrade to 5.10.2, flawless first reboot following upgrade
Code:
kernel-firmware-20201130_7455a36-noarch-1
*kernel-headers-5.4.81-arm-1
kernel-modules-sarpi4-5.4.80-armv7l-1_slackcurrent_01Dec20_sp1
*kernel-source-5.4.81-arm-1
kernel_sarpi4-5.4.80-armv7l-1_slackcurrent_01Dec20_sp1
sarpi4-boot-firmware-armv7l-1_slackcurrent_01Dec20_sp1
sarpi4-hacks-4.0-armv7l-1_slackcurrent_01Dec20_sp1
- Before upgrade to 5.10.4, first reboot hung following upgrade
Code:
kernel-firmware-20201130_7455a36-noarch-1
kernel-headers-sarpi4-5.10.2-armv7l-1_slackcurrent_25Dec20_sp1
kernel-modules-sarpi4-5.10.2-armv7l-1_slackcurrent_25Dec20_sp1
sarpi4-kernel-source-5.10.2-armv7l-1_slackcurrent_25Dec20_sp1
kernel_sarpi4-5.10.2-armv7l-1_slackcurrent_25Dec20_sp1
sarpi4-boot-firmware-armv7l-1_slackcurrent_25Dec20_sp1
sarpi4-hacks-4.0-armv7l-1_slackcurrent_25Dec20_sp1
If the worst that happened during upgrade is a hang on first reboot, then I'm not worried.

Happily running SlackwareARM -current with 5.10.4 on RPi4!

TKS

Last edited by TheTKS; 01-03-2021 at 10:11 PM.
 
1 members found this post helpful.
Old 01-03-2021, 01:32 PM   #21
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware [ARM]
Posts: 689

Original Poster
Rep: Reputation: 414Reputation: 414Reputation: 414Reputation: 414Reputation: 414
Quote:
Originally Posted by TheTKS View Post
If the worst that happened during upgrade is a hang on first reboot, then I'm not worried.

Happily running SlackwareARM -current with 5.10.4 on RPi4!
Thanks very much for posting your results TKS. I'm thinking, "damn this issue!" It could be one of those headache boot-firmware niggles (again).

For me this time around with kernel 5.10.4 everything went perfectly on the RPi3/4 but it wasn't on the RPi2. Like your experience, and as before with my own, power off/on was successful the second time around, and every subsequent occasion.

The RPi (1) is also suffering a hang on boot, right before networking is initialised, but it *is* eventually successful. Having previously booted as expected with kernel 5.10.2, I'm currently looking into what could be causing it. Very strange indeed.
 
1 members found this post helpful.
Old 01-05-2021, 06:31 PM   #22
gus3
Member
 
Registered: Jun 2014
Distribution: Slackware (x86 and ARM)
Posts: 432

Rep: Reputation: Disabled
Quote:
Originally Posted by Exaga View Post
The RPi (1) is also suffering a hang on boot, right before networking is initialised, but it *is* eventually successful. Having previously booted as expected with kernel 5.10.2, I'm currently looking into what could be causing it. Very strange indeed.
Looking in /etc/rc.d/rc.M: right before the network gets set up (rc.inet1), the entropy-gathering haveged is started (rc.haveged). Do you see the line "Starting haveged entropy daemon" before the delay, or after?

I am very interested in narrowing down the culprit program, and figuring out what's going on under the hood. Entropy gathering is my first suspicion, from this thread: https://www.linuxquestions.org/quest...on-4175680148/ (disclaimer: I popped up a few times in that thread).

But note that entropy-gathering in the kernel was significantly re-worked in v5.6 by eliminating the blocking pool and pushing responsibility for crypto-secure into user-space.

As a side question: maybe you also have a file /etc/rc.d/rc.rngd ? It can get called after setting up haveged. I find references to "rngd" in the SBo packages "rng-tools" and "onerng". Do you have either of those packages installed?
 
Old 01-06-2021, 05:02 AM   #23
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware [ARM]
Posts: 689

Original Poster
Rep: Reputation: 414Reputation: 414Reputation: 414Reputation: 414Reputation: 414
Quote:
Originally Posted by gus3 View Post
Looking in /etc/rc.d/rc.M: right before the network gets set up (rc.inet1), the entropy-gathering haveged is started (rc.haveged). Do you see the line "Starting haveged entropy daemon" before the delay, or after?

I am very interested in narrowing down the culprit program, and figuring out what's going on under the hood. Entropy gathering is my first suspicion, from this thread: https://www.linuxquestions.org/quest...on-4175680148/ (disclaimer: I popped up a few times in that thread).
That's not a disclaimer. That's an accreditation!

Quote:
Originally Posted by gus3 View Post
But note that entropy-gathering in the kernel was significantly re-worked in v5.6 by eliminating the blocking pool and pushing responsibility for crypto-secure into user-space.

As a side question: maybe you also have a file /etc/rc.d/rc.rngd ? It can get called after setting up haveged. I find references to "rngd" in the SBo packages "rng-tools" and "onerng". Do you have either of those packages installed?
Very many thanks for this advice. I don't have '/etc/rc.d/rc.rngd', or the 'rng-tools', or 'onerng' pkgs installed. I do have 'haveged-1.9.13' pkg installed on Slackware ARM current, but not on the RPi (1) Slackware ARM 14.2 version.

OK! So, aside from not believing this was a Slackware ARM 14.2 problem, unequivocally because there has been only one pkg update since the start of this issue and now - and that was 'glibc-zoneinfo*.txz', the timezone database, which has no bearing on this what-so-ever - I wasn't willing to make any changes to the OS infrastructure in any case. Experience has taught me that, under these circumstances, it's a complete waste of my time when there are inklings of the bespoke RPi boot-firmware being the culprit.

Yesterday there were changes to a few files in the RPi Github Linux kernel source and a new boot-firmware commit. So I've built and tested accordingly and found that the strange boot-hang has now been resolved and the Raspberry Pi (1) is now booting, loading the kernel and the Slackware ARM 14.2 OS as expected. However, the device suffered the "initial reboot-hang after upgrading" problem as I'd experienced on other RPi devices. On all subsequent reboots it seems to work perfectly.

As a consequence I am done with this and this and have looked into the permutations of the 'shutdown', 'halt' and 'poweroff' commands. I'm very much open to advice on this one because I've wasted enough time on it already. So, perhaps somebody might be so kind as to apprise me of their most assured and/or correct way of shutting down and rebooting the system successfully. Thanks in advance for sharing any experience(s) with this.

SARPi installer and system pkgs for the Raspberry Pi (1) have been updated [now running kernel 5.10.4] and are available from https://sarpi.fatdog.eu/index.php?p=downloads and https://slackware.uk/sarpi mirror.
 
1 members found this post helpful.
Old 01-11-2021, 08:56 PM   #24
gus3
Member
 
Registered: Jun 2014
Distribution: Slackware (x86 and ARM)
Posts: 432

Rep: Reputation: Disabled
FWIW

I updated my RPi 2 a couple hours ago, with the latest firmware and kernel packages from Exaga. No hiccups at all.

A WD Pi Drive is my primary, but /dev/mmcblk0p1 is mounted on /boot.

I did a straight "upgradepkg." And I took the plunge, as a test, to see if I'd get through it unscathed. The package order: firmware, headers, kernel, modules. (I skipped the hacks package, since I already took care of those on my own, a couple years ago.)

Once the packages were upgraded, I flushed buffers and rebooted. The re-start was successful, with no hangs or anything. It went straight from "reboot" command to a new kernel with a login prompt, with no manual intervention required.
 
1 members found this post helpful.
Old 01-11-2021, 09:50 PM   #25
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware [ARM]
Posts: 689

Original Poster
Rep: Reputation: 414Reputation: 414Reputation: 414Reputation: 414Reputation: 414
Quote:
Originally Posted by gus3 View Post
I updated my RPi 2 a couple hours ago, with the latest firmware and kernel packages from Exaga. No hiccups at all.
Thanks for the feedback gus

Today I've built, tested, and uploaded a new SARPi batch running RPi kernel 5.10.6 which seems to be working as expected without any errors. RPi (1) is still building and will be another day or so before that becomes available.

I skipped kernel 5.10.5 source because I became somewhat bemused with sifting through device drivers and kernel objects trying to find out what was terminally corrupting the ext4 root filesystem on the RPi2 and 3.
 
Old 01-12-2021, 05:17 PM   #26
gus3
Member
 
Registered: Jun 2014
Distribution: Slackware (x86 and ARM)
Posts: 432

Rep: Reputation: Disabled
Quote:
Originally Posted by Exaga View Post
I skipped kernel 5.10.5 source because I became somewhat bemused with sifting through device drivers and kernel objects trying to find out what was terminally corrupting the ext4 root filesystem on the RPi2 and 3.
Does this article show any resemblance to your issue?
 
Old 01-13-2021, 02:43 AM   #27
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware [ARM]
Posts: 689

Original Poster
Rep: Reputation: 414Reputation: 414Reputation: 414Reputation: 414Reputation: 414
Quote:
Originally Posted by gus3 View Post
Does this article show any resemblance to your issue?
I can't say because that article requires a subscription/login to view the information.

I know this does:

https://github.com/raspberrypi/linux/issues/4054

and this does too:

https://github.com/raspberrypi/linux/issues/4055
 
Old 01-13-2021, 06:47 PM   #28
gus3
Member
 
Registered: Jun 2014
Distribution: Slackware (x86 and ARM)
Posts: 432

Rep: Reputation: Disabled
Quote:
Originally Posted by Exaga View Post
I can't say because that article requires a subscription/login to view the information.
Sorry, I forgot all about that.

I checked your two GitHub links, and no, it's nothing like I thought it was. The link I gave was about how a compiler bug in GCC 4.9 for arm64 caused a use-after-free error on the kernel stack, specifically affecting the ext4_chksum() function. The resulting bug in the kernel has a window of exactly one instruction, during which an interrupt can corrupt the stack frame and overwrite the calculated checksum.

The mis-compilation was fixed six years ago, during pre-5.0. But there are two catches: the kernel still (officially) supports compilation with GCC 4.9, but not everyone has upgraded their GCC set with fixed 4.9.x versions.

(For the nerds: ext4_chksum() returned a value from a de-referenced pointer, a la

Code:
return *(u32 *)desc.ctx;
It turned into "fetch desc; free local stack space; get ctx from desc, but hopefully before an interrupt occurs...." The problem is that ctx is a member of desc, and desc has already been freed from the stack. The compiler lost the "live data" attribute between the desc structure and the ctx inside it. Hence, the ctx member could get over-written by an interrupt.)
 
Old 01-15-2021, 02:40 AM   #29
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware [ARM]
Posts: 689

Original Poster
Rep: Reputation: 414Reputation: 414Reputation: 414Reputation: 414Reputation: 414
Quote:
Originally Posted by gus3 View Post
Sorry, I forgot all about that.
No problem gus. I am an occasional visitor to that site, especially for the https://lwn.net/Kernel/ content. There's quite a lot of very insightful and educational information available for Linux in general on there.

The issue with the RPi kernel 5.10.5 was a strange one. Networking would fail/crash and the root filesystem superblock was somehow removed/deleted. Trying to repair the ext4 filesystem left me with a 'lost and found' folder and nothing else. Trying to restart networking was futile. So, it was a very terminal fault and I wasn't able to pinpoint the cause. However, it was fixed (thankfully) quite quickly in the next kernel release.
 
Old 01-17-2021, 01:19 PM   #30
TheTKS
Member
 
Registered: Sep 2017
Location: The deep south... of Canada
Distribution: Slackware, Xubuntu, OpenBSD, elementary, Raspberry Pi OS, Puppy, TinyCore
Posts: 251

Rep: Reputation: 152Reputation: 152
Did the big Xfce & KDE merge, then sarpi kernel & packages (5.10.4 to 5.10.7) upgrade today.

A few notes and a few questions:

- No hang on first reboot

- /etc/rc.d/rc.local was empty, rc.local.orig contained
Code:
/usr/sbin/sntp -sS 0.pool.ntp.org > /dev/null 2>&1
I added this to rc.local, with a 5 second delay (without the delay, correct time isn't set)
Code:
sleep 5 ; /usr/sbin/sntp -sS 0.pool.ntp.org > /dev/null 2>&1
=> Is sarpi4-hacks-4.0-armv7l-1_slackcurrent_17Jan21_sp1 not supposed to make changes to rc.local?

- All of these rc.modules are in /etc/rc.d
Code:
-rwxr-xr-x 1 root root   778 Dec 15  2015 rc.modules*
-rwxr-xr-x 1 root root  1745 Dec 25 06:04 rc.modules-5.10.2-v7l-sarpi4*
-rwxr-xr-x 1 root root  1745 Jan  2 01:44 rc.modules-5.10.4-v7l-sarpi4*
-rwxr-xr-x 1 root root  1745 Jan 17 03:37 rc.modules-5.10.7-v7l-sarpi4*
-rwxr-xr-x 1 root root  1745 Dec  1 02:43 rc.modules-5.4.80-v7l-sarpi4*
-rwxr-xr-x 1 root root   689 Dec 15  2015 rc.modules.local*
=> Is there any reason *not* to delete all but the most recent rc.modules-5.10.7-v7l-sarpi4? (rc.modules.local can stay for possible future use, as there is nothing uncommented.)

- consolekit is in /etc/rc.d
Code:
-rwxr-xr-x 1 root root   572 Nov 29  2018 rc.consolekit
=> Now that ConsoleKit2 is gone from -current, is there any reason not to delete this?

So here is the order of steps I took for this upgrade. It seems to work so I'll stick with it unless I hear of a good reason to change it.
Code:
bash-5.0$ su -l
# slackpkg update
# slackpkg install-new [deselected kernel packages - I haven't blacklisted them]
# slackpkg upgrade-all [deselected kernel-firmware - I haven't blacklisted it]
# installpkg sarpi4-kernel-source-5.10.7-armv7l-1_slackcurrent_17Jan21_sp1.txz kernel-modules-sarpi4-5.10.7-armv7l-1_slackcurrent_17Jan21_sp1.txz kernel_sarpi4-5.10.7-armv7l-1_slackcurrent_17Jan21_sp1.txz
# upgradepkg kernel-headers-sarpi4-5.10.7-armv7l-1_slackcurrent_17Jan21_sp1.txz
# slackpkg upgrade-all [upgrade kernel-firmware]
# upgradepkg sarpi4-boot-firmware-armv7l-1_slackcurrent_17Jan21_sp1.txz sarpi4-hacks-4.0-armv7l-1_slackcurrent_17Jan21_sp1.txz
Rebooted, checked a few things to make sure that the OS, DE and applications I commonly use work, then:
Code:
bash-5.0$ su -l
# removepkg /var/log/packages/*5.10.4*
# slackpkg clean-system
Great success! Thank you again for Sarpi, exaga, and helping us all skip over 5.10.5 funny business.

TKS

Last edited by TheTKS; 01-17-2021 at 01:24 PM.
 
  


Reply

Tags
raspberry pi, raspberry pi 2, raspberry pi 3, raspberry pi 4, slackware arm


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
Slackware ARM 14.2 on a Raspberry Pi (1) - SARPi kernel 5.4.65 update Exaga Slackware - ARM 4 09-18-2020 08:25 AM
[SOLVED] RPi4 (Sarpi) - rc.local ntpdate "hack" fails to update date/time eduardr Slackware - ARM 8 03-31-2020 07:56 PM
SARPI on Pi3 - Ran slackpkg update & slackpkg upgrade-all and now won't boot, can't find init petejc Slackware - ARM 11 03-25-2020 04:30 AM
SARPi website new URL - sarpi.co.uk Exaga Slackware - ARM 4 01-28-2018 06:36 PM

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

All times are GMT -5. The time now is 06:37 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
Open Source Consulting | Domain Registration