All installation guides have been migrated to use the AiO installer.
It looks good to me but as usual if anybody finds any issues with the install guides, let me know.

The AiO installers are identical to the previous ones (in fact the AiO images simply extend the 'bare' images), except that they have an additional ext4 partition containing the Slackware tree. There won't be anything else not included within Slackware on there.
The idea is simply to make it easier to install Slackware: all of the faffing around with network installation, copying the repo to a USB stick was too much for me.


I'm going to work on the x86/64 tool to build AiO images for USB booting. I've already got it working on 32bit x86 but it's all hacked together by hand at the moment.

For a first install, and occasionally throughout, an AIO install is the only way to go, imho. That has to be put on by another box somehow. You've gone the standard slackware route. But I believe the Slackware BDFL is a far seeing and practical man, and if he had designed a system for multivarious Arm SBCs, it would have been different. I normally boot such an image, install everything, and then delete the obsolete and x86-specific crud. Then I make it mine, installing things like vlc, Palemoon, Chromium-ungoogled. That's why I asked about a repo.

I've been chasing into playing videos. I use this one stretch of 1080p video as a test for comparison. Slarm64 plays it @350%-OTT (cpu overload). VLC won't render for 1 hdmi monitor, & mpv drops frames so the sound goes out of synch. Manjaro is worse. Ubuntu trips over it'd dependencies and won't play at all.. It's getting inconvenient for me to distro hop, because I haven't updated to later eeproms with UEFI & GPU throttling. Debian's 2022-09 64bit image plays it at ~60% on top, which is a vast difference in performance. LibreElec just use a cut-down Debian, and kodi only has installation instructions with apt. I'm convinced there's a proprietary driver that Broadcom wrote for that GPU. They even left some libs & includes in /opt/vcThe new kernel work is making a modest improvement, about 50%(out of 400%) but it still tops out on some cores, and videos drag. I'm annoyed,but there won't be this issue with the RazPi 5. Raspberrypi have postponed development of that at an early stage, which is fatal in hardware. Because whatever concept they settle on will be out of date by the time they produce it. You have to think years ahead in hardware. The 8 core orange Pi 5 is out. Solid run has a 16 core Arm mini-server for under $1000, etc. Next the frequency & quality of cores will increase. Look at Apple. It's a crowded market, especially when you're late in.

I didn't think building images was any big deal. There's zerofree, and some tune2fs option to compact the files (-M?). dd works, so why fix it?

Perhaps you mean something else, but anything downloaded needs a computer to copy it to the storage.
I did think about making instructions for MacOS and Windows, actually.

The design for Slackware AArch64 diverges from x86 at various points to tailor it to the platform, and I'm curious as to what you mean about what Patrick might have done differently? can you elaborate?

Also what x86 crud do you delete? All of the x86-only packages should not exist in the distribution, but there are probably some config files and stuff lying around that could be candidates for removal.

I'm uncertain who you're addressing, but I certainly didn't find building images a big deal - the Slackware AArch64 installer is a disc image; but
Slackware is installed using the installer as that's the only way to fully customise the layout of the file systems, and other stuff which you cannot do with pre-built images.
I don't think many people are aware of this, but the reasons most of the other distributions distribute an image was because it was easier than to port and maintain the text-based version of their installer, when most of the x86 installers moved to graphical.
I never had such a challenge with Slackware (apart from the initial reverse engineering efforts, since Pat did it all by hand back then), thankfully! :-)

Really, booting an x86 is controlled by the BIOS. Arm SBCs don't have a BIOS as such but each developed their own half-assed boot system and then tried to make it UEFI compatible. The RPi is very odd indeed. I imagine Pat V. would have reacted to the Landscape he surveyed. Arm is different from X86, and the OS would have reflected that. Debian's RPi OS adds a raspberrypi/ directory to /lib/firmware/ which stores the old eeprom revisions and gives a changelog.

As for "deleting crud:" On a RazPi, lilo, & elilo are unnecessary, and grub probably so. Ditto vi, elvis, joe, emacs, and all the other editor clones. You need the one you use, which for me is nano. Likewise I only need fonts for languages I speak. I don't need video drivers for gutless 1990s pci video cards, 100dpi & 75dpi fonts. I usually junk the bloat from the mozilla stable (thunderbird & seamonkey), floppy disk utilities. I refrain from installing emacs, Howtos, kde. I would clean out more except for the odd utility packaged with them. I'm not bothered pruning each tree, those are just the main offenders. OTOH, on X86_64 I install stuff from Alien Bob's repo, and on Aarch64 I use sndwvs's repo at https://dl.slarm64.org/slackware/packages/aarch64/ although that link is down atm. It comes & goes a bit.

On the images, I just wondered why you were writing software to do what's easily done, except to facilitate windoze users. Of course, there's probably all sorts of knee-jerk reactions to writing on anything from track 0, sector 0 onwards for a few gigs.The news for M$ is that they are very late to the party there. I had a near miss with the CIH boot virus back in the 1990s. I found 175 copies between 2 computers on April 23rd; CIH was going to overwrite the BIOS on April 26th!

