I'm having a go at installing Slackware ARM on my Raspberry Pi 4 using the latest sarpi4 installer (sarpi4-installer_slackcurrent_30Jan22_sp1.img.xz). This is my first attempt with an RPi4, I did fresh installs on my RPi3s last week using the sarpi3 installer (26Jan22 edition) with no problems.

What I find is when the installer finishes loading:

1. I get the "Choose keyboard map" (press Enter for default)
2. Bash prompt appears followed by the...
3. "Please press Enter to activate this console" message (press Enter)
4. Screen clears and shows "Choose keyboard map" again (press Enter)
5. Bash prompt appears again

Now anything I type is either only partially received (eg., I type 'lsblk<Enter>' and it only receives say 'sb' so I get 'bash: sb: command not found') or keys aren't received at all (except Ctrl-C always seems to work).

I can do Alt-F2 to open tty2, activate the console (shows bash prompt) and everything works fine.

If I look at /etc/inittab, it has:

From my tty2 shell, if I edit /etc/inittab and comment out the last 'tty1' line, do a 'killall -HUP init', and a 'kill -9' on the bash process on tty1 then when I go back to tty1 I've got a working bash shell. If I comment out the '::respawn:-/bin/bash' line and keep the 'tty1::askfirst' line, then after killing init I get the 'Press enter to activate console' message on tty1 and after pressing Enter, I get a working bash shell.

So I think there might be an issue with how the inittab is handling tty1. Wild guess is it starts two bash shells and some key presses go to one and some to the other. The 'tty1::askfirst' line is coming from /etc/rc.d/rc.installerconfig which appends it to the inittab if the hardware model is "Raspberry Pi 4" (so not a problem for RPi3).

I will carry on with installing from tty2 but just thought I would report my experience.

Geoff.

Hi Geoff,

Thanks for sharing the problems you're experiencing. It's sounds very much like you're suffering the same issues as laid out in this thread.

You are right, it is the same issue. I should have looked harder for an existing thread. I thought it surprising that I might be the first to encounter it.

Geoff.

I've just had a quick look at the SARpi installer image and you can probably fix this by removing 'console=tty1' from RPI boot loader's 'cmdline.txt'. The Slackware ARM installer should not have any Kernel console settings applied.

Gave it a quick try and it made no difference. I still got the "two bash shells" effect (or whatever) on tty1 while tty2 worked fine. I checked via dmesg that there was no console=tty1 in the kernel command line. I don't know enough about init or inittab or installers or RPi4 booting to be able to say what's happening but I will keep looking at it.

Geoff.

My guess is that the SARPi edition of the Slackware installer is incompatible with the AArch64 developments. I couldn't immediately see what that might be though, other than the console setting.

Can you try using the official Slackware installer for the RPi4 ?
ftp://ftp.arm.slackware.com/slackwar..._latest.img.xz

xzcat that to your SD card and boot it.

You cannot install the 64bit port yet since it's not released, but the installer should function properly at the virtual consoles and over the UART.

Update:
I went to see if I could fix SARpi's installer when it's running, but this version http://slackware.uk/sarpi/rpi4/curre...n22_sp1.img.xz hangs on the rainbow screen.

Which were you using?

Yep that'll be the problem. This is correct for Slackware AArch64 on the RPi4, but not with the kernel and configuration SARPi has. Perhaps it can be corrected on the next build there.

Oofa! I only built that a few days ago. Hopefully very soon I'll be able to stop releasing software that doesn't work anymore.

Not sure what might be causing any issues but I tested the latest SARPi installer (for the third time) and it boots, and runs, as expected. No keystroke issues or otherwise. It all seems to be working perfectly for me.

Attached Thumbnails

 

Strange thread here

1 members found this post helpful.

Did you test with virtual consoles? That's not a photo of your monitor, for sure.

No more strange than I've anticipated, that's for sure.

I tested by booting the RPi4 and logging in locally and remotely, just to make sure there wasn't any issues while setting up the system to install Slackware ARM. That's actually a screenshot from putty while logging in remotely. I am aware that you're using a RPi4 8GB and mine's a 4GB version but apart from that it's all the same hardware and I can honestly say I haven't found any problems this time around with the SARPi shizzle.

