[SOLVED] Slackware A-i-O (All in One) Installer images available for testing

drmozes · 01-10-2023, 08:31 AM

Hello

The new A-i-O (All in One Offline) Installer images for Slackware AArch64 are available for testing.

Essentially it's the existing Installer image with an extra partition containing all of the Slackware packages, and it'll automatically detect and recommend using it as the source media.
It makes it easier to install because there's simply less to do, and it means you can install it offline as well.

The quick HOWTO is here.

This will be the new installation method going forwards, and the documentation will be adjusted soon.

The AiO support will be pushed upstream soon for x86/64 for A-i-O USB images, so if you guys fancy a reinstall and helping out with the testing, I appreciate that.

pan64 · 01-10-2023, 12:01 PM

Quote:

The connection has timed out

An error occurred during a connection to slackware.uk

I guess it is a temporary issue

colinh2 · 01-18-2023, 09:00 AM

Hi Stuart,

the AIO installer is really nice, clear and simple! Congrats!

Unfortunately, I'm having problems:

I'm using a 4GB RPi4b. I've tried two SD cards (with identical results):

SanDisk Ultra 64GB XC I (C-10 rating)
Transcend High Endurance 32GB HC I (C-10 U-1 ratings)

[I installed Raspbian on a SanDisk Extreme 32 GB HC I (V-30 U-3 A1 ratings). This installs/boots ok.]

When the Slackware installer boots it displays (near the beginning):

"Card did not respond to voltage select! : (-110)"

At 31.7 secs "vcc-sd: disabling" is displayed, but then it continues with "Please wait, initialising network..."

So, the installation works fine.

However, booting the installed system hangs at 31 secs

"vcc-sd: disabling".

I tried going in to uboot and "mmc rescan 0" (rescanning using the "MMC legacy" speed mode) but that still gives the "Card did not
respond to voltage select!" error.

I tried uncommenting the "#device_tree=bcm2711-rpi-4-b.dtb" line. This made no difference.

I tried adding "device_tree=" (to both [pi4] and [all] sections). Then it hangs at the multicolour square.

Unfortunately, I don't know anything about uboot, dtbs or overlays. It's odd that the Slackware installer has no problems reading the SD cards, but that the installed system then fails to do so.

colinh2 · 01-18-2023, 05:12 PM

By sheer coincidence, I watched S02E20 as my very first youtube slackware arm podcast -- which seems to deal with this issue.

I have an SD card with slackware installed, and with the installer retained. So I was able to append "slkpbs" to the command line (in extlinux.conf). Unfortunately, this causes booting slackware to hang right at the beginning! (at "starting kernel...").

I looked in load_kernel_modules.scr/platform/aarch64/bcm2711 and "sdhci-iproc" is indeed commented out with the reason: "causes crash in 5.19"

drmozes · 01-19-2023, 02:53 AM

Quote:

Originally Posted by colinh2

By sheer coincidence, I watched S02E20 as my very first youtube slackware arm podcast -- which seems to deal with this issue.
I have an SD card with slackware installed, and with the installer retained. So I was able to append "slkpbs" to the command line (in extlinux.conf). Unfortunately, this causes booting slackware to hang right at the beginning! (at "starting kernel...").

This is what we made these videos for so I'm glad it's been useful!

You need a serial console to use slkpbs because the video drivers are loaded as modules, and the pre-boot shell halts the boot to enable manipulation of that stuff.

Quote:

I looked in load_kernel_modules.scr/platform/aarch64/bcm2711 and "sdhci-iproc" is indeed commented out with the reason: "causes crash in 5.19"

Thanks, it no longer crashes on my Rpi4 - probably because of the 'irqpoll' Kernel cmdline.

The Installer and the OS InitRD share the module loader code (so the module is commented in the installer too), but they diverge on the set of Kernel modules included, so this is likely why it differs in behaviour. I have a TODO to align them, but it means refactoring a load of old code from ARM32 that I hacked up for AArch64. I'm gradually merging the ARM fixes upstream so I'll get there at some point.

