Slackware ARM on a Raspberry Pi - SARPi updates

Exaga · 10-01-2020, 10:15 AM

For the Raspberry Pi 3 & 4 the Broadcom brcmfmac firmware for wireless and Bluetooth is now updated automagically on a "per-build-process" basis. So it should always be current, and updated a lot quicker than it has been in the past - which was when I remembered and then could be bothered to do it.

For the Raspberry Pi (1) & 2 the Broadcom brcmfmac firmware has been omitted from the build process as it's superfluous in any event.

From now on all SARPi releases are created with a "batch ID" which covers the installer image, and packages. This is to make it easier for me to know which build process created a given file, when I have 100s of files with the same release-version in their filenames. Also easier for you if you have a problem then the *sarpi*.txz pkgs you've installed can be traced to a specific job.

For example, on the Rasperry Pi 3 - the "BuildLog Ref" from the latest SARPi3 batch [https://sarpi.fatdog.nl/index.php?p=rpi3getcurrent] ties in with the "Build Ref" on all other *sarpi* downloads from the same build process. So if you have installed the latest release versions onto your Slackware ARM system check out the BuildLog from the SARPi3 download page:

Code:

# SARPi3.SlackBuild Batch ID
BuildLog Ref..: SP320275102231

Then, if you look at the contents of your /boot/version-kernel-sarpi3.txt file you will see the same "Build Ref":

Code:

Package: kernel_sarpi3-5.4.68-armv7-1_slackcurrent_01Oct20_sp1.txz
Download: https://sarpi.fatdog.eu/index.php?p=downloads
Build ref: SP320275102231
Build date: 2020-10-01 10:24:55
Git revision: 61b7f805d

For the inquisitive, this SARPi "Build Ref" tag is unique to each individual build process and is broken down as follows:
SP3 = SARPi Project rpi3 build version
20 = 2 digit year
275 = 275th day of the year
102231 = 10:22:31 - the system time when this build process was requested

You'll also see a '/boot/version-sarpi3-hacks.txt' file [if you have installed this pkg] containing the same build ref. The "Build Ref" is also included in the accompanying README file for each installer image. This is how *sarpi*.txz pkgs can be identified as coming from the same build process from now on. Saves me ripping my hair out sometimes, if nothing else! Easy for you to tell me what the "Build Ref" is of your current files if/when any problems arise.

I'm sure there's a dozen other new things I could mention but it's mostly devel shizzle and would bore you. All you need to know is if the software works as designed, and it does.

New SARPi batch uploaded earler containing all the latest updates: https://sarpi.fatdog.nl/index.php?p=downloads

Desiderius · 10-02-2020, 02:13 AM

In fact SARPI downloads are VERY VERY OLD ! 1970-01-01 !

Quote:

Originally Posted by Exaga

For the Raspberry Pi 3 & 4 the Broadcom brcmfmac firmware for wireless and Bluetooth is now updated automagically on a "per-build-process" basis. So it should always be current, and updated a lot quicker than it has been in the past - which was when I remembered and then could be bothered to do it.

For the Raspberry Pi (1) & 2 the Broadcom brcmfmac firmware has been omitted from the build process as it's superfluous in any event.

From now on all SARPi releases are created with a "batch ID" which covers the installer image, and packages. This is to make it easier for me to know which build process created a given file, when I have 100s of files with the same release-version in their filenames. Also easier for you if you have a problem then the *sarpi*.txz pkgs you've installed can be traced to a specific job.

For example, on the Rasperry Pi 3 - the "BuildLog Ref" from the latest SARPi3 batch [https://sarpi.fatdog.nl/index.php?p=rpi3getcurrent] ties in with the "Build Ref" on all other *sarpi* downloads from the same build process. So if you have installed the latest release versions onto your Slackware ARM system check out the BuildLog from the SARPi3 download page:

Code:

# SARPi3.SlackBuild Batch ID
BuildLog Ref..: SP320275102231

Then, if you look at the contents of your /boot/version-kernel-sarpi3.txt file you will see the same "Build Ref":

Code:

Package: kernel_sarpi3-5.4.68-armv7-1_slackcurrent_01Oct20_sp1.txz
Download: https://sarpi.fatdog.eu/index.php?p=downloads
Build ref: SP320275102231
Build date: 2020-10-01 10:24:55
Git revision: 61b7f805d

For the inquisitive, this SARPi "Build Ref" tag is unique to each individual build process and is broken down as follows:
SP3 = SARPi Project rpi3 build version
20 = 2 digit year
275 = 275th day of the year
102231 = 10:22:31 - the system time when this build process was requested

You'll also see a '/boot/version-sarpi3-hacks.txt' file [if you have installed this pkg] containing the same build ref. The "Build Ref" is also included in the accompanying README file for each installer image. This is how *sarpi*.txz pkgs can be identified as coming from the same build process from now on. Saves me ripping my hair out sometimes, if nothing else! Easy for you to tell me what the "Build Ref" is of your current files if/when any problems arise.

I'm sure there's a dozen other new things I could mention but it's mostly devel shizzle and would bore you. All you need to know is if the software works as designed, and it does.

New SARPi batch uploaded earler containing all the latest updates: https://sarpi.fatdog.nl/index.php?p=downloads

Exaga · 10-02-2020, 07:56 AM

Quote:

Originally Posted by Desiderius

In fact SARPI downloads are VERY VERY OLD ! 1970-01-01 !

OK. There's a transition time between me uploading the files and them transferring to slackware.uk/sarpi repository. This period is no longer than 30 minutes. In years gone by I have put the SARPi website into "maintenance mode" while I'm uploading, so that users will not be otherwise inconvenienced. I shall start doing the same thing in future and then there's no confusion.

What you're seeing is a 'null_value' [UNIX epoch] date because the files cannot be located. My guess is that you caught that page early on during the upload. Next time please wait at least 30 mins before alerting me of a problem that doesn't exist at the end of that 30 minutes.

Desiderius · 10-02-2020, 08:38 AM

Quote:

Originally Posted by Exaga

OK. There's a transition time between me uploading the files and them transferring to slackware.uk/sarpi repository. This period is no longer than 30 minutes. In years gone by I have put the SARPi website into "maintenance mode" while I'm uploading, so that users will not be otherwise inconvenienced. I shall start doing the same thing in future and then there's no confusion.

What you're seeing is a 'null_value' [UNIX epoch] date because the files cannot be located. My guess is that you caught that page early on during the upload. Next time please wait at least 30 mins before alerting me of a problem that doesn't exist at the end of that 30 minutes.

Dont'worry @Exaga ; It was only a joke

Exaga · 10-02-2020, 08:56 AM

Quote:

Originally Posted by Desiderius

Dont'worry @Exaga ; It was only a joke

Not worried at all. Next time it'll be in maintenance mode for the duration and I'm not joking. Thanks for apprising me of your predicament.

For future reference if it's so urgent that you need to download a sarpi file without delay then they are available from slackware.uk/sarpi mirror.

eduardr · 10-06-2020, 11:41 AM

As always thanks Exaga for the latest updates!

One thing I haven't been clear about for some time regarding the packages "kernel-source" and "kernel-headers" that come with Slackware ARM. It appears I should be removing these and then installing kernel-headers-sarpiX and sarpiX-kernel-source?

The manual page https://sarpi.fatdog.eu/index.php?p=endinstall doesn't talk about removing these 2 system packages.

Exaga · 10-06-2020, 01:40 PM

Quote:

Originally Posted by eduardr

As always thanks Exaga for the latest updates!

One thing I haven't been clear about for some time regarding the packages "kernel-source" and "kernel-headers" that come with Slackware ARM. It appears I should be removing these and then installing kernel-headers-sarpiX and sarpiX-kernel-source?

The manual page https://sarpi.fatdog.eu/index.php?p=endinstall doesn't talk about removing these 2 system packages.

Hi eduardr.

The 'sarpi*-kernel-source*.txz' and 'kernel-headers-sarpi*.txz' packages are not included in the '/sarpi-extras' dir within the initrd.gz and do not get installed after Slackware ARM 'setup' with the usual packages. That's why they don't feature on the SARPi 'Completing the install process' page.

If you are building/compiling - especially system software - I would highly recommend installing the sarpi*-kernel-source package if you are using SARPi kernel/modules, etc. NB: not because there's anything wrong with MoZes' packages! Installing the 'sarpi*-kernel-source' package means you have the same source that was used to build the kernel you are running. So any software which depends on the kernel source being present when compiling will use the exact same version. To ensure compatibility, if nothing else.

The 'kernel-headers-sarpi*' package is not usually needed as the headers are included within the kernel source-tree. This package has been available in the event that the headers may be required. In years gone by it has been requested a few times. Installing it hopefully won't cause any problems - it will just overwrite the kernel headers which are already on the system. If you are already running a SARPi kernel that's perfectly fine. Otherwise I'm not sure - that would be in the "uncharted territory" category.

eduardr · 10-06-2020, 02:27 PM

Thanks for the detailed notes Exaga!

I've removed the system "kernel-source" and "kernel-headers" packages and installed the sarpi ones instead. I don't prefer to install on top of the system ones because then I have duplicate packages and it gets confusing, especially when the latest kernel source from slackware arm and kernel source from sarpi happen to be the same version (which happens once in a while).

Exaga · 10-06-2020, 03:27 PM

Quote:

Originally Posted by eduardr

Thanks for the detailed notes Exaga!

I've removed the system "kernel-source" and "kernel-headers" packages and installed the sarpi ones instead. I don't prefer to install on top of the system ones because then I have duplicate packages and it gets confusing, especially when the latest kernel source from slackware arm and kernel source from sarpi happen to be the same version (which happens once in a while).

The reason I decided to create a kernel-headers package was predominantly for aarch64 related building and testing. It's now super-quick for me to maintain and update the sarpi/sarpi64 build scripts after spending all of September rebuilding and restructuring them - so was quite easy to include in both.

You aren't required to install either the source or headers packages. They should be treated as "optional extras" for specific purposes, like package building/compiling and such.

Exaga · 10-21-2020, 03:22 AM

Updated SARPi installer image and packages running kernel 5.4.72 for Slackware ARM on a Raspberry Pi.

Available from https://sarpi.fatdog.eu/index.php?p=downloads

mralk3 · 10-23-2020, 01:29 PM

Exaga, please see: https://www.linuxquestions.org/quest...rm-4175684124/

I did find a bug in sarpi4-hacks doinst.sh, where /mnt/etc/rc.d/rc.local is not found by grep, due to the installer looking for /etc/rc.d/rc.local. I believe this will only happen during a fresh installation of Slackwarearm, but not when the package is upgraded on an existing system. I haven't ran explodepkg to see what the doinst.sh is actually doing though. I hope this helps.

Exaga · 10-24-2020, 01:20 AM

Quote:

Originally Posted by mralk3

Exaga, please see: https://www.linuxquestions.org/quest...rm-4175684124/

I did find a bug in sarpi4-hacks doinst.sh, where /mnt/etc/rc.d/rc.local is not found by grep, due to the installer looking for /etc/rc.d/rc.local. I believe this will only happen during a fresh installation of Slackwarearm, but not when the package is upgraded on an existing system. I haven't ran explodepkg to see what the doinst.sh is actually doing though. I hope this helps.

Many thanks for making me aware. From what you have described, if it's anything to do with 'ROOT=/mnt installpkg' at the end of Slackware ARM 'setup' (which I suspect it is) then I know exactly what causes it. I'll certainly investigate and get back to you.

mralk3 · 10-24-2020, 11:58 AM

Exactly, the error from grep pops up just before sarpi4-hacks finishes installing while running ROOT=/mnt installpkg, etc.

Exaga · 10-31-2020, 05:14 PM

Quote:

Originally Posted by mralk3

Exactly, the error from grep pops up just before sarpi4-hacks finishes installing while running ROOT=/mnt installpkg, etc.

mralk I am at a loss here. The latest sarpi-hacks pkg installs/upgrades as expected without error(s) and functions as designed.

Code:

+==============================================================================
| Upgrading sarpi3-hacks-3.0-armv7-1_slackcurrent_19Oct20_sp1 package using ../sarpi3-hacks-3.0-armv7-1_slackcurrent_31Oct20_sp1.txz
+==============================================================================
Pre-installing package sarpi3-hacks-3.0-armv7-1_slackcurrent_31Oct20_sp1...
Removing package: sarpi3-hacks-3.0-armv7-1_slackcurrent_19Oct20_sp1-upgraded-2020-10-31,22:03:48
Verifying package sarpi3-hacks-3.0-armv7-1_slackcurrent_31Oct20_sp1.txz.
Installing package sarpi3-hacks-3.0-armv7-1_slackcurrent_31Oct20_sp1.txz:
PACKAGE DESCRIPTION:
# sarpi3-hacks-3.0 (Raspberry Pi 3 modifications and fixes)
#
# This package modifies a new Slackware ARM installation with required
# fixes, specific to the Raspberry Pi 3. See the included README for
# further details of modifications and fixes.
#
#
#
# SARPi Project - https://sarpi.fatdog.eu - SP320305090611
#
Executing install script for sarpi3-hacks-3.0-armv7-1_slackcurrent_31Oct20_sp1.txz.
Package sarpi3-hacks-3.0-armv7-1_slackcurrent_31Oct20_sp1.txz installed.
Package sarpi3-hacks-3.0-armv7-1_slackcurrent_19Oct20_sp1 upgraded with new package ../sarpi3-hacks-3.0-armv7-1_slackcurrent_31Oct20_sp1.txz.

root@jook:/tmp#

My guess is that you have an older version which I remember on one batch did have an error in the doinst.sh code - '/etc/' was specified and it should have been 'etc/' which caused the error. Without spending too much time trolling through past builds I'm guessing it was around kernel 5.4.50 / 5.4.60 sort of period. If you have a build ref for the pkg you're using that would be a great help and save me wasting some time on it. If it's pre-build ref then forget about it. Haha!