Slackware - ARM This forum is for the discussion of Slackware ARM. |
Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
 |
|
09-22-2022, 02:27 AM
|
#16
|
Member
Registered: Jun 2007
Location: Australia
Distribution: Slackware
Posts: 81
Rep:
|
Quote:
Originally Posted by gsl
That's why my thought was to install them manually: mount the SD card partitions on my PC, untar the SaRPi packages, copy the kernel & modules into place, edit extlinux.conf, config.txt, cmdline.txt, /etc/fstab, /etc/inittab, whatever is necessary.
|
I gave this a try and it does work. No surprise really as you are just manually rejigging things to match what you'd get by installing the SaRPi packages. I did need to copy the SaRPi firmware to the vfat boot partition as well. (Possibly just the appropriate dtb would be enough but I replaced all the *.dtb, *.dat, *.elf and bootcode.bin with the SaRPi versions.) Also you don't need to change extlinux.conf as you are just using the RPi boot loader via SaRPi's config.txt.
So it is an option if you want to revive a broken slackwareaarch64-current install rather than do a fresh install of SaRPi.
Geoff.
|
|
1 members found this post helpful.
|
09-23-2022, 11:20 PM
|
#17
|
Senior Member
Registered: Dec 2002
Distribution: slackware!
Posts: 1,398
|
My rpi are on back burner except one rpi3, as I have not had any unresolvable issues, thanks to Stuart, with my rockpro64s.
Exaga has been very kind in bridging gaps.
Last edited by glorsplitz; 09-23-2022 at 11:25 PM.
Reason: typoh
|
|
2 members found this post helpful.
|
09-26-2022, 02:21 AM
|
#18
|
SARPi Maintainer
Registered: Nov 2012
Distribution: Slackware ARM, AArch64
Posts: 1,067
|
Quote:
Originally Posted by glorsplitz
Exaga has been very kind in bridging gaps.
|
For almost a decade. 
|
|
|
10-14-2022, 06:51 PM
|
#19
|
Member
Registered: Jan 2004
Location: British Columbia
Distribution: Slackware64-current, aarch64
Posts: 232
Rep: 
|
Quote:
Originally Posted by Exaga
For almost a decade. 
|
Putting the slack back in slackware for the rpi4... Thanks again.
|
|
3 members found this post helpful.
|
12-30-2022, 06:07 AM
|
#20
|
Senior Member
Registered: Oct 2012
Location: South Devon, UK
Distribution: Slackware
Posts: 1,160
Original Poster
Rep: 
|
I had put this on the back burner, awaiting kernel 6.X.X to be in the mainstream. However, having a few hours to kill, I thought I'd try the latest version and see if there had been any fixes in the interim. Sadly not! Although the install went OK, it crashed in exactly the same place when the boot process appeared to disable the SD-card. Since this is where the OS resides on a Pi, this is not very helpful.
I decided to try the latest sarpi64, using the slackwareaarch64 packages, and that works perfectly! Indeed, its even better than slarm64, as now my wifi works again! (Something in slarm64 stopped it a while ago, and I haven't been able to fix it.)
I've tried every possible modification of config.txt and extlinux.conf on slackwareaarch64 and only succeeded in making matters worse (wouldn't boot at all!).
I thought I'd try putting the OS on a USB drive, but I seem to have run into the problem that Exaga found here: https://www.linuxquestions.org/quest...ce-4175682591/
as both a pendrive and a SSD got past the disabling of the SD card, but then crashed with a load of scsi errors (constantly re-setting). I've ordered one of the USB adapters recommended by Exaga, and when it turns up, I will give it another try.
Conclusions: Something in the kernel setup of slackwareaarch64 is preventing it from working on the Pi400 (and possibly 4 as well). I'm guessing that its something in the kernel .config file used to build it, as nothing in the boot configurations seems to help.
Hopefully this will get fixed when the 6.X.X kernels are standard. In the meantime, the sarpi64 kernel and install works really well! Many thanks, Exaga!
--
Pete
|
|
|
01-03-2023, 04:48 AM
|
#21
|
Slackware Contributor
Registered: Apr 2008
Distribution: Slackware
Posts: 1,624
|
I've just installed on the Raspberry Pi4 running Linux 6.1.2. The V3D driver works out of the box, and so far (having added 'irqpoll' to the Kernel cmdline - thanks to whomever it was on this forum who suggested that a few months ago) the MMC subsystem is stable.
I'll probably push out the updates later this or early next week.
|
|
1 members found this post helpful.
|
01-03-2023, 05:46 AM
|
#22
|
Senior Member
Registered: Oct 2012
Location: South Devon, UK
Distribution: Slackware
Posts: 1,160
Original Poster
Rep: 
|
Thanks for this, Stuart!
Strangely enough, I'm just having another crack at it at the moment!
The Exaga recommended USB2SATA adapter turned up a couple of days ago, so I tried doing an install straight to the SSD. Any install to the SD card fails to boot due to the disabling of the SD card during the boot process, as mentioned above. This means installing everything to the SSD. Unfortunately, this also fails as the install process tries to remove the installer files from the (non-existant!) SD card, so when you attempt to reboot from the SSD, it just runs the installer again!
I've just done a complete re-install to SD card, and am currently cloning the SD card to the SSD via "dd". I'm hoping this will produce a usable SSD installation. It will probably be another half-hour before it completes, and then I'll report back.
Certainly Exaga's (and sndwvs - slarm64) 6.0.X kernels work well and invoke the V3D driver correctly. Still not perfect, the word is there is more to come in 6.2 which should be out in a month or so.
In the meantime, once the clone finishes, I'll report back if my rather long-winded way of installing the current iteration to SSD works or not!
Happy New Year!
--
Pete
Last edited by pchristy; 01-03-2023 at 05:47 AM.
Reason: typo
|
|
|
01-03-2023, 06:52 AM
|
#23
|
Senior Member
Registered: Oct 2012
Location: South Devon, UK
Distribution: Slackware
Posts: 1,160
Original Poster
Rep: 
|
Woo!Hoo! Well, that got it to boot from the SSD! (Still won't boot from the SD card)
The only slight issue is that after mounting the various partitions, the system pauses for a very long time before bringing up either a login prompt or starting sddm. Must be the best part of a minute - certainly enough time to make you think it has frozen, but it hasn't (the cursor keeps flashing!). Its still running llvmpipe, so the graphics are clunky, but at least it gets it to boot!
I can't see anything that might account for the pause, but I'm guessing that its expecting something to be on the SD card and has to hunt for it elsewhere.
Roll on the kernel 6 updates!
--
Pete
|
|
|
01-03-2023, 10:07 AM
|
#24
|
SARPi Maintainer
Registered: Nov 2012
Distribution: Slackware ARM, AArch64
Posts: 1,067
|
Quote:
Originally Posted by pchristy
Unfortunately, this also fails as the install process tries to remove the installer files from the (non-existant!) SD card, so when you attempt to reboot from the SSD, it just runs the installer again!
|
I set up all the required partitions and install Slackware to the SSD on the Raspberry Pi, only using the SD card to boot into the installer. Then once the system is ready to reboot I power the whole thing off and remove the SD card before 'rebooting' into the Slackware OS.
If the SD card is present (even if the RPi4 is set to boot from SSD first) it usually boots from the SD card in any event. One might assume, that even with the SD card plugged in, the device should ignore it and boot from SSD. This is perhaps why it runs the installer again when you reboot. Otherwise there should be no installer present on the SSD to load.
|
|
|
01-03-2023, 10:26 AM
|
#25
|
Senior Member
Registered: Oct 2012
Location: South Devon, UK
Distribution: Slackware
Posts: 1,160
Original Poster
Rep: 
|
Hi Exaga,
Sorry if I wasn't clear. I wasn't talking about sarpi64 - which works perfectly  - but a pure slackwareaarch64 install. The problem seems to be that although slackwareaarch64 installs perfectly to the SSD, it doesn't remove the installer on completion. It appears to be trying to remove it from the (non-existent) SD card, which is why it keeps trying to run the installer instead of booting Slackware.
The sarpi64 install was completely painless, and works exactly as expected. Indeed, it is even better than my previous favourite (slarm64) which seems to have an issue with wifi on my Pi400.
I know Stuart doesn't recommend slackwareaarch64 for the Pi4/00, but as it is one of the more popular small computers out there, I would like to try and assist as much as I am able. I do like to get my teeth into a tricky problem, it helps keep the mind alive (!), but I don't always have the time! I should be fixing an annoying fault on my classic car today, but its too wet, cold and windy to be working in the garage! So, I have a bit of time to have another look at this...
BTW, your comment about "even if the RPi4 is set to boot from SSD first" has intrigued me! I was unaware such a setting existed! I certainly haven't seen it on my 400. Where is this magical incantation?
Cheers,
--
Pete
|
|
|
01-03-2023, 01:59 PM
|
#26
|
SARPi Maintainer
Registered: Nov 2012
Distribution: Slackware ARM, AArch64
Posts: 1,067
|
Quote:
Originally Posted by pchristy
Sorry if I wasn't clear. I wasn't talking about sarpi64
|
Neither was I refering to SARPi. This isn't about Slackware or the way one installs it on any ARM device. It's about how SBCs work in general.
Quote:
Originally Posted by pchristy
BTW, your comment about "even if the RPi4 is set to boot from SSD first" has intrigued me! I was unaware such a setting existed! I certainly haven't seen it on my 400. Where is this magical incantation? 
|
For example; I modified the RPi4 boot order to use SSD as primary and did some testing at the time. After successfully installing Slackware ARM on a SSD I left the SD card plugged in when I rebooted and ("Hey presto!") the system booted the Slackware ARM installer initial RAM disk from the SD card, instead of the expected Slackware ARM OS on the SSD. I ejected the SD card, rebooted, and the expected Slackware ARM OS on the SSD loaded. Therefore, I deduced that even though I'd modifed settings to boot from SSD first, with the SD card present it still booted from it and not the SSD. I think I've read somewhere (a couple of years ago before the RPi400 was available) that this is expected whenever there's a bootable SD card detected. Do some Googling and hopefully you'll dig up more information about it. Alternatively, which might be quicker and much less time/effort, do some testing yourself and see if the system boots from a SD card even though it's set to boot from SSD first.
|
|
|
01-03-2023, 02:26 PM
|
#27
|
Senior Member
Registered: Oct 2012
Location: South Devon, UK
Distribution: Slackware
Posts: 1,160
Original Poster
Rep: 
|
OK, but I was under the impression that the /boot and /hwm_bw partitions (slackwareaarch64) stayed on the SD and only the /root and /swap partitions were on the SSD. My objective is to get the whole system on a single drive. If I'm right in my impression, then the vfat (hwm_bw) and /boot partitions never get transferred to the SSD under the Slackwareaarch64 installer, and therefore it isn't going to boot without the SD card - which it won't do anyway, due to the previously mentioned disabling of the SD card during the boot process!
This is mostly conjecture on my part, and I'm very happy to be shown to be wrong if I am!
--
Pete
|
|
|
01-03-2023, 03:09 PM
|
#28
|
SARPi Maintainer
Registered: Nov 2012
Distribution: Slackware ARM, AArch64
Posts: 1,067
|
Quote:
Originally Posted by pchristy
OK, but I was under the impression that the /boot and /hwm_bw partitions (slackwareaarch64) stayed on the SD and only the /root and /swap partitions were on the SSD. My objective is to get the whole system on a single drive. If I'm right in my impression, then the vfat (hwm_bw) and /boot partitions never get transferred to the SSD under the Slackwareaarch64 installer, and therefore it isn't going to boot without the SD card - which it won't do anyway, due to the previously mentioned disabling of the SD card during the boot process!
This is mostly conjecture on my part, and I'm very happy to be shown to be wrong if I am!
--
Pete
|
You're talking about two different things which conflict with your goals/expectations/requirements. If I understand correctly;
1. How MoZes intends his software to be installed.
2. How you'd like it to be installed.
Logical conclusion: If the solution to your quandary does not exist then create it. It goes without saying, if an ARM device is capable of booting from SSD then whatever enables it to boot from a SD card needs transposing/replicating on a SSD to effectuate the same end result.
Slackware is one of the most versatile, adaptable, changeable, and adjustable, Linux distro's available. Being peerless and unabridged by nature and design, Slackware empowers users to make it happen. Slackware ARM dev's might not cover all eventualities for every end-user. So this is where the end-user has the opportunity to step up and glow.
|
|
|
01-03-2023, 05:19 PM
|
#29
|
Senior Member
Registered: Oct 2012
Location: South Devon, UK
Distribution: Slackware
Posts: 1,160
Original Poster
Rep: 
|
Yes, your analysis is spot on!
The install instructions place the boot system on the SD card, with everything else on "sda" - this is presumably because non-Pi systems have a built in hard drive of some kind. For the Pi, as you will be aware, it makes sense to put it all on one drive, and until the September updates, this worked OK on the SD card. Something in those updates - presumably the kernel update - broke the ability to boot from an SD card on the Pi.
However, you could run the installer, and install on the SD card - it would just hang when you tried to reboot into Slackware. This is why I thought installing on the SSD drive would make sense. Unfortunately, installing straight to the SSD drive also fails, because during the final stages, it leaves the boot process pointing at the installer. It does try to remove the installer, but incorrectly assumes it is on the SD card - which doesn't exist!
So, my solution was to install to the SD card, but then instead of rebooting, to clone the SD card to the SSD and then boot that. My first attempts failed, because of the USB2SATA adapter issues that you identified elsewhere. Once I got a replacement adapter, it all started to come together.
There are still some minor issues. There is a very long pause during the boot process whilst it tries to find something in an unexpected place (I guess), and reboot doesn't work. It gets stuck in a loop trying to unmount the SD card - which again, doesn't exist! It also doesn't fully shutdown, but this has been a problem on slackwareaarch64 on the Pi since its inception. I have a USB-C power switch on order to save me having to get on my hands and knees to unplug it (or risk damaging the surface mount USB-C power socket on the 400!).
But it is getting there!
Sarpi64 works much better at present, though!
--
Pete
|
|
|
01-03-2023, 06:58 PM
|
#30
|
SARPi Maintainer
Registered: Nov 2012
Distribution: Slackware ARM, AArch64
Posts: 1,067
|
Quote:
Originally Posted by pchristy
Sarpi64 works much better at present, though! 
|
Sarpi64 is just an installer for Slackware AArch64 on the Raspberry Pi devices(s). The operating system is not SARPi and never will be. EVER!
SARPi/SARPi64 shizzle does not, and never will, butcher ANY official Slackware [setup] files in order to make ends meet. SARPi used to be the easiest way to install Slackware ARM on the Raspberry Pi devices, but now there's the official software available so THAT should be used and promoted first and foremost. I do not welcome users comparing SARPi to the official software that MoZes releases because that's like comparing the dog-eaten menu down Greasy Joe's cafe (SARPi) with the Rosetta Stone (Slackware).
[ I'm assertively confident that the person who manipulated the SARPi64 installer to work with Slarm64 on the RPi400 (i.e. something it was never intended for in a millennia of derranged nightmares) can successfully mutilate the official Slackware AArch64 installer with the same degree of reckless abandon in order to make it dance to their tune. ]
If you're not happy with the way the official Slackware AArch64 installer works then take it up with Stuart. Better still, create your own fully working version of 'how it should be done' and use it as a test-case to present as a proof of concept. You never know, maybe he'll endorse it and include it (or something similar) in the officially released software.
|
|
1 members found this post helpful.
|
All times are GMT -5. The time now is 12:38 PM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|