Thanks for digging into this and for the report.
Mientras, I've uncommented the module in the loader and I'll be pushing out the next batch in the next few days.

colinh2 · 01-19-2023, 06:42 AM

Quote:

Originally Posted by drmozes

You need a serial console to use slkpbs because the video drivers are loaded as modules, and the pre-boot shell halts the boot to enable manipulation of that stuff.

Could you explain how to get a serial console? (Sorry, I've done a few all-nighters, and my brain is running on fumes. Actually, it's stopped running, and I'm gliding. Also known as crashing.

Quote:

Mientras, I've uncommented the module in the loader and I'll be pushing out the next batch in the next few days.

Or I could just wait... :-)

drmozes · 01-19-2023, 07:56 AM

Quote:

Originally Posted by colinh2

Could you explain how to get a serial console?

It's in the RPi install doc at the bottom.

I'd say that they're essential on ARM, otherwise your nights will be longer ;-)

colinh2 · 01-19-2023, 09:21 AM

Astonishingly, I've had partial success with this.

I installed the latest ARM Gnu toolchain (for Intel Macos).
Compiled u-boot for 'qemu_arm64_defconfig'.

slkaio-qemu.img is the rpi4 arm-slackware-aio image.

Started qemu (I have version 7.0.50, but accidentally used version 6.1)

Code:

~/qemu/build/qemu-img create -f qcow2 slk.qcow2 32G
~/qemu/build/qemu-img resize slkaio-qemu.img 16G

colin@mac:~/qlinux/slackware$ qemu-system-aarch64 -machine virt -m 4G -nographic -cpu cortex-a57 -bios ../u-boot/u-boot.bin -drive if=virtio,format=raw,file=slkaio-qemu.img -drive if=virtio,file=slk.qcow2

During setup I created ONE ext4 partition for '/'. I only installed a few series (a,d,f,k,n,...) I opted to keep the Installer.
Installation took hours with the Macbook Pro fan spinning the whole time :-/

If I then reboot, it doesn't give me the option of booting the new Slackware or the old Installer -- it just reboots the installer.

Code:

root@slackware:/# reboot
Sending all processes the SIGTERM signal.
Sending all processes the SIGKILL signal.
Syncing filesystems.
Unmounting filesystems:
/mnt/sys                 : successfully unmounted
/mnt/proc                : successfully unmounted
/mnt/dev                 : successfully unmounted
/slack-all-in-one        : successfully unmounted
/mnt                     : successfully unmounted
/dev/shm                 : ignored
/sys                     : ignored
/proc                    : ignored
/                        : ignored
Rebooting.
[ 2843.712972] reboot: Restarting system


U-Boot 2023.01-00621-g5b958dea5c-dirty (Jan 19 2023 - 04:04:32 +0100)

DRAM:  4 GiB
Core:  47 devices, 13 uclasses, devicetree: board
Flash: 64 MiB
Loading Environment from Flash... *** Warning - bad CRC, using default environment

In:    pl011@9000000
Out:   pl011@9000000
Err:   pl011@9000000
Net:   eth0: virtio-net#32
Hit any key to stop autoboot:  0 
fatal: no kernel available
Command 'load' failed: Error 1
starting USB...
No working controllers found
USB is stopped. Please issue 'usb start' first.
scanning bus for devices...

Device 0: unknown device

Device 0: 1af4 VirtIO Block Device
            Type: Hard Disk
            Capacity: 16384.0 MB = 16.0 GB (33554432 x 512)
... is now current device
Scanning virtio 0:2...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
1:	Boot Installer: Slackware Linux
Retrieving file: /Image-armv8
Retrieving file: /initrd-armv8.img
append: earlyprintk root=/dev/ram rw kbd=us nic=auto:eth0:dhcp irqpoll
## Flattened Device Tree blob at 40000000
   Booting using the fdt blob at 0x40000000
