H have a RazPi 4 and have done the following:

1. Grabbed the 4 Arm8 packages
2. Put the img.xz on /dev/mmcblk0p1 of the sdcard as instructed
3. Made mmcblk0p2=256M swap and mmcblk0p3 as ext4 as the rest of 16G.
4. Grabbed the 32Bit current and put it on a usb stick.
5. installed to the micro sdcard on the RazPi

All good so far, except I'm stuck in the install. I get a menu for the keyboard, root has no password, and I'm told to type 'setup' to get started.

I apparently have made an elementary mistake A quick look at the /boot dir left me thinking I had installed an Arm7(5.4.23) until /boot ran out of space, and the 5.4.36 one shows in /var/log/packages also. The (Armv8) kernel8.img seems alive & well, however. I ran 'ls -lht' on the /boot partition and the dates differbetween Arm7 & Arm8 stuff. They can go quickly enough, but how do I stop/delete the installer? What's it doing on the sdcard anyway?

@Business_Kid, somebody more knowledgeable will have to help you with this one, as I had no installation problems like this, but while I’m pretty new at this, I am going to grasp at straws - maybe you can get someone else started helping you with a few things:
- Confirm if you’re using Sarpi’s packages. I’m not aware of any other easy path to getting SlackwareARM running on RPi
- Post the information of the SD card you’re using. Exaga mentions that some have not worked, or not worked reliably.
- Have you got the RPi on ethernet?
- The old reliable: Bad installation? Try reinstalling or installing on another SD card.

I have nothing more than that, but maybe something in there can get you started until someone who really knows this can help.

TKS

Did you get the installer images form here -->https://sarpi.fatdog.eu/index.php?p=downloads

If not, I would highly recommend you do, and follow the install instructions on the Sarpi site.

If this is what you did, posting in the salckware Pi sub forum may get you more help.

I actually got them from sarpi64.fatgog.eu, but I sorted this, thanks. I finished reading /boot/README.

I should have removed the armv7 kernel stuff and then installed the kernel and initrd.gz at the END of setup/install. Just trying to get the wifi up now, and generally giving it that 'lived in' look. Tidying up minor details at a leisurely pace.
I won't sweat too hard, as I'm examining slarm64 packages atm. All arm64/aarch64 stuff is unofficial. What I'm hoping for is a little common sense,

• Minimal 100 &75 dpi fonts in X, when no modern apps use them (except xmms, iirc).
• No drivers for the gutless pci D/As that we used to call video cards supporting no modern sdandards.
• No bloatware (e.g. seamonkey, thunderbird, kde etc).

Slarm seems to have kde, but not xfce :-o.

EDIT: I take that back. It has xfce.

1 members found this post helpful.

The SARPi64 project (all of it) is strictly experimental. I was actually trying to do it "under the radar" on this side-project, mainly in case Mozes found out! It's very much of an unknown quantity and prototype by design. All-be-it great fun! I've had to do some questionable things to Slackware ARM in order to make it work and it is nowhere near in-line with the Slackware philosophy.

If you're just starting out with Slackware ARM on the Raspberry Pi 4 then it's advised to stick with the SARPi installer. The SARPi64 stuff requires some extra knowledge and experience to work with, but the Slackware ARM installation procedure is exactly the same. Incidentally, it's Slackware ARM [32-bit] that's installed with an ARMv8 kernel and modules [64-bit] with SARPi64 installer.

2 members found this post helpful.

Not sure about the RPi4 w/ its VideoCore VI, but the earlier models with VideoCore IV support routing the raw digital VGA output to the GPIO pins, in several bit depths and layouts. And you can buy adapter dongles to connect a VGA display to a RPi.

Look - I know the Electronics market. Chips which don't sell are no longer made and become obsolete - within months, unless there's a market for replacements. But who replaces a GPU by buying a chip?? It's cheaper to buy the card.

Who is buying S3? Or any of that old stuff with 20-25 years of age on them? I can understand (with great difficulty) X supporting old x86 32bit cards in case there's working models, and because disk space is cheap. The S3 went out for the ISA bus as well, you know. I was around when pci buses were a novelty, and IIRC the S3 was as good as it got for a year or two. But it, and all it's competitors are dead & buried now, or should be.

