Merry Christmas ARMed Slackers! Felicitations and best wishes to you all over the festive season.

The sarpi installers (and relevant pkgs) for Slackware ARM current now runs kernel 5.10.x on the Raspberry Pi 2, 3 and 4. Due to this being a new kernel [major revision] update, any and all feedback will be much appreciated. Especially regarding any unexpected anomalies.

I'm still working on building kernel 5.10.x on the Raspberry Pi (1) and *if* that pans out OK it'll be at least a couple of days before that becomes available. In the interim, the latest sarpi update is still running kernel 5.4.x on this device.

All sarpi downloads are available from https://sarpi.fatdog.eu/index.php?p=downloads and https://slackware.uk/sarpi mirror.

<<< is sending you a PM

kernel 5.10.2 has been built and tested on the Raspberry Pi (1) and is working very well indeed. As always, it will be much appreciated if anybody using the SARPi shizzle keeps me apprised me of any bugs, glitches, problems, etc. that they encounter.

The sarpi installer and pkgs for Slackware ARM 14.2 are available from: https://sarpi.fatdog.nl/index.php?p=downloads and https://slackware.uk/sarpi mirror.

have fun.



<<< replied

By the way, none of the sarpi installers or pkgs were cross-compiled. They were all built on the architecture on which they are intended to run.

3 members found this post helpful.

5.10.2 so far, so good here - thanks!

TKS

1 members found this post helpful.

Thanks TKS. I've been running kernel 5.10.2 for a few days now and there doesn't seem to be any problems while 'running it' at all. 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.

Hope you had a good Christmas!

1 members found this post helpful.

My upgrade to 5.10.2 today on my RPi4 went smoothly. No weirdness, no hangs on first reboot.

A few of my upgrade notes in case you can draw any hints from this:
- This was my first upgrade after installing new about a week ago (Dec 23, I think.) I had messed up my previous installation, so I installed fresh on a new 64GB SD micro card, using the Sarpi installer downloaded at that time and very closely following your excellent instructions on the Sarpi website.
- SlackwareARM -current was the most recent, from Dec 7, including kernel-firmware.
- So before upgrading, I had these kernel and sarpi packages in /var/log/packages/. Note source and headers were still stock SlackwareARM 5.4.81, not the sarpi versions. (Is there a good reason to change or not to change in the sarpi installer, to replace SlackwareARM source and headers with the sarpi versions? If no, then a note in the Sarpi instructions that these are available for manual replacement, if not already on the website.)
- I upgraded in this order:
- Then I looked at /var/log/packages again and decided it might not be good to have two versions of sarpi4-boot-firmware and sarpi-hacks, so did:
- So then I had this in /var/log/packages:
- Rebooted normally, tried a bunch of applications, and everything seemed to work ok, and
gave
so I did:
- There were a few warnings as removepkg ran. Nothing caught my eye as catastrophic (but I still consider myself barely beyond newbie, so take that for what it's worth) and things seemed to still run fine.

- After that, my /var/log/packages contained:
I've rebooted once since, and again SlackwareARM booted and has been running normally.

OK, those "few" notes turned out a bit longer than I expected.

BTW, any comments on the upgrade steps or order I used, aside from using upgradepkg in future for kernel-header, sarpi4-boot-firmware and sarpi4-hacks?

I did have a good Christmas, thanks for the good wishes. Likewise I hope you had a good Christmas and wish you and all here a Happy New Year!

TKS

First of all, many thanks for this information. Your notes are very enlightening and gives much insight into how other users work. Great reading it is!

Interesting. Then perhaps it's the difference between the way in which you and I install new pkgs that causes the initial reboot-hang after upgrading. I will explain in more detail shortly.

When you're installing (or re-installing) Slackware ARM on a RPi device then it makes sense to use the latest SARPi installer - IF that's your chosen method. This is because it will include an 'initrd.gz' which has been created from the latest 'uinitrd-armv7.img' which MoZes creates and makes available. This image file will always contain the latest version of files that he has intended for end-users, such as you and me. It contains the Slackware installer and all the other tools and goodies which facilitates the installation of Slackware ARM, as it makes things much, much simpler and a lot less laborious. So, any changes/updates by MoZes to the Slackware installer and/or content of his initial RAM disk image will feature in the 'initrd.gz' shipped with SARPi to ensure it's very much up-to-date with Slackware ARM proper.

Linux kernel source pkg: there are occasions when building your own binaries requires the kernel source to be present. Not everything you might build requires the kernel source, but if you're ever in a situation where you get a "error: no kernel source found in /usr/src/linux" type message while compiling then you will certainly need to download the kernel source, or install it via a pkg like the one SARPi provides. It should always be the source that was used to build your currently running kernel. The sarpi-kernel-source pkg is always the exact source that the sarpi kernel and modules were built from for this reason. You can't just download any old kernel source and expect it to work as intended.

Linux kernel headers pkg: this is only important to users who need them. I'm not being flippant here. Kernel header files are all the *.h files containing functions which the kernel makes available for other programs to use. These define the interface(s) between components of the kernel and also between the kernel and user-space. They aren't usually needed, errr... unless you need them! (sorry!) "Why or when would I need them?" Say for example, when building external modules you're going to need the exact version of headers from the kernel that the modules are intended for. Or else it's just going to get real messy, real quick, and nothing's going to work as you expected. You may already know that the established standard location for the kernel source is '/usr/src/linux' but it's not the same when building external modules. I've asked MoZes about kernel headers, more than a few times (because he's much more au fait with them), and I think we briefly touched on this topic on one of the Slack chat podcasts some time ago.