Working FDT set to 40000000
   Loading Ramdisk to eb0c4000, end fffffb68 ... OK
   Loading Device Tree to 00000000eafc1000, end 00000000eb0c3fff ... OK
Working FDT set to eafc1000

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x411fd070]
[    0.000000] Linux version 6.1.4-armv8 (root@bladswede.arm.slackware.com) (aarch64-slackware-linux-gnu-gcc (GCC) 12.2.0, GNU ld version 2.39-slack151) #1 SMP PREEMPT Mon Jan  9 23:17:52 UTC 2023

I tried rebooting with the slkaio.img removed -- but, of course (?), that "SD card" image contains the boot partition (and Installer, since I opted to keep it).

Code:

=> poweroff
poweroff ...
colin@mac:~/qlinux/slackware$ qemu-system-aarch64 -machine virt -m 4G -nographic -cpu cortex-a57 -bios ../u-boot/u-boot.bin -drive if=virtio,file=slk.qcow2 


U-Boot 2023.01-00621-g5b958dea5c-dirty (Jan 19 2023 - 04:04:32 +0100)

DRAM:  4 GiB
Core:  47 devices, 13 uclasses, devicetree: board
Flash: 64 MiB
Loading Environment from Flash... *** Warning - bad CRC, using default environment

In:    pl011@9000000
Out:   pl011@9000000
Err:   pl011@9000000
Net:   eth0: virtio-net#32
Hit any key to stop autoboot:  0 
fatal: no kernel available
Command 'load' failed: Error 1
starting USB...
No working controllers found
USB is stopped. Please issue 'usb start' first.
scanning bus for devices...

Device 0: unknown device

Device 0: 1af4 VirtIO Block Device
            Type: Hard Disk
            Capacity: 32768.0 MB = 32.0 GB (67108864 x 512)
... is now current device
Scanning virtio 0:1...
No EFI system partition
Unable to find TPMv2 device
Missing RNG device for EFI_RNG_PROTOCOL
BootOrder not defined
EFI boot manager: Cannot load any image

Device 0: unknown device
starting USB...
No working controllers found
BOOTP broadcast 1
DHCP client bound to address 10.0.2.15 (1 ms)
Using virtio-net#32 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15
Filename 'boot.scr.uimg'.
Load address: 0x40200000
Loading: *
TFTP error: 'Access violation' (2)
Not retrying...
BOOTP broadcast 1
DHCP client bound to address 10.0.2.15 (1 ms)
Using virtio-net#32 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15
Filename 'boot.scr.uimg'.
Load address: 0x40400000
Loading: *
TFTP error: 'Access violation' (2)
Not retrying...
=> ?

After rebooting it seems I don't have an /extlinux/extlinux.conf

Code:

=> ext4ls virtio 0:1 /    
<DIR>       4096 .
<DIR>       4096 ..
<DIR>      16384 lost+found
<DIR>      12288 etc
<DIR>       4096 tmp
<DIR>       4096 var
<DIR>       4096 bin
<DIR>       4096 boot
<DIR>      69632 dev
<DIR>       4096 home
<DIR>       4096 lib
<DIR>      12288 lib64
<DIR>       4096 media
<DIR>       4096 mnt
<DIR>       4096 opt
<DIR>       4096 proc
<DIR>       4096 root
<DIR>       4096 run
<DIR>      12288 sbin
<DIR>       4096 srv
<DIR>       4096 sys
<DIR>       4096 usr
=> ext4ls virtio 0:1 /boot
<DIR>       4096 .
<DIR>       4096 ..
            1747 README-kernels.txt
<DIR>       4096 grub
             704 .boot_details
        28230144 Image-armv8-6.1.4
         4912739 System.map-armv8-6.1.4
          272210 config-armv8-6.1.4
<DIR>       4096 dtb-6.1.4
       265428059 initrd-armv8-6.1.4
<DIR>       4096 local
<DIR>       4096 platform
<SYM>         17 Image-armv8
<SYM>         22 System.map-armv8
<SYM>          9 dtb
<SYM>         18 initrd-armv8
<SYM>         40 README.initrd
=>