Understand totally. I get it - Sarpi64 is unofficial, yours is unofficial squared. Alpha, really.
That said, my Pi (RazPi 4 w/4G) is in use as a media box, and uses Raspbian on a 32G sdcard for the foreseeable. It's there because the TV web interface is so terrible. But I do have a 16G sdcard also, that's surplus to requirements. And I do have the 32bit SarPi installer.It looks that, with a few exceptions, it's a 64bit compile of the sarpi or X86(_64)stuff.

Sarpi works for me, but it doesn't have any sort of a 'lived in' look yet. I'm currently battling with wifi. I gather I can install it over sarpi with upgradepkg, with a few exceptions in the a/ directory, but I can use a PC for that. As I have the Sarpi64 kernel, I can simply unmount /boot to preserve that, and cast a cold eye over what turns up there. But I have questions:

1. Is this simply an isolated alpha set of packages, or a fork?
2. Do your libs go in /usr/lib, or /usr/lib64?
3. Will there be updates/fixes/ further releases?
4. I'm calling for a confession: Bare your soul. How have you contravened 'the slackware philosophy?' You've patched plenty, I gather, hacked a bit, maybe?
5. Would you value testers, or was this personal amusement?
6. The $64,000 question: The Arm64 distros out there are near zero. So anyone doing an arm port (e.g. Palemoon) is going to do a 32bit port. Therefore, it will be necessary to have a set of 32bit libs. Where's that coming from?

[*]Is this simply an isolated alpha set of packages, or a fork?
A. It's not a fork. It's a jiggery-pokery ARM64 kernel and modules.

[*]Do your libs go in /usr/lib, or /usr/lib64?
A. /usr/lib only.

[*]Will there be updates/fixes/ further releases?
A. Yes.

[*]I'm calling for a confession: Bare your soul. How have you contravened 'the slackware philosophy?' You've patched plenty, I gather, hacked a bit, maybe?
A. Plausible deniability is all I will admit to. It's difficult to read this page - The Slackware Way - and find a stipulation that I haven't contravened or offended at some point.

[*]Would you value testers, or was this personal amusement?
I've always viewed and valued testing and constructive ideas from other users as helpful and beneficial on any and every level, in general. If it wasn't for a great many individuals, directly and indirectly involved, then SARPi/SARPi64 would not be what it is as you see it today.

[*] The $64,000 question: The Arm64 distros out there are near zero. So anyone doing an arm port (e.g. Palemoon) is going to do a 32bit port. Therefore, it will be necessary to have a set of 32bit libs. Where's that coming from?
A. slarm64 - https://bitbucket.org/sndwvs/slackwarearm64-current/ - take a look at that. A Slackware community project maintained by other users.

---