What I have now is an SSD in the lowest priority USB-3.0 socket. A usb thumb drive in the other will assert boot priority, and an sdcard can trump even that. So I can painlessly try things, and rsync them accross if desired. I'm currently miffed that the OSS community hasn't got even a closed source version of the Broadcom video driver, which I'm sure rpi os has. I want to avoid that sort of messing next time I buy Arm.

Not really, the community settled on U-Boot in the main.

Lilo and elilo don't exist in Slackware on ARM.
Grub is required (or will be) by the Honeycombe XL.

I don't understand what you're referring to. What software?
I do the official port of Slackware to ARM, and I ported the installer and that's what's used. The improvements I made for ARM I have upstreamed to improve the installation process on x86/64.
Can you be more specific? Is the documentation confusing?

I'm not sure of the link here.

Anyway, enjoy!

Sorry, my bad - I'm very unclear, being the nutty professor type. In post #1 you said
Yes, the community has settled on u-boot. Unfortunately u-boot spreads my screen rather too much, so I can't use it. I need the config.txt approach. That's also controlled by some kernel option, but I haven't a clue which one.

The Linux Kernel config has no connection to the configuration of the boot loader, after all the Kernel isn't loaded when the boot loader is running, and you could boot something other than Linux from there. On Slackware we use the RPi native boot loader initially so you can see if you can make it do what you want. See the section about Device Tree Overlays in the install guide for the location of the RPi boot loader config.

I already tested all the AiO changes for ARM on x86 and upstreamed them. The remaining AiO installer work for the x86 is further understanding syslinux (as I want to display the Slackware logo and some other stuff) and packaging it for both 32 and 64bit x86 platforms.

Again I'm being unclear. Sorry.

Screen spreading is controlled by some kernel option. The option "disable_overscan=1" in /boot/config.txt allows the screen to go as large as it's set by video. But "disable_overscan=0" reduces the screen size on all 4 edges. With "disable_overscan=0" set, the first page of output during a boot is big type as firmware is loaded from /boot. The next page is the kernel asking "What planet is this?" and retains the reduced size. The third page has the small size or reverts to full size dependent on some kernel option. I've fixed that issue just by swapping kernels.

I'm pretty sure the next sbc I'm going to buy will have a decent gpu driver available to the community.

I have searched high and low for the script/source/bits to create one of these AIO installer images and I'm coming up empty handed. Being able to create one of these myself would greatly help me and booting an installer of Slackware aarch64 on Apple Silicon machines. Since kernel support is not upstreamed completely, it can't be officially be added as a hardware model just yet, but being able to create installers would greatly help my testing (and improve my current installation method drastically). Is it online somewhere and I'm just not finding it?

The AiO builder isn't available yet but all you need is sdcards.build.
The AiO images are created from the images generated by that script.

Want to report my first time using AiO images to install to rpi4, it all went well, thank you Stuart.

1 members found this post helpful.

The main blocker here is that the Installer build system for ARM isn't publicly available because it's about 16 years in the making and 4 layers of hackery, and even I don't know how some of it works anymore. The official build_installer.sh was written for ARM, adopted by x86_64; and as we all maintain the upstream version, I had to re-adopt it for ARM as a downstream consumer. I need to re-design and re-write the ARM integration for it. I plan on upstreaming most of the Installer improvements this year, which enables me to strip the build system back and make it something I'd put my name on ;-)

I need to have a long hard think about it. Perhaps I'll make a 3 hour podcast as I toss the ideas around, and put you all to sleep ;-)

You've no doubt concluded already that your best bet would be to put your own set of Kernel modules into the installer image to get it working.
If you create the Kernel module loader script for it, send it to mozes@slackware.com and I can begin baking it in, and likewise if there are any Kernel modules/features that it requires which are in the stable Kernel.org Kernel, I can add those in: it's easier to merge in small changes over time.

For testing the Installer, perhaps you can network boot it - this will save you loads of time. Check out the 'installer/README.txt' in the root of the slackwareaarch64-current tree.

2 members found this post helpful.

Glad it works! I hope 6.1.12 works next week.

1 members found this post helpful.

Currently the Asahi [project porting the kernel to Apple Silicon] people have their own branch of the 6.0 kernel as most changes have yet to be upstreamed. As of now I'm not sure what could be pre-added, I'll have to take a look and do some comparisons. I've basically just re-packaged their built kernels, as my attempts months ago to get my own builds to boot failed (which turned out to be some missing kernel configs). I haven't started trying to make my own again yet. It just seemed easier to approach it like re-packing any other bin-only program until the work is upstreamed completely and actually buildable. My device also has no functioning usb until later in the boot process (easy to fix buying an adapter) so I can't really fix boot issues easily currently. My current methods require "nbd", MacOS, and a Slackware box and I just chroot and installpkg.

It works, it's convoluted and sloppy but it works. I'm currently setting up the machine again, I'll try and set aside some time to look into the installer. Though TBH much of the boot process still mystifies me, it boots and runs well so I can't be that far off with it.