It really looks like this should be doable :-/

There's more qemu stuff

Quote:

Running U-Boot¶

The minimal QEMU command line to get U-Boot up and running is:

For ARM:

qemu-system-arm -machine virt -nographic -bios u-boot.bin
For AArch64:

qemu-system-aarch64 -machine virt -nographic -cpu cortex-a57 -bios u-boot.bin
Note that for some odd reason qemu-system-aarch64 needs to be explicitly told to use a 64-bit CPU or it will boot in 32-bit mode. The -nographic argument ensures that output appears on the terminal. Use Ctrl-A X to quit.

Additional persistent U-boot environment support can be added as follows:

Create envstore.img using qemu-img:

qemu-img create -f raw envstore.img 64M
Add a pflash drive parameter to the command line:

-drive if=pflash,format=raw,index=1,file=envstore.img
Additional peripherals that have been tested to work in both U-Boot and Linux can be enabled with the following command line parameters:

To add a Serial ATA disk via an Intel ICH9 AHCI controller, pass e.g.:

-drive if=none,file=disk.img,format=raw,id=mydisk \
-device ich9-ahci,id=ahci -device ide-drive,drive=mydisk,bus=ahci.0
To add an Intel E1000 network adapter, pass e.g.:

-netdev user,id=net0 -device e1000,netdev=net0
To add an EHCI-compliant USB host controller, pass e.g.:

-device usb-ehci,id=ehci
To add an NVMe disk, pass e.g.:

-drive if=none,file=disk.img,id=mydisk -device nvme,drive=mydisk,serial=foo
To add a random number generator, pass e.g.:

-device virtio-rng-pci
These have been tested in QEMU 2.9.0 but should work in at least 2.5.0 as well.

...which I haven't looked at, but probably should have. If I've made a silly mistake, I'd really like to avoid reinstalling the packages again...

PS. I've been developing my own OS (on the RPi 3b, under qemu) -- it has pre-emptive multitasking, a filesystem, shell (which is just my own Lisp interpreter), editor, debugger, graphics and maths libs, window manager, memory management, allocation and automatic garbage collection, regex, mphf etc. -- The unusual thing about it is that it's coded completely in lovingly crafted ARM64 assembly code (like the original RISC-OS). So, the entire operating system fits in the instruction cache :-) -- It's also unusual in that there's absolutely no security or separation between the OS and "user" code -- I can call any core routine from Lisp. Once I've done an assembler (and Lisp compiler) I'll be able to change core OS routines on the fly. It's vaguely inspired by Unix v.6, RISC-OS (which I had) and Lisp Machine (which I've never seen, but hear was nice).

I'd like to compare its performance (very roughly) regarding cache coherency, filesystem, malloc/free etc. with Linux's. So I just need to be able to run both OSs on the same hardware. Or the same emulator.

drmozes · 01-19-2023, 09:41 AM

QEMU used to be supported and we booted the Kernel directly.
It was just too slow to be useful, but maybe it's better now - particularly on faster hardware.

You're welcome to make it work and add in support properly as for any other Hardware Model.

Interesting to read about your OS - it does sound like RISC OS (or really any OS of that era).
I have been tempted to run RISC OS on the RPi just for kicks, but I still have my Iyonix working so it's easier to use that to satisfy any nostalgic urges ;-)

drmozes · 01-20-2023, 03:50 AM

The latest updates are out, including new A-i-O Installer images.

I've also made available the script I use on my development machines to dump the image to the MMC and reboot. If you're already in the OS and want to blast it away and reinstall, it'll be useful.

KDE under X still crashes on the RPi4 but works on the other machines, so use XFCE instead until it works ;-)

The installation guides will be updated next to use the A-i-O method, then work begins to migrate the USB Installer boot image for X86 to A-i-O.

Enjoy !

drmozes · 01-20-2023, 10:27 AM

