LinuxQuestions.org - [SOLVED] slarm64 (aarch64 unofficial slackware)

- Slackware - ARM (https://www.linuxquestions.org/questions/slackware-arm-108/)

- - slarm64 (aarch64 unofficial slackware) (https://www.linuxquestions.org/questions/slackware-arm-108/slarm64-aarch64-unofficial-slackware-4175613287/)

I propose to make a list of additional software which is not enough for aarch64, to build and update in addition to slarm64.

Quote:

Originally Posted by sndwvs (Post 6125673)

I propose to make a list of additional software which is not enough for aarch64, to build and update in addition to slarm64.

Strange... I thought I replied to this one a few days ago. I must have not hit the submit button. Oops.

Interesting idea. The biggest package that I build that takes the most time and resources, by far, is LibreOffice. But at least I have a script for that one that makes for a fairly automated process, even if lengthy.

I just reinstalled on a Pine64 box with a next-kernel. The first two packages I built were:

ncdu (usually one of the first packages I build on any Slackware-based system)

transmission (my favorite headless torrent deamon/client)

Those, their MD5SUM files, and a few other of my recent builds are all here:

https://3space.xyz/pineslarm/packages/

I will try to keep track of my most essential packages going forward.

Most of the ones I am currently hosting required special tweaks to build. Many others build as-is from slackbuilds.org that I am not hosting at the moment.

Bonus fact: most of these packages contain the SlackBuild file in the docs directory in case you want to rebuild your own package.

Thank you, this is always useful.

update rootfs image 2020.05.20

I tried this.

No swap, but that's actually preferable, as I have 4G on the RazPi 4B. But / is mounted READ ONLY, so it goes through the init, puking in predictable places, and reboots endlessly. One other thing: I presume a password for / is set, but it is not mentioned. So folks will not be able to login, or add users. I'm trying to get there now by Machievellian techniques.

Quote:

Originally Posted by business_kid (Post 6127960)

I tried this.

No swap, but that's actually preferable, as I have 4G on the RazPi 4B. But / is mounted READ ONLY, soit goes through the init, puking in predictable places, and reboots. One other thing: I presume a password for / is set, but it is not mentioned. So folks will not be able to login, or add users. I'm trying to get there by Machievellian techniques.

What are we talking about?
About slarm64 is rebuilt slackware.
About Raspberry Pi 4 bcm2711 (aarch64) is a slarm64 + kernel from the raspberry repository.

Sorry: About http://dl.fail.pp.ua/slackware/rootf...00520.info.txz. This is your last slarm64 rootfs

This is really sorted. I reinstalled, logged in again, and it booted fine, but I couldn't log in. I had copied over /etc/shadow, and /etc/shadow- from my x86_64 box to have the same passwords, but that didn't work. But I have a sdcard-to-usb thingy that came with the Lablists RazPi kit, and I'll probably go at it with that. On first glance, I like the look of it, but as you can gather, I didn't get beyond login.

I will look at this problem.
Нou can always use chroot and change the password.

Quote:

Originally Posted by sndwvs (Post 6128341)

I will look at this problem.
Нou can always use chroot and change the password.

I wouldn't bother looking into it. I just resorted to Jesuitical or Machievellian tricks. You don't need chroot, which is a bit iffy from an X86 box (!)

Mount the sdcard, then as root use

'passwd --root=/sdcard_root' and follow the prompts. That's all you need.

I'm still a newbie with Arm and proceeding at my own SLOW pace. Here's a good one, though, and it's ok if you don't know this, I wanted to stick in 32 bit libs, but glibc is proving a sticking point, because Gcc & glibc have (theoretically) to be able to compile 32 bit Arm programs. Now the RazPi 4 is hard float, because it has it's own FPU, and you want to use that. But the state of 32bit systems is less certain, as most don't have FPUs, as far as I know. So what's the deal from here?

Also, when 3rd party Arm software is compiled 32bit for Arm (sometimes with no source), that, I presume, will be soft float. Then the permutations get imponderable. I don't even know if multilib is possible. Your slarm64 is up & running here, btw. No bending it straight to do, just setting up.

I have your rootfs of 2020-05-20 installed here. ( I stress that I'm not a fast or tireless worker.)

It's overscanning here, and there seems nothing I can do about it. It starts when the kernel boots. I see "ing" instead of starting' or 'loading'. When xfce starts, I get the menu bar barely visible on top, and nothing else. Changing monitors is actually a huge deal, but the same hdmi monitor was picture perfect on Slackware arm (32bit) and Raspbian/Noobs.

I fiddled a bit with config.txt. Raspbian offered the following settings
overscan_left
overscan_right
overscan_top
overscan_bottom

Setting overscan_top & bottom to 64 solved the height problem, but I never got to see the picture edge on any side. Thhe overscan left & right settings apparently had no influence. I also tried with a single 'overscan' setting, intending to see some edge, and adjust from that. I raised the overscan setting in increments as far as 256, which is ridiculous, but never moved anything.

Personally, I think it's a kernel issue. But the kernel these days is huge, and I'm not up to date with framebuffer issues at all.

The problem with the root user password is solved in rootfs-20200528

Quote:

Originally Posted by sndwvs (Post 6128957)

The problem with the root user password is solved in rootfs-20200528

Great. Has it done anything about the screen overscan? What's the fix in rootfs-20200528 - enter my own root password? I've dodged the issue by low devices and got a root password of my own on.I mean to add a user, because the xfce4/settings windows don't want me as root. so I get no complaints there, but all of the settings are greyed out there. I shouldn't start X as root anyhow.

I have been reading up on compat32, and the rest of this post here contains what I've discovered. In a word, there is no need for Compat32, and here's why.

X86 started with separate "Maths Co-Processors" which developed well in 16bit. The 80386, the first X86 32 bit cpu, had it's co-processor (aka FPU) built in. No issues surfaced from i386 to i686 (Nobody bothered compiling i786). Since we went to X86_64, the FPU and it's ABI has largely been left alone. Slackware's Compat32 packages supported building 32 bit programs with a 64bit system. In particular wine, which translates windows 32bit system calls to Posix ones needs the 32 bit libs there to run.

Not so with the Arm, which started with basically no FPU, and it gradually evolved. So the Razpi 4 (A-72 Cortex) has a serious FPU, but earlier ones don't. So you have the situation that 32 bit programs & libs will run on later 32bit models, and later 64bit models if they have correct 32bit libs. This can get very tricky; There's a gcc option '-msoftfp' which basically tells gcc to use what FPU the CPU has, and emulate the rest. But if I were to use that on my A-72 Cortex RazPi 4, gcc would compile for a FULL FPU, and all 32bit CPUs could puke on maths operations because of an ABI incompatibility. From this, I made 2 decisions that suit me, and may not suit others.

1) Break with slackware64 in allowing compilation of 32bit programs. There's no wine for Arm. I've no 32bit Arm devices. (Even my phone with it's Snapdragon 820 is 64bit)
2) Cater only for 3rd party software installed on my system, which is currently zero.

These simplify things. But in 32 bit software, somebody may legitimately compile for soft float (=no fpu) for reasons of compstibility, and that imposes a significant speed penalty on maths based stuff, but the ABI is forward compatible. So we add decision 3

3) Never install anything that is maths based and 32bit except as an absolute last resort.

Personally, I am of the opinion that Mozes & Exega made the correct call in compiling for the RazPi 2 (=A-7 Cortex). Raspbian apparently sank to the bottom of the barrel, with purely soft float.I once had a Raspi 1, and Raspbian ran on it, although the best browser on offer was Midori, which is one step above lynx. I intend to check if they do a hard float option.

For compat32, then, I just need somne libs from the a/, l/, n/, & x/ packages, and not all of them either. You do need most of a/, though. You do get surprises, though. I needed libwayland for xfce, something from Cyrus-sasl & something from sql for various utilities. I do expect I'll need to fetch stuff from Slackware Arm if much goes in. But a simple check 'ldd <newly_installed_program> |grep found' will tell me what to get. Repeat for the 32bit libaries. I see no reason to install gcc libs.

I repeat rootfs and slarm64 is a system that is not tied to any device.
Binding (which is usually a specific kernel) is done in images_build_kit