Many times in the past I have had the incorrect sarpi pkgs in place and used 'installpkg' - which has been headache inducing, on such occasions. Now-a-days I put all the SARPi pkgs in one location and 'upgradepkg /path/to/*.txz' - kernel, modules, boot-firmware, and sarpi-hacks. This is the difference between how you do it and I do it and might be why I suffered an unexpected reboot-hang. Next time I am going to do it your way, if I remember. Haha!

Thanks. I spent my Christmas Day (morning) cooking for approx. 4 hours and testing the latest SARPi installer shizzle in between (which I'd left building overnight). Then I uploaded it all and had lunch. Was a quiet but productive day.

1 members found this post helpful.

I've spoken briefly with Exaga, in private, about trying to update my boot firmware and kernel. For the past year and a half, anytime I tried to update either of them, I'd end up with an RPi that didn't boot. Maybe it wouldn't even give me the four-color video test. So I'd pull the SD card and restore the /boot partition. I was stuck on kernel 4.20.16 or so.

Well, today, I decided to try out his SARPi packages. I took a backup of /boot, one more time, and then installed the firmware, kernel, modules, and headers. I inspected everything carefully, and then rebooted.

Black screen. The green LED flashed once, and then stayed off.

I unplugged the power, pulled the SD card, and restored the power. The green LED came on, and stayed on. Okay, power off, re-insert card, power back... one flash and off. Still nothing on the monitor. Another failed update.

So I put the SD card into my netbook and tried to restore the /boot partition. And even that step failed, for lack of space. So I wiped the first (boot) and second (swap) partitions, and made one big first partition for boot. Then I restored the last known working /boot partition, put it back into the RPi, and plugged it in.

Black screen, one flash from the green LED. The restore from backup was officially a lost cause.

Now, before I proceed, I should point out that I have a Pi Drive from Western Digital, and use that as my primary storage on the RPi. I use the SD card solely for /boot; the Pi Drive is so much faster, and less prone to wear over time. Plus, I had manually updated the firmware and kernels for a few years now. Those weren't part of Slackware's packaging system, at least on my RPi, until today. And you see how that went.

So I decided on a plan B: get the SARPi installer image, and at least get a working CLI prompt that way. Then I could diagnose the situation, and pursue remedies. Fine, that's what I did.

And as the kernel was booting, I got an idea : all of Exaga's packages are currently using kernel 5.10.2. Maybe I could edit config.txt and cmdline.txt to use my Pi Drive as the root, instead of the installer's init ramdisk? After all, the x86 Slackware installer CD's include instructions on how boot in "rescue mode" with an alternate command line. Why not try it with the SARPi installer? Comment out the last line of config.txt, and change the "root=" and "rootfs=" in cmdline.txt to match my system. I didn't have to worry about kernel modules being on the root partition; they got installed before everything went on the fritz.

I am very pleased to say, I now have a running Raspberry Pi 2 model B, with Slackware-current and kernel 5.10.2, thanks to Exaga's SARPi installer image. For now, I'll keep it as my /boot partition.

As I remarked to him, "a successful tool is one that's used in ways its designer didn't anticipate." Therefore, I'm putting this success story on record.

2 members found this post helpful.

I'm more than happy to be of assistance and very pleased you were able to find a solution. Manipulation of the config.txt and cmdline.txt files content is often what's needed to solve a multitude of errors and unexpected results. Been there so many times myself with the RPis and it's never Slackware ARM that causes problems such as yours. It's usually a misconfiguration, or the boot-firmware, or something missing in the kernel which stops the device(s) from booting normally.

You asked, in and amongst, if anyone had created a rescue disk from the SARPi installer image. This actually is (or can be used as) a 'rescue disk' on the RPi devices and that's nothing at all to do with me. That's down to Stuart (MoZes) and the way he creates his 'initial RAM disk image'. Which is ~95% of what the SARPi 'initrd' is created from. The rest is just the '/lib/modules/$(uname -r)/' that I've built which are needed for the hardware, and a 'README' file.

Once the SARPi installer image is booted, it loads the 'initrd' which then gives you access to all the commands and abilities to chroot, mount partitions/filesystems, copy/edit/create/overwrite/delete files, install/upgrade/remove pkgs, so on and so forth. Whenever I've botched the bootloader, or kernel, or Slackware ARM itself, I'll boot the RPi from another working SD card or copy over new /boot dir files and try to recover it from there, if possible. It's so easy to mount other USB storage devices and manage any issues in this way. Thanks for the thanks but it's ultimately MoZes' wizardry and discernment that makes all this possible with Slackware ARM. I'm sure nobody will disagree with me on that note.

1 members found this post helpful.

Between your posts and gus3's, there's a lot there and I'll have to read in detail later, but I'm glad you've both posted in detail here, as I have a lot to learn about kernel packages and about booting. Your notes are sure to help along with more digging into background. I'm glad to hear my notes were of some help to you.

A related note, for how I normally upgrade kernel packages on x86_64 Slackware 14.2 and -current, I have been using Lysander666's blog as a reference.
https://www.linuxquestions.org/quest...ackware-37876/
- then I run /usr/share/mkinitrd/mkinitrd_command_generator.sh for the new kernel
- then I reboot and try a few applications. If things look like they're working right, I removepkg old source, modules, huge and generic.

I adapted those steps (imperfectly) for this upgrade. I expect upgradepkg for sarpi4-boot-firmware and sarpi4-hacks instead of the two-step installpkg and removepkg is fine. It hasn't failed me on upgrades on my previous installation that I'm aware of (recall that I corrupted that installation by not paying attention to space on my 16GB card and letting it run out of space mid-update.) I just guessed at whether upgrading those two could or should come before or after the others.

Installing/upgrading/removing individually and in the right order is a bit more time consuming at update/upgrade time than doing it as a batch, but prevents me from installing the wrong packages (mostly - I still managed to do that once, but caught and fixed the mistake in time.)

What I'm still not clear on is whether order matters for all of those packages. Examples: does it matter if boot-firmware is first, last or anywhere in between; must sarpi4-hacks come last?

TKS

1 members found this post helpful.

For SARPi, no. It doesn't matter in which order you install 'sarpi*.txz' pkgs. As long as you don't just install 'kernel_sarpi*.txz' and then reboot. That would be terminally fatal to the boot operation because there'd be no modules to accompany the kernel. Best if you're using the SARPi shizzle to install kernel, modules, and boot-firmware pkgs all together in any order. The 'sarpi-hacks*.txz' isn't mission critical but skipping it will stop your wireless from working on the RPi3/4. My way is to put all the SARPi pkgs in /tmp/sarpi-pkg dir (I'll create this dir specifically for the purpose and delete it afterwards) and use these commands, as 'root' user :