Quote:

Originally Posted by drmozes

The latest updates are out, including new A-i-O Installer images.

I've also made available the script I use on my development machines to dump the image to the MMC and reboot. If you're already in the OS and want to blast it away and reinstall, it'll be useful.

KDE under X still crashes on the RPi4 but works on the other machines, so use XFCE instead until it works ;-)

The installation guides will be updated next to use the A-i-O method, then work begins to migrate the USB Installer boot image for X86 to A-i-O.

Enjoy !

I couldn't stop, I've already PoC'd it on 32bit x86.

colinh2 · 01-22-2023, 01:25 PM

Quote:

Originally Posted by drmozes

QEMU used to be supported and we booted the Kernel directly.
It was just too slow to be useful, but maybe it's better now - particularly on faster hardware.

Actually, for performance comparisons, cache behaviour etc. It doesn’t really make sense for me to be trying this under Qemu anyway…

Also, while the AIO installed perfectly on the RPi4 it hangs on my RPi3 at “booting the kernel…”

[as an aside, do you prefer developing for the pinebook pro over the RPis? I’m considering getting one (a PBP)…]

drmozes · 01-23-2023, 03:20 AM

Quote:

Originally Posted by colinh2

Also, while the AIO installed perfectly on the RPi4 it hangs on my RPi3 at “booting the kernel…”

Can you try removing irqpoll from the extlinux.conf? As the Rpi3 and 4 use the same image they both get that.
I don't have an RPi3 so it only gets tested from time to time when Brent fires it up.
I've updated the installation guides to reflect that.

Quote:

[as an aside, do you prefer developing for the pinebook pro over the RPis? I’m considering getting one (a PBP)…]

The note at the head of the RPi installation guide explains the situation.
The RPi foundation or whatever it's called that develops the RPi focus first and foremost on making their hardware work with their own distribution, at the expense of upstream, so the upstream support is fragile and can break at any point when you upgrade the Kernel.

It's like a storage vendor saying: Oh we developed our SATA driver for our cheap SATA board, but we don't care about upstreaming our development, so if you want to use our SATA card you need to use our Kernel fork.
Ordinarily you'd laugh and move on and use a different SATA card that is supported upstream. Unfortunately when it's the computer *itself* that the vendor does this for, means you either need to use a different one (which is what I *strongly* recommend), or use whatever happens to work in the upstream Kernel - which is what we and all the other distros do, and users put up with the fragility. At one point I thought I'd use an RPi for my gateway because I like that it has no power button, so I can rest assured that if the power is ever dropped it'll power up again. However, with the instability of the Kernel support, I will never again purchase anything RPi.

So in summary, I dislike the RPi: the hardware's nothing special in comparison to other vendors, the upstream support is fragile and lacking. It does have lots of great documentation and 'fun' projects around it though, but nothing can compensate for the fragile upstream support.

colinh2 · 01-23-2023, 09:08 AM

Quote:

Originally Posted by drmozes

Can you try removing irqpoll from the extlinux.conf? As the Rpi3 and 4 use the same image they both get that.
I don't have an RPi3 so it only gets tested from time to time when Brent fires it up.
I've updated the installation guides to reflect that.

Will do -- later. I'm using the RPi4 at the moment...

Quote:

The note at the head of the RPi installation guide explains the situation.

Absolutely no criticism (of you) was implied! :-)

Quote:

So in summary, I dislike the RPi: the hardware's nothing special in comparison to other vendors, the upstream support is fragile and lacking. It does have lots of great documentation and 'fun' projects around it though, but nothing can compensate for the fragile upstream support.

I've been getting increasingly frustrated with the RPi from a documentation and "openness" point of view. The very first youtube video I saw had Ebon Upton complaining that kids these days (even those going to study CompSci at Cambridge, I believe) had no idea anymore about how computers *really* work: they were good at games and web browsing, maybe knew a bit of PHP or whatever, but other than that...

He wanted to encourage people to try hacking their computers like in the good old BBC Model B days.