Although, as you come ever closer to releasing your latest Slackware work I'll be looking to wind down my support, and efforts with the SARPi project. There really is no point or valid reason for me to continue with it when you're supporting the Raspberry Pi devices yourself. For now the SARPi installer seems to be working as well as it ever did and I have no answer for why users are experiencing problems with it. It certainly doesn't need fixing in the next release as far as I can tell. I don't expect that to endure for much longer and am a little surprised everything's still working as well as it is given the impending release of Slackware ARM 15 and AArch64. I'm quite sure what you've designed will work perfectly as intended. That's what end-users should be running, moving forward.

and you admirably took care of where there was a need, CHEERS!

2 members found this post helpful.

The official RPi4 aarch64 installer works fine as far as the consoles go. I get a bash shell on the serial console and tty1 shows the 'Press enter to enable' message, then the 'Choose keyboard map', then gives a working bash shell. I guess somehow the inittab '::respawn:-/bin/bash' line in the official installer goes to the serial console while in the sarpi4 installer, it goes to tty1 and hence conflicts with the appended line for tty1.

I did find the official installer doesn't like my SD card as the dmesg log has a continuous stream of 'mmc1: invalid bus width' messages and the SD card doesn't show up as a block device (no /dev/mmcblk0*). Tried with a couple of SD cards without luck -- a decent Samsung Evo 32GB and a slow no-name one. Possibly related to this bug: https://bugzilla.kernel.org/show_bug.cgi?id=213753. Writing the official installer to a USB drive and booting from that worked fine. I also tried booting the Raspberry Pi OS arm64-lite version off an SD card and that worked fine (it's using a 5.10.92 kernel).

That's the sarpi4 installer I tried. I haven't tried the latest sarpi4 installer (02Feb22) yet. On my RPi4 4GB it does remain on the rainbow screen for longer than I am used to (10+ seconds) but it doesn't hang.

Geoff.

Thanks glorsplitz. I filled the need because it seemed like a good idea at the time and I had a dream that Slackware ARM might become a much used OS for the Raspberry Pi device. That dream died some years ago as it was never realised and I don't think it ever will be. I've put wayyy more time and effort into the SARPi Project than I can recall over the years and enjoyed it for the most part. When all I get back is criticism, rebuke, certain people second-guessing my work and experience, accusing me of having ulterior motives and spitting on their work when I'm actually trying to help them, trying to discredit me at every opportunity in favor of their own agendas while trying to promote themselves as the 'go-to expert' on LQ for Slackware on the Raspberry Pi devices, and now when I've also got Stuart telling all and sundry that SARPi just doesn't work when it clearly does, I have much more enjoyable things to concern myself with in life. I'm not interested in taking any of the recognition or esteem in order to bolster my non-existant ego. Others are, so it seems and those with delusions of grandeur or guru-syndrome are most welcome to it.

I've never forced anyone to use SARPi. It was a means to an end. Now the end of the project is near and it could have gone down a lot more smoothly and amicably than it is doing, but that's not my choice. I've been bugging Stuart to officially support the Raspberry Pi for years and really glad he's finally doing it. It'll save me a shedload of time and effort. I just wish others would realise there is no struggle for power or dominance, or turf-war, or market-share value or otherwise. It all seems a little childish and very unnecessary at times, the way people are trying to disparage and disrespect my project and the amount of work I've put into it. What some people don't realise is that I'll gladly hand off any and all responsibility and commitments I may have garnered over the years by doing what I've done with SARPi. Any and all credit goes to Stuart for Slackware ARM and Dave Spencer for his raspi build scripts.


My experience with Samsung EVO SD cards is that the Raspberry Pi (1) loves them and the 2, 3 and 4 don't as much - but that's very hit and miss depending on the Linux distribution you're running from them. I've tested with dozens of SD cards over the years and the best ones I find are the Kingston SDCG3 range for reliability and longevity.

I built and tested the latest SARPi installer yesterday, which seems to work perfectly, and "hanging on the rainbow screen for longer than expected" is something I've noticed happening for quite a few months. It used to be a brief 5-6 seconds and these days it's 12-15 seconds. As you say, it doesn't hang there indefinitely. It does what it's designed to do and that's the most important thing.

1 members found this post helpful.