With packages that are not already installed 'upgradepkg' will skip them. So, for example, you'll receive a message saying something like "Error: no existing sarpi4-kernel-source*.txz package found - skipping upgrade." Sorry, I can't remember the exact error message but it's of that nature.

However, when installing Slackware ARM, yes - for certain packages the order of them is important. Like the 'aaa_*.t?z' pkgs in Slackware are named that way for a specific reason. MoZes filled me in on why they are like that and it's very logical - they must be installed first before all others! Thankfully, the Slackware installer takes care of all the hard work so end-users can rest easy on that topic.

[EDIT]
There's no need to run the mkinitrd unless you intend to create an initial RAM disk image. Is that an x86 thing?

Running out of disk space is a PITA and I've done that more than a few times. As a precautionary measure I got rid of all my 16GB cards many years ago and decided at the very least every SARPi build system would use a 32GB card. Today the Rpi(1),2/3/4 all have 64GB cards and the RPi4 also uses a SSD plugged in to the USB3 port for certain build runs.

1 members found this post helpful.

As I was building/upgrading the latest SARPi batch I thought this would be a good opportunity to show you properly how I upgrade these pkgs. All *.txz pkgs are copied to and located in '/tmp/zxc/' dir this time around. Sure, it's the lazy way of doing it. Then I simply do this...