But now it seems that the RPi is "just" a cheap Linux machine (configured to look and feel as much like a Windows machine as possible?). Admittedly, it makes lots of projects using cameras, GPS, GPIO etc. relatively easy -- but hacking the hardware itself can be annoying :-/

In the first "peripherals" doc they accidentally gave a link to the Arasan SD/MMC docs. This they later removed, but left the register descriptions. The latest doc for the RPi4 has completely removed any mention of SD/MMC or USB...

Hmmm. Actually, maybe it's good to get experience with NDAs, bad/missing documentation, insane "standards" (USB) and so on -- before you decide whether to study electronic engineering or what have you... :-)

Anyway. Sorry for the OT rant. Looks like I'll be getting a PinePook Pro and/or Rock64 thingy :-)

business_kid · 01-23-2023, 11:52 AM

I tried this AIO image on my RazPi 4 - I'm impressed! It comes up just like the x86_64 version with the same install script tucked into the ramdisk. Is there just the install dvd or is there any repository of compiled programs?

I thought I'd comment on this

Quote:

Originally Posted by drmozes

The note at the head of the RPi installation guide explains the situation.
The RPi foundation or whatever it's called that develops the RPi focus first and foremost on making their hardware work with their own distribution, at the expense of upstream, so the upstream support is fragile and can break at any point when you upgrade the Kernel.

I've been doing a bit of reverse engineering (an essential skill in Electronics Hardware) on rpi OS. I haven't found the kernel troublesome, but video. On a nasty video, software rendering cooks the cpu @400% in top or more. That's true for nearly all distributions. Vlc won't render, or mpv drops frames and the sound goes out of synch. Debian/rpi os 64 bit played the same video at 60-70% (out of 400%) cpu, and the latest image, 2022-09, plays it at 50-60%. That's a humungous difference. Browsing this search

Code:

HEVC pi 4 site:raspberrypi.com

makes clear there is a High Efficiency Video Codec (HEVC) in the pi 4, but the community is stuck on software rendering. I believe

Broadcom who were never any friend of Open Source may well want to keep that HEVC a closely guarded secret.
Raspberrypi just use linux because it's cheaper than windows.
Debian were surely paid to develop rpi os, but have technical information under a Non Disclosure Agreement. So they are gagged.

There is some efforts out there, or was at least. There is a patched kernel http://github.com/raspberrypi/linux which has a 'make bcm2711_defconfig' target. I built it. It builds 5.15.84-v8+ and provides a modest reduction in cpu load while software rendering, about 50% (out of 400%)on top.
A patched version of ffmpeg-4.3.1 is available herehttp://github.com/jc-kynesim/rpi-ffmpeg Somebody recommends it in one of those threads above. It's really something you want to extract the patches (commits?) from and apply to a newer source.

The same guy has some work done on vlc http://github.com/jc-kynesim/vlc but again, it's the patches you want. Interestingly, the 'configure --help' lists two rpi options which don't appear in the unpatched version. But extract the patches again.

Lastly, guys sing the praises of LibreElec's Kodi and their patches. It's probable that someone in Debian took the good ideas from these and any other sources and banged out his own patches which are now part of the Debian/rpi os version, in addition to whatever codec is used. Those githubs are pretty dead now.

As for not buying from raspberrypi again - you won't have to. Raspberry pi have comitted the fatal mistake of postponing development of the rpi 5. So imho they are dead in the water. Whatever hardware design they select to build will be out of date by the time they have built it and got software going. So they won't be a player. The Orange Pi 5 is out, and is exactly what raspberry should be selling. Your time to market is everything in hardware.

Quote:

Originally Posted by colinh2

He wanted to encourage people to try hacking their computers like in the good old BBC Model B days

That will never happen again. The BBC micro had discrete components which could be desoldered & replaced. Your cpu or wifi is now a chunk of programmed code or a precompiled closed-source core in some corner of a massive chip. The board is the replaceable component.