The SARPi64 project was an attempt to encourage users into rolling their sleeves up and getting stuck in to some Slackware ARM 64-bit dynamics. If users find it helpful then that's what it's there for. This isn't an attempt to use MoZes' work and better, or butcher, it (NB: although I've done plenty of the latter by default) but it's more of a contrived stepping-stone in my scheme of all things unofficially Slackware ARM64 related.

In a nutshell, I don't have a clue how to build an OS like MoZes does. Nor do I have the motivation to do so alone. So I hope that by being creative on SlackDocs, and such like, with Slackware ARM64 shizzle, and guiding others into doing the same, it will further efforts on the whole towards a bona fide Slackware ARM64 OS eventually. That's my dream.

1 members found this post helpful.

You'll really have to fix that. You can't run any external arm package without multilib. The software out there for arm64 is zero.

On baring your soul: I looked at the link; I see some obvious offenses, but I don't think you can have offended them all. When things didn't compile, you bent them straight; that would need to be tested, sure. But it can't be that bad.

On the $64,000 question: The bitbucket link returns error 404. You can't do it anyway, over the fact that 64bit libs NEED to live beside 32bit ones. So, I gather I can install the OS, run my mail server, firewall or db, but not actually do anything. I can't install a codec or a browser plugin, for instance. So it might do for a special purpose little box, but I can't even install vnc, which is essential for such a thing. I don't have that kind of box - mail for a few accounts, or firewall. I'm a user, not a sysadmin.

I'm sorry, but I'm better off with SarPi. I even have doubts about SarPi64. If you had libs in /lib64 & /usr/lib64, it could be done this very awkward way

1. Install Sarpi, & Sarpi64 as they stand.
2. Present slarm64 on a usb stick
3. Manually edit the sarpi files in /var/lib/pkgtools/packages removing the lines with /lib & /usr/lib in them, and saving them to a files. That's scriptable.
4. Run an upgradepkg command from the appropriate directory to replace sarpi packages with slarm64 ones.
5. That leaves you with a whole lot of unlisted sarpi 32bit libs stored in files. Simply append those files cut from the 32bit packages you made earlier to the relevant slarm64 packages, so when you remove a 64 bit package, you remove the sarpi libs also.

Once you have a multilib setup, you make packages by installing to a $DESTDIR, but don't make the package. Make clean, & recompile 32bit, but only install the libs to the $DESTDIR. Then make the package.

You should also go after patches other distros use. Fedora32 have an arch64 release, Arch, & somebody else and they have their patches up for grabs. Look at LFS or CLFS to see how building an OS is done.

Then perhaps you can make it happen. When I started the SARPi project I was told by someone a lot wiser than me to get ready to roll my sleeves up and be prepared for some good old fashioned hard work. I would say the same to you in this instance. If you have something to contribute then I would be assertive in saying that there's no better way to manifest your skills and knowledge than by sharing your work. SARPi is an installer, not an operating system. What you've mentioned is part of an operating system for which MoZes is responsible in Slackware ARM. He's the master in that respect, not me. Anything that falls outside of installing Slackware ARM on a Raspberry Pi device is not within the remit of the SARPi installer.

No need to apologise. I completely understand. That's what I would advise (and believe I did advise) with regards to sticking with the SARPi installer - because it's a known quantity and enables users to install Slackware ARM pretty much perfectly on the Raspberry Pi devices. The SARPi64 shizzle is so far off the beaten track it's only available on the understanding that every thing involved is experimental and prototype. Some things just don't work. Ergo, in order for them to work the end-user has to make things work. Which is why I wrote that SARPi64 requires a little more effort and experience. Even I have prehistoric doubts about SARPi64 as a viable OS - because it's just an installer. That's all it will ever be. SARPi files and SARPi64 files should never be installed (or run) together on the same SD card. I've never attempted it because I'm not a masochist.

Incidentally, SARPi is an acronym of "Slackware ARM on a Raspberry Pi".

Sounds like you know what you're talking about. By all means, use SARPi to install Slackware ARM on your Raspberry Pi and knock yourself out! I would enjoy seeing the efficacy of your suggestions brought to life, so to speak.

Compiling 64bit is easy on most things --with-libdir=/usr/lib64. A libdir can be specified in cmake with, I think -Dlibdir=/usr/lib64. That leaves Mesa, which has some crazy setup, but Alien Bob has a script for that which refuses it permission to think and specifies everything.

AFAIK, there's some tweak in ldconfig to get /usr/lib64 searched instead/as well as /usr/lib. but if you can grab source, a recursive diff should get you the patch. Or you could simply hack /etc/ld.so.conf.

I've been around a while, I'm mainly a hardware guy, and not much use on patching software. I can do small amounts, but undertaking an OS is not something I'm prepared to do. From LFS, I can batter something into compiling, and my faultfinding experience with hardware comes in surprisingly useful. At one stage I was one of the best at Electronic Hardware in this country (Ireland), now I'm like a Cooper(wooden barrel maker) with an obsolete, unwanted skill. And I had a stroke, which is limiting. What I am definitely not prepared to undertake is software maintenance. I'm already married, and have no wish to marry an unpaid job.

SarPi64 is 4 files: An Armv8 kernel, but running that on an Armv7 OS probably means the extra potential is very lightly used. That's a kernel source, isn't it? The installer is the /boot drive because booting a Raspberry Pi is a very complicated business. What_I_Found_Out
But the only thing that will change there is the kernel, and maybe a firmware update. Then there's the /lib/firmware directory - 3rd party stuff and again 99.99% unchanging, and the hacks.

Judging by the rate this is done, Distro makers all script this. Look at Slackware-Current: there's a Slaxckware 32bit & 64bit Current compiled at the very least, once a month, often twice a month. Now, on Raspbian, it came with Chromium, and the considerable developmental clout of Debian behind it. Money probably quietly changes hands there. I could add Palemoon, and Firefox to it - on 32 bit. I put a fair bit of time in reverse engineering Fedora32_aarch64, because they have some developmental clout also. But everything is in /usr/lib. IMHO, everything had to be split, /usr/lib, & /usr/lib64. Everything 64bit needs a /lib/ld-linux.so being 64bit. Everything 32bit needs a /lib/ld-linux.so being 32bit. That's why you need /lib64.

But SarPi64 will not be needed until 64bit 3rd party software becomes more mainstream.

Once you get one 63/32 bit system, you can compile stuff, but you'll have to cut the crud to save space. Who in their right mind would kde on a speed embarrassed, memory embarrassed RazPi? etc.

I said to myself: "This slarm64 thing is no use - I'll delete it." But it had been a pain to d/l, so I exploded a few packages on the PC to be sure. The libs are installed in /usr/lib64. Any thoughts?

So, it is compatible with sarpi. A slight variation in version numbers is of no consequence - they're both not used together - to my knowledge. It's 32 bit OR 64 bit. Have you ever met a 32/64 bit program?

Now we need a little script to surgically remove the /lib & /usr/lib lines from the sarpi install into files, and then a clever little command to tack them on the end of the slarm64 packages. Any thoughts there, or should I float that as a separate thread on slackware-arm? I can stick them on the end with 'cat[list] >> $FILENAME'

Then I've got a Multilib Arm OS. From something like that, you can compile & run 32bit or 64bit software. It would be a good engine for making an approvable 64bit system, which will have to be multilib for now.

It will be significantly overpopulated with 32bit libs. I've 3.1G in SarPi's /usr/lib, but only 2.0G on my multilib pc. A guy called Eric Hamleers did the grunt work on this, and forked Slackware-12.2 as Slamd64-12.2. It was 64bit with 32bit libs. The fork only had the one version, as Eric became very ill but he helped Alien Bob sort the compat32 stuff. If you just do in Arm32 what is up as as Compat32, all should be well. It's about 300Megs of archives, and gcc & glibc are complete reinstalls.

There is the issue of storage, as my sdcard is only 16G, my spare usb key is only 8G and SarPi /usr is currently 9.9G. So I'll invest a few €, and have /usr as a mountable partition, and maybe /home as well. Then it will be like the 1970s, with thyese 2 foot platter disks holding something like 64K on each 'lp' (there were usually 4 or 5) And /usr HAD to be on another platter, because there wasn't room.

You'd have to contact the maintainer of slarm64 for any answer(s). slarm64 is an entirely different project to SARPi, of which I am not involved on any level. Both are Slackware Linux community efforts that are not officially endorsed by Patrick and the Slackware devs. That's as much as I know about any common factor between them.

I've never installed or used slarm64. So, I really don't know what might be compatible or not. If slarm64 features a package tree [as much as possible] identical to Slackware ARM I don't see why SARPi couldn't be further mangled and cajoled into installing it. The SARPi project follows the work of Stuart Winter [a.k.a. MoZes] the Slackware ARM developer, as closely as is technically possible, and always has/will.

Thanks for making that clear. I did say this earlier:
So the BDFL doesn't approve - yet. Frankly, I don't see that happening any time soon. Maybe Pat will appoint a deputy. But I fancy nothing much will happen before 15.0 comes out.

I'm convinced that long term, Slackware will have to go with different software choices if the x86 version is to stay relevant. No VNC - surely basic for a RazPi. The lack of 'official' versions of many things. I frankly don't see the relevance of x86 stuff on space limited Arm distros (32 or 64 bit), all the extinct video drivers and bitmap fonts in X on the Arm versions, or kde which even my pc is too slow for.

But I'm doing this for my amusement,and I'll feed back anything of interest, won't make a fuss, and take our feedback off to PM if you prefer. This is really impolite - discussing a 64bit OS on the ML of a 32bit port. My only defense is that I couldn't think where else, as it appeared here.