Too much to copy and paste just to show an example, but the order is; headers, modules, kernel, boot-firmware, sarpi-hacks, and kernel source pkgs. As you can see, for the headers pkg, which is not already installed, there's an error message. That's no big deal because this is purely a RPi2 build system and I don't have any need right now for the pkgs that will display this error. It's of no consequence in which order these SARPi pkgs are installed, as long as all the important pkgs are installed at the same time. 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.

After rebooting...

Then I will test the functionality of Slackware ARM, use the system, run some of my own scripts, update the OS with official pkgs from MoZes, and make sure it's all working as expected as far as my own requirements are concerned. When I'm happy I'll build the same SARPi batch again, and those are the files which will ultimately become available to download and use.

1 members found this post helpful.

Surely this depends on how the kernel is compiled? If it is compiled with ext4 as a module, rather than built in, it won't be able to load the required module to read the root partition as the modules usually reside in /lib/modules/(kernel number) - which is on the ext4 /root partition! The initrd will provide this module during the boot process to enable the kernel to read the root partition.

Certainly, on x86(-64) systems using the generic kernels, an initrd is essential to get it to boot.

Of course, if ext4 is compiled in to the kernel - as it is in the "huge" kernel - then you don't need an initrd. Normally the same would apply to vfat for the /boot partition too, but the Pi seems to be able to read vfat by default - presumably something in the "bios" provides this functionality?

I'm missing a lot of information here! The other missing piece of the jigsaw is where the modules are installed. On x86 type systems they are installed in /lib/modules/(kernel number), but they *could* be put on the /boot partition (provided there is room!) as long as the system was configured to look for them there.

Looking at the differences between the slarm64 boot system and sarpi(64), it would appear that slarm64 requires an initrd, whereas sarpi doesn't. This maybe why I've been having problems with my "hybrid" system, but I thought I had compensated for that. Still didn't work though! :/

--
Pete

1 members found this post helpful.

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. I could go into the permutations of acceptable vfat partitions but I'm not going to complicate the matter. The closed-source boot-firmware that boots the device is why it needs to be this way and cannot be changed, as it can with u-boot.

As with Slackware [ARM], SARPi kernels/modules support all filesystems. Quite sure if the device supported booting from a "ext5000" formatted partition it would be possible if the module existed and could be loaded by the kernel at boot time. The difference (and I'm asserting here) is that slarm64 supports many more devices than just the Raspberry Pi and most significantly uses u-boot dynamics. There was a time when I thought about employing u-boot in conjunction with SARPi but... many years ago I spent a few weeks trying to work out the correct u-boot parameters on SolidRun's Hummingboard devices (I finally succeeded but it was a massive PITA effort). Plus I wanted nothing less than 100% assured and guaranteed success without wasting any time or needlessly worrying over the risk of boot-failure(s). So, I opted to stick with the official RPi boot-firmware.

1 members found this post helpful.