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/)

Ok. I'll get a look at the kernel myself some day. And I'll go at things here, at my own pace. I just wanted to know if you knew of some specific hiccough, and you didn't. That's fine. Raspbian aren't offering a hard float version with X yet. There's some console based image you can use to build & debug X yourself. But you've done it, haven't you?

Quote:

Originally Posted by business_kid (Post 6129046)

There are images for RPI 3/4 with xfce and these are not modified slarm64 packages.
But the kernel itself is taken from the raspberry repository, there’s nothing to test with, if someone needs it, it can try, tethe, fix and configure it. If you want to help fix and bring it to the correct operation of an automatic collector of images.

Quote:

Originally Posted by business_kid (Post 6128192)

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.

This happened because PAM was added to -current upstream, and required a few extra packages to be installed to avoid exactly what you ran into:

Code:

Sun May 24 08:08:08 UTC 2020

> 

> Hello! With this update, PAM has been merged into the main tree.

> When updating, be sure to install the new pam, cracklib, and

> libpwquality packages or you may find yourself locked out of your machine.

> Otherwise, these changes should be completely transparent and you shouldn't

> notice any obvious operational differences. Be careful if you make any changes

> in /etc/pam.d/ - leaving an extra console logged in while testing PAM config

> changes is a recommended standard procedure. Thanks again to Robby Workman,

> Vincent Batts, Phantom X, and ivandi for help implementing this.

> It's expected that there will be some more fine-tuning of the config files, but

> for now it's good to go!

Any rootfs or base image made before this date will have the password issue unless you also run something like slackpkg install-new to catch the new stuff to allow you to log back in after reboot. I made the same mistake on a few test images I was using for other purposes, so I know exactly what caused it and how to avoid it for anyone working with an older image. Just make sure to install the new stuff and you should not have any issues.

I am rebuilding my A64-Pinebook images now for this very reason.

Side note #1: I have also been testing out some Rock64 images. Those seem to build fine, and the "next" kernel is really nice on this little board. I am hoping to try out some initrd stuff soon, see if I can get some disk encryption happening.

However, I still cannot boot from an A64-Pinebook image unless I roll it back to a specific commit from a few months ago. Hopefully I can figure out what that is. I recall that it was suggested that the u-boot was a problem. I was able to rule that out, actually. That was some time ago. Maybe I can make some more progress on that soon. Fingers crossed.

Side note #2: I am starting up a campaign to generate some funds to donate to my most crucial free software projects. It might not be much, but I should be able to drop something in your bucket soon. Again, fingers crossed.

Thanks very much. I have the X86 laptop with sdcard reader to fal;l back on, but I'm downloading the latest rootfs now. That's not a quick operation from where I am. And 'xz -dc image | dd of=sdcard' must be the slowest ever, as they each dawdle along at a few %.
/Sigh.

EDIT: Ah! I can relax! It's only an 83MB tar.gz. So that must go over the 2020-05-20 image, and then, any config I've done might need going over that. I'll try it as it stands first.

/Much Later

I'm going to leave this for the moment. I want to take the time to thank you, sndwvs & Shelldweller for your prolific work, which is rewarded solely by the output. It's a worthwhile cause and an interesting challenge that I unfortunately cannot get involved in, as my health does not permit it.

Despite many ups and downs here, your OS is so security conscious I'm still stubbornly locked out here. Probably some of that is my fault. On X86_64, Slackware will probably change a bit next release, if Alien Bob's repo is anything to go by. I think mine is a different and minority use case to Slackware Arm and the folks you're mainly catering for, so I've reluctantly made a break from Slackware, and undertaken duelling the demons of systemd & NetworkManager with a debian based 32 & 64 bit os. They're on different sdcards andre-badgers, but if I need outside software I can stick it on 32bit, the rest of the time I'll use 64 bits.

Great news, for the project slarm64 was provided a board raspberry pi 4 4G user wowbaggerHU.

The image that we prepared together works great on this board.

Quote:

Originally Posted by sndwvs (Post 6138258)

Great news, for the project slarm64 was provided a board raspberry pi 4 4G user wowbaggerHU.

The image that we prepared together works great on this board.

Good news indeed. If past form is anything to go by, images seem the only way to install stuff on these.

Now that you have a working image, have you a download link? a root password?

Quote:

Originally Posted by business_kid (Post 6138486)

Now that you have a working image, have you a download link? a root password?

Yes, updated images with firmware upgrade support.
Also checked boot from sdcard -> usb-hdd

Quote:

Originally Posted by sndwvs (Post 6138489)

Yes, updated images with firmware upgrade support.
Also checked boot from sdcard -> usb-hdd

Excellent!

I was just beginning to think I was getting high mileage from one of my sdcards, however when it started nuking attempts at read/write in a major way, so I'll have to buy, before I try, if you follow my drift.

This is a little off the wall for updates, but I'll ask it anyhow.

You do a version of firefox. Does your version of firefox offer the option to play DRM content in the preferences? Does it work?

In X86_64, you apparently need to have that option checked to get Netlifx, Hulu, Amazon Prime, Disney Plus, HBO, Spotify, Pandora, YouTube, VUDU, and many others. Firefox then downloads libwidevine.so into a sandbox, plays your DRM content, and deletes it afterward. (It's only the premium service of youtube).

I have a fix on Chromium 32bit on Raspberry Pi OS which has a libwidevine.so shoved in. As it's posted on a public forum, I presume it's not criminal. But libs aren't 'promiscuous,' i.e. 32 ≠ 64 bit where libraries are concerned. So without an option to play DRM sources, Netflix etc. are locked out on 64bit. I don't even know if there is a libwidevine.so for aarch64, and it's presumably a closed source thing https://www.widevine.com/

firefox assembly is no different from x86_64

firefox drm/cdm aarch64

Quote:

Originally Posted by sndwvs (Post 6141064)

firefox assembly is no different from x86_64

firefox drm/cdm aarch64

Thanks. That doesn't clear up why I don't have the option to play DRM, even if it doesn't work because they don't have an aarch64 widevine compile. I would expect to have the option, but the option not to work. Maybe Debian compiled without it.
But I haven't got your firefox running yet, so all will be revealed.

A link in the bug lead me to another bug which mentioned that there was a chromium-widevine for Stretch (which is some random edition of debian with a different stupid codename). As I happen to have Raspberry Pi OS with [= Debian 'Buster'] (grovelling apologies for another stupid codename) I can search for that.

EDIT: That other bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1392037